generating multiple root nodes fails silently




19 years ago
17 years ago


(Reporter: stinney, Assigned: keith)



Firefox Tracking Flags

(Not tracked)




19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)

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



<xsl:stylesheet version="1.0" 

<xsl:template match="sign">
      <xsl:for-each select="value">
          <xsl:for-each select="vals/val">
            <xsl:value-of select="."/>
        <xsl:for-each select="data">
          <b><xsl:apply-templates select="."/></b>

should be (from Saxon [and XT]):
<?xml version="1.0" encoding="utf-8"?><a>ba</a><b>BA</b>

but tx gives (no <b>BA</ba>)...
<?xml version="1.0"?>


If you remove the first nested for-each, the second is processed

<?xml version='1.0'?>
<xsl:stylesheet version="1.0" 

<xsl:template match="sign">
      <xsl:for-each select="value">
        <xsl:for-each select="data">
          <b><xsl:apply-templates select="."/></b>

<?xml version="1.0"?>

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.

Comment 1

19 years ago
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.

Comment 2

19 years ago
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?


Comment 3

19 years ago
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.

Ever confirmed: true

Comment 4

19 years ago
I upgraded your perms, keith goes to all, jus to CanConfirm.
So Jus, your bugs won't even start unconfirmed anymore.


(assigning this one)

Comment 5

19 years ago
changing severity to normal
Severity: blocker → normal

Comment 6

19 years ago
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">
    <xsl:for-each select="value">

this yields:

<?xml version="1.0"?>

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.



19 years ago
Severity: normal → enhancement
OS: Linux → All
Hardware: PC → All
Summary: a sequence of nested xsl:for-each's loses context → generating multiple root nodes fails silently
Target Milestone: --- → Future

Comment 7

19 years ago
Darn, confirmed a bug that's invalid.
But I don't like invalid, so I will not mark this one invalid, but change the
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.


Comment 8

19 years ago
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?

Comment 9

19 years ago
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".



Comment 10

19 years ago
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

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)...


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">

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.

Comment 11

19 years ago
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 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 can leave it as a bug! ;-) Even though it's an invalid DOM tree, 
it's a valid "xslt result".

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
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 years ago
we didn't verify for a long time.
I really checked, so VERIFIED.
You need to log in before you can comment on or make changes to this bug.