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:

Current Thread