- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 04 May 2005 19:47:03 +0000
- To: public-qt-comments@w3.org
- Cc:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=1306 Summary: Construction mode preserve with copy-namespaces no- preserve Product: XPath / XQuery / XSLT Version: Last Call drafts Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: XQuery AssignedTo: chamberl@almaden.ibm.com ReportedBy: mike@saxonica.com QAContact: public-qt-comments@w3.org 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
Received on Wednesday, 4 May 2005 19:47:18 UTC