From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) BuildID: with standalone transformiix build, a sequence of xsl:for-each commands nested within an xsl:for-each results in loss of data, probably because the current context is being lost; TX also miscounts the position() in certain cases and I believe the bugs may be related; I have created a detailed test-case for the xsl:for-each bug, and will test the position() more when that is fixed Reproducible: Always Steps to Reproduce: The output after processing test.xml: <sign> <value> <vals> <val>ba</val> </vals> <data>BA</data> <refs>PEa:146</refs> </value> </sign> with foreach.xsl: <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="sign"> <xsl:for-each select="value"> <a> <xsl:for-each select="vals/val"> <xsl:value-of select="."/> </xsl:for-each> </a> <xsl:for-each select="data"> <b><xsl:apply-templates select="."/></b> </xsl:for-each> </xsl:for-each> </xsl:template> </xsl:stylesheet> should be (from Saxon [and XT]): output.saxon: <?xml version="1.0" encoding="utf-8"?><a>ba</a><b>BA</b> but tx gives (no <b>BA</ba>)... output.tx: <?xml version="1.0"?> <a>ba</a> ===== If you remove the first nested for-each, the second is processed correctly: foreach2.xsl: <?xml version='1.0'?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="sign"> <xsl:for-each select="value"> <xsl:for-each select="data"> <b><xsl:apply-templates select="."/></b> </xsl:for-each> </xsl:for-each> </xsl:template> </xsl:stylesheet> output.tx2: <?xml version="1.0"?> <b>BA</b> Expected Results: This is in the standalone tx build on Linux, freshly cvs updated as of 9/26/00. This bug has also been reported in netscape.public.mozilla.layout.xslt.
This appears to effect only standalone transformiix. The expected output when using integrated transformiix works on linux and mozilla. This is confirmed with linux and win32 standalone 26th sep 2000. Keith can you change this to confirmed.
Sorry Jus, I don't have enough priviledges. I used to, but for some reason Bugzilla doesn't let me do anything anymore except add comments. I will try to get a patch in asap for the bug. Peter mentioned something about Axel being able to change my permissions, perhaps if he's listening he can do so? --Keith
me listens to keith, anything you get, I get too ;-). Being back from the Frankfurt week, I do more stuff like this. I remember that accepting at once didn't work, so I confirm. Axel
I upgraded your perms, keith goes to all, jus to CanConfirm. So Jus, your bugs won't even start unconfirmed anymore. Axel (assigning this one)
changing severity to normal
OK...well it's because your result tree is invalid. You are creating an illegal XML document. XML documents are supposed to only have _one_ root element, so transformiix is just using the first one. If you wrap your outer xsl:for-each within a root element you will get the correct result, for example: <xsl:template match="sign"> <foo> <xsl:for-each select="value"> ... </xsl:for-each> </foo> </xsl:template> this yields: <?xml version="1.0"?> <foo><a>ba</a><b>BA</b></foo> I am not sure how we should really handle the case when the user tries to create more than one root element. I used to add a wrapper "root" element myself called "tx:result" and in some cases I still do. But this is kind of ugly. Since I currently still use a DOM for the result tree it's not possible for me to create the result that XT or Saxon gives you. --Keith
Darn, confirmed a bug that's invalid. But I don't like invalid, so I will not mark this one invalid, but change the summary. The error is, we don't report one ;-). As error reporting is not our primary interest, I MFuture and switch to enhancement on this one. Axel
Hey, I confirmed it first :(. It confused me when in mozilla it worked "correctly". Im assuming when running within mozilla, we have previously generated a root element before starting the transformation, and thats why this behaved as the reporter expected?
Adding Peter, we shouldn't produce false DOM on mozilla. This is either some inconsistency in the mozilla dom, or some followup to peter's "eat this tree, you darn view". Peter? Axel
Now that I understand the reason for the failure of the test case this bug is no longer a blocker for me; I don't need to create fragmentary documents. However, transformiix's current behaviour is incorrect and non-conformant. The spec addresses this in two places, which I quote below for convenience' sake. Now to make a test-case for that position() bug (which is manifesting in a well-formed context)... Steve 3.1 Root Node Children The normal restrictions on the children of the root node are relaxed for the result tree. The result tree may have any sequence of nodes as children that would be possible for an element node. In particular, it may have text node children, and any number of element node children. When written out using the XML output method (see [16 Output]), it is possible that a result tree will not be a well-formed XML document; however, it will always be a well-formed external general parsed entity. 16.1 XML Output Method The xml output method outputs the result tree as a well-formed XML external general parsed entity. If the root node of the result tree has a single element node child and no text node children, then the entity should also be a well-formed XML document entity. When the entity is referenced within a trivial XML document wrapper like this <!DOCTYPE doc [ <!ENTITY e SYSTEM "entity-URI"> ]> <doc>&e;</doc> where entity-URI is a URI for the entity, then the wrapper document as a whole should be a well-formed XML document conforming to the XML Namespaces Recommendation [XML Names]. In addition, the output should be such that if a new tree was constructed by parsing the wrapper as an XML document as specified in [3 Data Model], and then removing the document element, making its children instead be children of the root node, then the new tree would be the same as the result tree, with the following possible exceptions: The order of attributes in the two trees may be different. The new tree may contain namespace nodes that were not present in the result tree.
Fair enough. I will need to change the returned result to a Node, so that is could be a DocumentFragment as well as the normal document....in which case we should be able to output an "xslt root" (ie...not a document) as a well-formed external entity. The caller will need to cast according to the NodeType. So Axel...you can leave it as a bug! ;-) Even though it's an invalid DOM tree, it's a valid "xslt result". --Keith
Not sure how Mozilla should handle multiple root nodes. Leaving open for the standalone. If anyone has ideas for the mozilla module, speak up.
This was fixed in the output rewrite
we didn't verify for a long time. I really checked, so VERIFIED.