Subject: RE: [xsl] Why XTRE1500: Cannot read a document that was written during the same transformation ? From: "Michael Kay" <mike@xxxxxxxxxxxx> Date: Wed, 30 Jan 2008 20:55:58 -0000 |
> But I do not understand why *XTRE1480* is an error! I assume you mean XTDE1480: using xsl:result-document in temporary output state. > > And the reason given by the norm is not very convincing, it > just says that it is: "to ensure that the results are fully > interoperable even when processors optimize the sequence in > which instructions are evaluated". > > I know it's not the role of W3C to give more details, but if > you could give me some convincing example of > over-optimization in the case where XTRE1480 happens, I would > less regret to have had to write a cumbersome workaround for that. Consider <xsl:variable name="temp" as="item()*"> <xsl:sequence select="1"/> <xsl:sequence select="2"/> <xsl:result-document href="output.xml"> <out/> </xsl:result-document> </xsl:variable> <xsl:value-of select="$temp[2]"/> Does the output get written or not? (The point being that implementations are only required to evaluate variables - or any other subexpressions - to the extent needed to determine their result. Many implementations using pipelining and lazy evaluation will be able to compute $temp[2] without looking beyond the second item in the sequence) If the third instruction were xsl:message rather than xsl:result-document, it would be implementation-defined whether the message gets written out. If it were <xsl:sequence select="error()"/>, it would be implementation-defined whether the error gets thrown. The WG didn't want it to be implementation-defined whether final result documents get written or not. At one time the WG tried to model this a different way, and you might find it helpful. In this model, xsl:result-document produces a "document-reference" node that is present on the main result tree, linking to the document node of the secondary result tree. So the output of the stylesheet is in effect a single tree, in which secondary documents are linked as descendants into the primary tree; it's only the serializer that splits this uber-tree into separate documents. The advantage of this model is that there are strictly no side-effects. The disadvantage was that it meant putting something rather artificial into the XDM data model, raising questions about how these document-reference nodes would be accessible to path expressions and so on. We went for the notion of "temporary output state" because it didn't involve tweaking the data model in that way. Michael Kay http://www.saxonica.com/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Why XTRE1500: Cannot read, Colin Adams | Thread | RE: [xsl] Why XTRE1500: Cannot read, Alain |
Re: [xsl] Why XTRE1500: Cannot read, Colin Adams | Date | [xsl] FW: Two-Column XSL question, Thomas, Josh |
Month |