- 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