This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4353 - [XSLT+XQuery] Identity constraints at element level
Summary: [XSLT+XQuery] Identity constraints at element level
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Don Chamberlin
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-27 16:22 UTC by Michael Kay
Modified: 2007-05-08 20:46 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2007-02-27 16:22:48 UTC
Both XSLT and XQuery state that when validating an element node (as distinct
from a document node), identity constraints specified in the element
declaration are not taken into account.

XQuery says: If the operand node is an element node, the validation rules
named "Validation Root Valid (ID/IDREF)" and "Identity-constraint Satisfied"
are not applied. This means that document-level constraints relating to
uniqueness and referential integrity are not enforced.

XSLT says: Validation of an element or attribute node only takes into
account constraints on the content of the element or attribute. Validation
rules affecting the document as a whole are not applied. Specifically, this
means... The validation rule "Validation Rule: Identity-constraint
Satisfied" is not applied.

In both cases, the reasoning given in the spec is spurious. Identity
constraints (xs:unique, xs:key, and xs:keyref) defined on an element
declaration are not document-level constraints, their effect is local to the
element on which they are defined. It would be perfectly possible to apply
such constraints when validating at element level, and it seems odd that we
should diverge from the XML Schema rules in this regard. There might be some
rationale if we ignored everything on the element declaration other than its
type, but we don't: we take into account properties of the element
declaration such as abstract="true", nillability, and fixed values.

The effect of the omission is that it's very easy to output a document which
appears to have been validated, but which will then fail validation if put
through a free-standing schema validator. This is also true of ID/IDREF
constraints, of course, but in this case there is a solid justification, in
that validation of a non-document element would otherwise give spurious
IDREF errors.

In the XSLT case, it's not entirely clear when this rule applies. Does it
apply, for example where validation is initiated using <lre xsl:type="xxx">?

Michael Kay
Comment 1 Don Chamberlin 2007-05-08 20:46:13 UTC
Michael,
Thank you for this bug report, which was considered by the Query Working Group on April 16, 2007. The working group agrees with your analysis and has decided to apply the following correction, which will be published in a future erratum:

In XQuery Section 3.13 (Validate Expression), Rule 3c, change "... the validation rules named 'Validation Root Valid (ID/IDREF)' and 'Identity-constraint Satisfied' are not applied" to "... the validation rule named 'Validation Root Valid (ID/IDREF)' is not applied". The second sentence in this rule is not affected.

Since you were present during this discussion, I am marking this bug report as Fixed and Closed.

Regards,
Don Chamberlin (for the Query Working Group)