- From: <bugzilla@jessica.w3.org>
- Date: Mon, 27 Apr 2015 08:53:26 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28565 Bug ID: 28565 Summary: [xslt30] The nilled, is-id, and is-idref properties Product: XPath / XQuery / XSLT Version: Last Call drafts Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XSLT 3.0 Assignee: mike@saxonica.com Reporter: mike@saxonica.com QA Contact: public-qt-comments@w3.org The spec for xsl:copy-of says: The new element will have the same values of the is-id, is-idrefs, and nilled properties as the original element. By implication, this also applies to the copy-of() and snapshot() functions. Consider the case with validation="strip". In the case of the "nilled" property this will violate an XDM constraint (XDM 3.1, ยง6.2.1, rule 10) <quote>If the dm:type-name of an Element Node is xs:untyped, then the nilled property must be false.</quote> So if xsl:copy-of sets the type to xs:untyped and the nilled property to true, it is violating an XDM rule. (This appears to be a bug in XSLT 2.0). For is-id and is-idref I don't think we actually violate any constraints, although we do produce surprises. The biggest surprise (which I think we should treat as a bug) is that when you validate a document against a schema defining xs:ID elements or attributes, the id() function doesn't work as expected on the result, because the is-id property is the same as the original node, rather than being based on the result of schema validation. For validation="strip", and for the strip-type-annotations attribute, we consistently say that this does not affect the is-id and is-idref properties. I can't think why! I suspect we don't have any tests for this. It breaks a rule which I thought existed, but which I can't find in the specs, that an element can only have the is-ID property if its typed value includes an item of type xs:ID. For xsl:copy, we appear to have no rule that says what the nilled, is-id, and is-idref properties on the result should be. I think they should depend on the result of schema validation; but that relies on schema validation producing a result, which is not the case at the moment. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 27 April 2015 08:53:28 UTC