- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 18 Oct 2006 22:23:43 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3849 Summary: [XQuery] Copied nodes and in-scope namespaces Product: XPath / XQuery / XSLT Version: Candidate Recommendation Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: XQuery AssignedTo: chamberl@almaden.ibm.com ReportedBy: hrennau@yahoo.de QAContact: public-qt-comments@w3.org This comment refers to the scope of the concept „copied nodes“ and, in consequence, to the control of in-scope namespaces of constructed nodes. Two alternative changes of the specification are proposed, one merely editorial, the other changing semantics. The proposals are preceded by a motivation. Motivation The concept of “copied nodes” is crucial to the control of in-scope namespaces. The term is quite suggestive and seems to distinguish nodes copied into the result from those constructed within the query. However, of course, the scope is broader, including any node added to the content of a constructed element or document node by evaluating an enclosed expression. In consequence, any constructor occurring between curly braces (either delimiting an enclosed expression, or a function body) contributes to the result a copied node (or no node at all, depending on context). In particular, it holds that the descendants of constructed document nodes and of computed element nodes are necessarily copied nodes. Example: the query declare copy-namespaces no-preserve, inherit; declare namespace ns1=”example.ns1”; document { <a xmlns:ns1=”example.ns1”> <ns1:b>bla1</ns1:b> <ns1:b>bla2</ns1:b> <ns1:b>bla3</ns1:b> </a> } produces the output: <a> <ns1:b xmlns:ns1=”example.ns1”>bla1</b:ns1> <ns1:b xmlns:ns1=”example.ns1”>bla2</b:ns1> <ns1:b xmlns:ns1=”example.ns1”>bla3</b:ns1> </a> So the copy-namespaces settings have a broader scope than perhaps generally appreciated. Checking several textbooks, I did not find any hints to this matter, so I believe the specification should strive at clarification. Please kindly consider the two proposals meant as alternatives. Alternative A: editorial change To enhance clarity, the term “copied nodes” may be linked to an explicit definition, rather than be introduced in running text, and this definition may be supplemented by a note emphasizing the “true” scope of the term. Alternative B: semantic change It may be considered if the present scope of “copied nodes” should be restricted to what the term suggests, that is, exclude nodes constructed within the enclosed expression and delivered into the result by the constructor expression itself, rather than by reference via variable or path. (Treatment of nodes created within functions would deserve special thought.) Afterword: I apologize for the great length of this comment. What I have in mind is that the inadvertent “disappearance” of a namespace declaration attribute (e.g. effected by “no-preserve”, the setting recommended by an excellent textbook) can lead to a proliferaton of namespace declaration attributes further down in the tree, exploding the size of the result and spoiling its readability.
Received on Wednesday, 18 October 2006 22:23:47 UTC