This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
One of my users is struggling with the problem of how to use XQuery to make an amended copy of elements with namespace-sensitive content. It really isn't easy (in fact, I don't think it's possible in general); but that's a subject for vendor extensions now and for XQuery 1.1 in due course. Meanwhile, there's a situation that the spec doesn't seem to address. Consider the construct element { node-name($t) } { $e/@*, $e/* } where construction mode is preserve, and one of the attributes is typed as a QName. I think this should give error XQTY0086. But the current description of XQTE0086 is too narrow. It says: <quote> It is a type error [err:XQTY0086] in this case [where copy-namespaces mode specifies no-preserve] if the typed value of the copied element or of any of its attributes is namespace-sensitive. </quote> But in this example the namespace-sensitive attribute does not belong to a copied element, and that's a problem regardless of the copy-namespaces mode. The equivalent XSLT error condition is wider: <quote> [ERR XTTE0950] It is a type error to use the xsl:copy or xsl:copy-of instruction to copy a node that has namespace-sensitive content if the copy-namespaces attribute has the value no and its explicit or implicit validation attribute has the value preserve. It is also a type error if either of these instructions (with validation="preserve") is used to copy an attribute having namespace-sensitive content, unless the parent element is also copied. A node has namespace-sensitive content if its typed value contains an item of type xs:QName or xs:NOTATION or a type derived therefrom. The reason this is an error is because the validity of the content depends on the namespace context being preserved. </quote> I think this needs a new clause, perhaps between D and E, along the lines: <proposed> D2 If construction mode is preserve, and the value of an enclosed expression includes an attribute node whose typed value is namespace-sensitive, then error [err:XQTY0086] is raised. </proposed>
Probably the only way out, but the implied restriction is a pity: a general impossibility to incorporate detached namespace-sensitive attributes during construction. An alternative which comes to mind is probably unacceptable, but let me nevertheless describe it: to accept the attribute without error IF the in-scope namespaces of the receptor element include a namespace binding matching the namespace binding implied by the QName/Notation value. Thus one could "prepare" the receptor, if necessary. An obvious problem however would be that the receptor's namespace bindings themselves are only finalized by analyzing the attributes (3.7.4). Thus we would get an unpleasant mixture: some attributes creating namespace bindings, and others requiring them.
The fix for this bug does not appear in the Recommendation of 23 January 2007. It will be considered for a future publication (either an Errata document or some possible future version of the specification).
Michael, The Query Working Group has discussed your comment and agreed to add a new rule in Section 3.7.1.3, following the current Rule 1.e.ii.D, as follows: An enclosed expression in the content of an element constructor may cause one or more existing nodes to be copied. Type error XQTY0086 is raised if: (a) An element node is copied, and the typed value of the element node or one of its attributes is namespace-sensitive, and construction mode is preserve, and copy-namespaces mode is no-preserve. (b) An attribute node is copied but its parent element node is not copied, and the typed value of the copied attribute node is namespace-sensitive, and construction mode is preserve. (NOTE: Explanation of XQTY0086: It is not possible to preserve the type of a QName without also preserving the namespace binding that defines the prefix of the QName.) This new rule (and related editorial changes) will appear in a future XQuery errata document. Since you were present for the discussion of this bug report, I have marked the report as Fixed and Closed. Regards, Don Chamberlin (for the Query Working Group)