- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 19 Oct 2006 09:05:40 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3849 ------- Comment #1 from mike@saxonica.com 2006-10-19 09:05 ------- Allow me to attempt a personal response, since the WG seems to have appointed me kicking and screaming into the unsolicited role of chief namespace guru. Firstly, is the current text clear? I think it is. Section 4.9, describing the copy-namespaces declaration in the prolog, states clearly what its effect is on the static context. It clearly states that it sets the "copy-namespaces mode", and gives some helpful cross references as to where this is used. Copy-namespaces mode is used only in section 3.7.1.3, clause 1.e.ii.D, where it explains the effect on "copied element nodes". Clause 1.e.ii starts "For each node returned by an enclosed expression, a new copy is made of the given node and all nodes that have the given node as an ancestor, collectively referred to as *copied nodes*. " I think that this clearly explains what is meant by "copied nodes" within the body of this clause. I agree it's not easy reading. Nothing to do with namespaces ever is. And I can appreciate the cause of the misunderstanding: your example doesn't feel like one that is copying anything, so it's not intuitive that a declaration that talks about copying is actually relevant. But I don't think we're suddenly going to make namespaces comprehensible to the average punter (who doesn't read textbooks, let alone the spec) just by choosing a more judicious keyword, even if we could come up with one. Now to your suggested 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. I'm afraid it's not at clear to me how such a change could be defined, even if it were desirable. XQuery is an expression language, with orthogonality as one of the design aims: the treatment of nodes in the result of an enclosed expression should therefore not depend on how and when those nodes were created, or on the syntactic form of the expression that created them. Is a change to the semantics desirable? It seems to me that "copy-namespaces no-preserve" is a statement that you don't want namespace declarations on an element unless they are actually needed on that element. So in your example, you got exactly what you asked for. You didn't have to ask for it. I do think (and I have argued this in the working group) that finer control over construction of namespace nodes will be needed by some users. A global switch at the prolog level is really too crude. A lot of people scream at me when I suggest this, because they say (rightly) that it's quite complicated enough already. But in XSLT 2.0, in the light of user experience, we added copy-namespaces="yes|no" at the level of an individual instruction, and we added an xsl:namespace instruction to construct individual namespace nodes dynamically; I think that field experience with XQuery will reveal the same requirements. But this is definitely for consideration only in a future version. I will recommend to the WG that we close this with no action, and I would appreciate your concurrence with this.
Received on Thursday, 19 October 2006 09:05:52 UTC