- From: Michael Kay <mhkay@iclway.co.uk>
- Date: Sat, 24 Feb 2001 17:29:08 -0000
- To: <xsl-editors@w3.org>
Even after the XSLT 1.0 errata, we seem to have the following situation: The following is not an error (because there is nothing that disallows it): <xsl:attribute-set name="aset"> <xsl:attribute name="a">a</xsl:attribute> <xsl:attribute name="a">b</xsl:attribute> </xsl:attribute-set> But the following is a recoverable error: <xsl:attribute-set name="aset"> <xsl:attribute name="a">a</xsl:attribute> </xsl:attribute-set> <xsl:attribute-set name="aset"> <xsl:attribute name="a">b</xsl:attribute> </xsl:attribute-set> because of the sentence, unchanged in the errata, "it is an error if there are two attribute sets that have the same expanded name and equal import precedence and that both contain the same attribute, unless [snip]." I assume "contain the same attribute" means "cause attribute nodes with the same expanded name to be instantiated" (something that isn't known until run-time: which means an implementation that wants to report this error can't merge the attribute sets at compile time). Is this really what is intended? Can anyone imagine a situation in which an implementor would choose to signal the error in the second case, rather than taking the recovery action? I guess there's a rather puritan justification based on the philosophy that any dependency on the ordering of top-level elements is technically an error, but it seems very odd all the same. Mike Kay
Received on Saturday, 24 February 2001 14:08:00 UTC