This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We say in 5.7.1 Constructing Complex Content, rule 9: If an attribute A in the result sequence has the same name as another attribute B that appears later in the result sequence, then attribute A is discarded from the result sequence. A strict reading suggests that the processor is not allowed to perform any schema-based validation on attribute A until it is confident that it will not be discarded under this rule. This also suggests that in such circumstances the processor should not attempt any static validation of the attribute. For example, it appears to be incorrect to report an error for: <e> <xsl:attribute name="a" xsl:type="xs:integer">abcd</xsl:attribute> <xsl:copy-of select="@*"/> </e> until you have established that @* does not contain an attribute named "a". This seems an unreasonable constraint on the implementation which gives no user benefit. It's very unlikely that any users would wish such behaviour or rely on it. I propose that we should add to rule 9. "Before discarding attribute A, the processor MAY perform validation on the value of the attribute and report any validity errors that would arise if attribute B were not present."
The WG discussed this on 21 Jun 2007 and agreed with the general intent but with some reservations as to whether the word "validation" was quite appropriate. Perhaps something like "detecting type errors".
Erratum E10 drafted, using the text: Before discarding attribute <var>A</var>, the processor <rfc2119>may</rfc2119> detect and report any <termref def="dt-type-error">type errors</termref> that would be reported if attribute <var>B</var> were not present.