DO NOT REPLY [Bug 32360] - Default Namespace not handled correctly
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-01-17 21:03 --- Richard, Here's a question for you: Let's say I have a file that looks like this: ?xml version=1.0 encoding=iso-8859-1? parent test xmlns=http://test; child-element / /test /parent How do I access the child-element in this situation. If I declare context.registerNamespace(null, http://test;) and then try: context.getValue(/parent/test/child-element) I get nothing, because parent does not have http://test; as its namespace. In other words, as soon as I introduce a mapping for the empty prefix I seem to lose the ability to access nodes that really don't have any namespace. Does this make sense? How should we resolve this conundrum? Thanks, - Dmitri -- 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]
DO NOT REPLY [Bug 32360] - Default Namespace not handled correctly
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | -- 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]
DO NOT REPLY [Bug 32360] - Default Namespace not handled correctly
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 [EMAIL PROTECTED] changed: What|Removed |Added Severity|normal |enhancement --- Additional Comments From [EMAIL PROTECTED] 2005-01-07 00:55 --- Sorry to annoy you about this again, but I have been thinking about it, and decided that I feel strongly enough about it to give it another try... While I cannot argue the point about what the XPath specifications say, I feel this is not enough reason to discard out of hand setting a no-prefix namespace for JXPathContexts. After all, both XSLT 1 and 2 behave in the way I describe (at least xalan and saxon do) - you can set a no prefix namespace in the XSL document and the xpath expressions in the XSL will be correctly evaluated against XML elements of this namespace. Not permitting this feature limits JXPaths usefulness, particularily when attempting to process XML documents in an automated way, where the XPath expressions do not come directly from handwritten code, but rather are extracted from some other document, or input by the user. Finally, I must admit that while I did not consult the XPath spec in advance before submitting the bug, intuitively most programmers would expect it to work with no-prefix namespaces, the same way as XPath in XSLT. I beg you to reconsider your decision, esp. since I believe it would be a very simple change in the code - just permit NULL or the empty string to be registered as a prefix, and interpret this as the no-prefix namespace. -- 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]
DO NOT REPLY [Bug 32360] - Default Namespace not handled correctly
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-11-26 21:05 --- I really don't think this is a bug, and the solution that you have in the bug description is the correct one. Here's a quote from the XPath specification: 'A QName in the node test is expanded into an expanded-name using the namespace declarations from the expression context. This is the same way expansion is done for element type names in start and end-tags except that the default namespace declared with xmlns is not used: if the QName does not have a prefix, then the namespace URI is null (this is the same way attribute names are expanded). It is an error if the QName has a prefix for which there is no namespace declaration in the expression context.' See: http://www.w3c.org/TR/xpath.html#node-tests -- 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]
