DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32360>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32360 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-31 20:03 ------- I think perhaps our disagreement is caused by a difference in vocabulary... In the context of this bug, I have been referring to the 'default namespace' meaning the 'no namespace', as in the namespace of element a in the following example: <a> <b xmlns="http://foo"/> </a> While element b has namespace 'http://foo', element a has NO namespace. This is what I (perhaps incorrectly) have been referring to as the default namespace. Perhaps I should correctly call it the 'no namespace'. In any case, I don't care about the no namespace, except that it should be possible in some way to assign a prefix to it so that xml documents entirely without namespace declarations can still somehow be matched. The concept you refer to as the default namespace I have been calling the default prefix. Lets call it default namespace, from now on. So the example you provide: > <test xmlns="http://test";> > <child-element xmlns="http://www.example.org/"; /> > </test> then has NO elements in the no namespace and two elements with a default namespace. This is still no problem in my proposal. All I was suggesting is that you could (only if you wanted to) assign one of the namespaces to the default prefix (ie null). Since the nodes have different namespaces, you will have to assign the second default namespace to a non-null prefix in order to construct an xpath expression that involves both nodes. But there is no confusion here. As for your example with the attribute: > <test xmlns="http://test"; foo="bar"/> there are also no problems. The namespace spec clearly states that the default namespace does not apply to attributes. Hence the foo attribute is not even technically in the http://test namespace. The same is true for the xpath expression involving @foo -> the default namespace does not apply to it either, since it is an attribute. So @foo will match the attribute, as it should. Perhaps part of the problem is that the XPath 1.0 spec says: "A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context." but also says: "Expression evaluation occurs with respect to a context. XSLT and XPointer specify how the context is determined for XPath expressions used in XSLT and XPointer respectively." Perhaps part of the problem is that we are now using XPath in ways other than XSLT and XPointer, and thus need to reevalute which namespace mappings are used in the expression context... You say the following: > There are no deficiencies in XPath namespace handling. XPath 1.0's > namespace handling is complete. Nothing is missing. Nothing extra is needed. Well that's just your opinion. And since there is an XPath 2.0 spec, which goes beyond what's in XPath 1.0, I'd say there are some other people with differing opinions. Consider again my example from above, which to me sums up the problem very elegantly: <doc xmlns="http://a";> <item id="123">...</item> ... (more content) ... <itemref xpath="//[EMAIL PROTECTED]"/> ... (more content) ... </doc> The fact that this construction is 'illegal' is a problem, because it is the most natural way to write it. The fact that the following would actually be necessary: <doc xmlns="http://a"; xmlns:foo="http://a";> <item id="123">...</item> ... (more content) ... <itemref xpath="//foo:[EMAIL PROTECTED]"/> ... (more content) ... </doc> is klunky, ugly, more verbose, and counterintuitive. And since it is easily fixed, it should be. That is my whole point. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
