W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2001

Attribute sets (again)

From: Michael Kay <mhkay@iclway.co.uk>
Date: Sat, 24 Feb 2001 17:29:08 -0000
To: <xsl-editors@w3.org>
Message-ID: <000001c09e95$67d06440$ab2c3c3e@oemcomputer>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT