Re: AW: [xsl] xsl:result-document appending
Subject: Re: AW: [xsl] xsl:result-document appending|
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 19 Sep 2003 14:08:50 -0400
At 09:45 AM 9/19/2003, you wrote:
Actually, random order would be fine. Though I don't understand
how this could happen, position() isn't random, is it?
No, it isn't, but XML does not define any ordering for attributes of an
element, so an XSLT processor may encounter them in any order -- it's an
architectural thing. As reported by the parser, attributes on a given
element need not "appear" in any particular order or even the same order
all the time.
position() refers to the position of the current node in the current node
list. This is determined by how you are doing your processing. Introducing
a sort (as David C. suggested I think) is the only way you can induce a
particular order for processing your attributes, since otherwise the
processor generally goes in "document order", which as just explained isn't
defined for attributes.
What's really important for me is to collect my log entries from
different transformations in the same file.
The entries originating from one transformation should stay together though.
Interestingly, the problem here is the same as the last, only on the other
end -- you want to control how your output is written, but this is outside
of the scope of XSLT.
I think you want to handle this some way in your processing environment.
For example, Ant could make intermediate files for you, etc. As Mike just
explained, you don't want to depend on processing happening in any
particular order (which overwriting an input file implies).
Right now this looks like I have to use both approaches simultaneously,
read the file before I write to it and run through the for-each loop twice,
in order to read the file only once per transaction and not once for every
iteration in the for-each loop.
I guess, even this approach is still not entirely legal, since I still
read and write the same file from within one transformation.
Right. But the problem is a snap to handle outside with a little file
swapping. You are right, this is clumsy -- but it's the price we pay for
XSLT's abstraction from the file system, which is generally a very good
thing. Is that so bad?
"Thus I make my own use of the telegraph, without consulting
the directors, like the sparrows, which I perceive use it
extensively for a perch." -- Thoreau
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list