This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We allow a query to run with construction mode preserve, and copy-namespaces mode no-preserve. This means that type annotations are preserved, but in-scope namespace bindings are not preserved. As a consequence, it is possible for a copied element or attribute of type QName to lose its namespace bindings. This would mean that the element or attribute would not (after copying) be a valid instance of its type. In principle it would be possible to reinstate these lost namespace bindings by extending the namespace fixup process described in 3.7.4 (in-scope namespaces of a constructed element). However, this would mean that copy operations could not be pipelined, because the new inscope namespaces to be added to the tree have to be added before the values that refer to those namespaces. In XSLT we have decided to ban the combination of copying type annotations without copying inscope namespaces, and I commend the same solution to XQuery. Another solution would be to say that if this combination is chosen, any type annotation that identifies a namespace-sensitive type should cause the relevant value to be revalidated against that type, with a dynamic error resulting if it is invalid. This would make the combination viable provided (a) there is no namespace sensitive content, or (b) the user ensures that the required namespaces are present in the result tree (not easy to do without a computed namespace node constructor, but that's another story). Michael Kay
At the face-to-face meeting in May, the XQuery WG decided that disallowing the combination of copying types without copying namespaces was too severe a restriction, and asked XSL WG to reconsider its decision on bug 1235. This the XSL WG did at its telcon on 9 June. The XSL WG decided they did not want to introduce namespace fixup for this case, because of the impact on streaming processors, but decided that rather than having a static restriction, there should be a dynamic restriction: if copying of type annotations is requested, and copying of namespaces is not requested, then it should be a dynamic error (probably a type error) if the node being copied actually contains namespace-sensitive content. It seems to me a reasonable restriction that if you copy namespace-sensitive content then you should also copy the namespaces. This solution appears to deal with the XQuery WGs valid objections that the proposed restriction was too severe, while also dealing with the XSL WG's concerns about streaming implementations. (There remains one difficulty: XQuery only allows the copy options to be selected at the module level, and it's a bit onerous to have to put an expression in a separate module just because different copy options are required. However, that's not a new problem caused by this change, and it can be solved quite independently of this change.) The detailed proposal is now: Change 3.7.1.3 1.e.ii.D.I from If copy-namespaces mode specifies preserve, all in-scope-namespaces of the original element are retained in the new copy. If copy-namespaces mode specifies no-preserve, the new copy retains only those in-scope namespaces of the original element that are used in the names of the element and its attributes, and in the typed values of the element and its attributes if these are namespace-sensitive. Values are namespace-sensitive if they include an item that has a dynamic type of xs:QName or xs:NOTATION or types derived by restriction therefrom. to If copy-namespaces mode specifies preserve, all in-scope-namespaces of the original element are retained in the new copy. If copy-namespaces mode specifies no-preserve, the new copy retains only those in-scope namespaces of the original element that are used in the names of the element and its attributes. It is a type error [ERRxxxx] in this case if the typed value of the element or of any of its attributes is namespace-sensitive. Values are namespace-sensitive if they include an item that has a dynamic type of xs:QName or xs:NOTATION or types derived by restriction therefrom. Michael Kay
Mike, The XQuery working group discussed this comment at its meeting on June 29, 2005 and accepted your revised proposal. I have implemented the revision and therefore I am marking this bug report as Fixed and Closed. Regards, Don Chamberlin