- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 23 Oct 2006 15:40:23 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3849 ------- Comment #3 from mike@saxonica.com 2006-10-23 15:40 ------- >>(a) on first glance only those nodes of the expression result need to be actually copied – rather than taken as is and simply attached to their new parent – which existed prior to the expression evaluation (typically: nodes of an input document); (b) however, this amounts to treating the nodes differently according to information not contained in static/dynamic context and node properties, thus braking a key principle. I think you're confusing the language semantics and the behaviour of an actual implementation. Implementations can often avoid making an unnecessary copy; optimizers can use any information they want to make the code faster (of course, if they don't make a copy, then they must behave exactly as if they did). That doesn't affect the language semantics and doesn't break any language design principles. >>At any rate, the real issue is, as you pointed out, fine-grained control of the namespaces policy.... If your result document contains QNames in content, you need to use copy-namespaces preserve. If it doesn't, you can safely use no-preserve. I think that's a fairly simple rule. It's true that a consequence of using no-preserve is that namespaces may be declared further down the tree than you would like, from the point of view of minimizing clutter in the serialized document. But that's largely aesthetic, it doesn't affect whether downstream applications using the XML work or not. >> Finally, I do not agree that a clarifying note concerning the scope of the copy-namespaces declaration is superfluous. You are right in this: the present text is absolutely clear and unambiguous. But the real problem... We're writing a specification, not a tutorial. We've always taken the view that it's not the job of the language specification to give advice and education. If existing textbooks aren't good enough, that's hardly surprising given that the specification is not yet frozen. I'm sure good books will appear in time. I might even write one myself. >> I suggest a short note in Section 4.9: ... I'll leave that one for the editor to respond to. Logistically, it's not a good time to be making editorial improvements at the moment. Michael Kay personal response
Received on Monday, 23 October 2006 15:40:34 UTC