Nick,
you are right that the specification is all too often somewhat
ambiguous. But in this case, I think it would make little sense to only
forbid adding attributes after _all_ children have been added. On the
other hand, the requirement that all attributes have to be added first
corresponds well to the notion of document order, in which "The
attribute nodes and namespace nodes of an element occur before the
children of the element." [XPath]. This is just to explain why we
preferred this particular interpretation of the spec.
Best,
Tom
> >The XSLT spec, section 7.1.3 says:
> >"The following are all errors:
> >Adding an attribute to an element after children have been added to it;
> >implementations may either signal the error or ignore the attribute.
> >[...]"
> >So version 0.36 behaved incorrectly since it accepted the attribute
> >without any error.
>
> One note however, specification talks about "children" - not the first
> child. How can you be sure there is no other children nodes till you read
> closing tag.
>
> You could have something like
>
> <option value="FL">Florida
> <xsl:attribute name="selected">selected</xsl:attribute>
> The Sunshine State
> </option>
>
> where "The Sunshine State" is another text mode or even another child
> element:
>
> <option value="FL">Florida
> <xsl:attribute name="selected">selected</xsl:attribute>
> The Sunshine State
> <alt-name>Fla</at-name>
> </option>
>
> I see your point and I am not saying I am right. It's spec's flaw that it
> allows too many interpretations.
>
> It might be good idea to enforce handling all the attributes first but the
> spec does not say that clearly - seems to me.
>
> NS.
