W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2008

[Bug 4869] [FS] Enclosed expressions and namespaces

From: <bugzilla@wiggum.w3.org>
Date: Tue, 26 Feb 2008 00:20:37 +0000
To: public-qt-comments@w3.org
Message-Id: <E1JTnYj-0000tp-KV@wiggum.w3.org>


------- 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:


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:35 UTC