- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 26 Feb 2008 00:20:37 +0000
- To: public-qt-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4869 ------- Comment #22 from chamberl@almaden.ibm.com 2008-02-26 00:20 ------- I was not present at the discussion on 12 Feb 2008, but I must say that I find it very strange for the behavior of a direct element constructor to be influenced by copy-namespaces mode. Consider the following example: <a xmlns:p="uri1">{xs:QName("p:foo")}</a> The user has constructed an element with a namespace binding for the prefix "p". He expects this namespace binding to exist in the constructed element node. He has not copied anything and has no reason to expect copy-namespaces mode to have any influence at all. He expects the following serialized output: <a xmlns:p="uri1">p:foo</a> Instead, the proposal in Comment #20 throws away the namespace binding that the user has specified and generates this serialized output: <a>p:foo</a> I cannot explain to this user why we threw away his namespace binding. I do not think that users are well served by this proposal. I prefer to keep the semantics exactly as currently specified in the language document. Nested direct element constructors do not copy anything, and they are not influenced by copy-namespaces mode. Enclosed expressions, on the other hand, generate references to nodes; these nodes are typically pre-existing and making copies of them is reasonably governed by copy-namespaces mode. The examples in this bug report, in which the entire content of a direct constructor is an enclosed expression containing another direct constructor, are a strange usage. There is no reason to do this. It will never occur in nature. We should not warp our rules on account of this anomalous usage. In particular, we should not throw away namespace bindings that the user has taken the trouble to write.
Received on Tuesday, 26 February 2008 00:20:43 UTC