This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
In fact, the statement in xsl:copy-of saying that the is-id and is-idref properties are retained contradicts what section 24 (Validation) says. Section 24 defines validation="strict" and validation="lax" by reference to the rules in XDM "construction from a PSVI", and these rules cause the is-id and is-idref properties to be set "as expected". So I think the statement in xsl:copy-of needs to be corrected. This leaves open the question of whether validation="strip" should leave the values unchanged, as we now say, or whether it should set them to false.
I note also in passing that the specs for xsl:copy-of, xsl:copy, copy-of(), and snapshot() (when applied to a document node) do not say whether or not its unparsed entities are copied.
Noted also that the rules for "constructing complex content" say nothing about the way these properties are set in the result.
For reference, the XQuery rules analogous to our "constructing complex content" are in 3.9.1.3 clause 1(e)(iv)(C), and in effect say that if construction mode is preserve, the property values are preserved, and if construction mode is strip, they are set to false, with an exception for attributes named xml:id.
My proposal is as follows. 1. Unparsed entities should be copied whenever a document node is copied using xsl:copy-of, xsl:copy, copy-of(), or snapshot(). NOTE: document nodes are never copied in the course of "constructing complex content". RATIONALE: better to retain the information than to lose it. In xsl:merge, this is the only way the application will have access to the unparsed entities, since only copied information is available. NOTE: previous versions left this question unanswered. 2. Whenever nodes are constructed with validation="strict" or validation="lax", the is-id, is-idref, and nilled properties are as determined by the XDM rules for "construction from a PSVI". NOTE: this is the status quo, though the spec doesn't make it very clear, and xsl:copy-of says something contradictory. We should add explicit mention of this in 24.4 Validation, and remove the contrary statement from xsl:copy-of. 3. When element or attribute nodes are deep-copied using validation="preserve" (explicitly or by virtue of default-validation), the values of is-id, is-idref, and nilled remain unchanged. This includes xsl:copy-of with validation="preserve" either explicitly or through default-validation, xsl:copy on attribute nodes, fn:copy-of(), fn:snapshot() (for nodes "below the pivot). NOTE: this is the status quo, and appears unproblematic. It needs to be clarified in the text. 4. When element nodes are deep-copied using validation="strip" (explicitly or by virtue of default-validation or strip-type-annotations), the value of "nilled" is set to false. NOTE: This is what we currently say in 24.1.1, though it conflicts with a statement in xsl:copy-of. It is necessary in order to avoid violating an XDM consistency constraint, which states that an element with type xs:untyped will always have nilled=false. NOTE: this rule also applies implicitly to elements copied using xsl:copy validation="preserve". 5. When element or attribute nodes are deep-copied using validation="strip" (explicitly or by virtue of default-validation or strip-type-annotations), the values of is-id and is-idref are left unchanged. NOTE: this rule might be questionable, but it is clearly stated in the 2.0 spec, and has value in the case where the is-id and is-idref properties were DTD-derived. 6. When nodes are copied in the course of "constructing complex content" (section 5.7.1 rule 10), the rules are effectively determined by section 24.4, although this isn't clear because there is no cross-reference. In effect, the validation applied to the newly constructed element (or document node) is also applied recursively to it children, and this includes validation="strip" or "preserve". We should add a note to this effect. NOTE: there is a difference from XQuery, in that XQuery with construction mode strip will drop is-id and is-idref properties except in the case of xml:id attributes.
As discussed during today's telcon, the proposal in comment#5 has been ACCEPTED. See minutes for decision (though no changes have been made to the proposal): https://lists.w3.org/Archives/Member/w3c-xsl-wg/2015Jun/0011.html (member only).
The change has been applied