commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 32360] - [jxpath] Default Namespace not handled correctly
Date Thu, 03 Nov 2005 09:52:53 GMT
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


elharo@metalab.unc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Additional Comments From elharo@metalab.unc.edu  2005-11-03 10:52 -------
The bottom line is that there is no need for this feature. None. Zip. Zero.
Zilch. Nada. XPath 1.0 and JXPath fully handle all use cases without any
registerDefaultNamespace method or anything of the sort. The one project that
thought they needed this feature in JXPath has now realized they can use regular
XPath 1.0, and they are in fact doing so. The absolute best you can say about
these methods is that they are redundant and unnecessary. They add complexity to
the API for no gain. 

That's the best. What's the worst? First of all these methods are buggy, even on
their own terms. GUMP has been failing JXPath for the last few days over
precisely this. (If nothing else, that justifies me reopening this bug.) The
GUMP failure is probably not hard to fix, but there's a deeper problem here the
implementation does not yet recognize. Elements and attributes are not treated
the same with respect to the default namespace. I strongly suspect this has not
yet been tested or handled properly. (I'm not absolutely sure since there seems
to be something funny with CVS. The repository there does not seem to reflect
the updates discussed here.) 

The default namespace is special. It is not treated the same as an empty prefix.
This isn't XPath 1.0, by the way. It's even deeper. This is how Namespaces in
XML is written irrespective of XPath. The current problems with registering a
default namespace for both elements and attributes could be fixed, but it would
be quite tricky to do right, and would significantly complexify the code base. 

Finallly, and most importantly, providing these methods encourages developers to
do the wrong thing. It teaches them that XPath 1.0 behaves in a way it doesn't.
The proper reponse to developer confusion about these issues is to teach them
the right way to handle namespaces in XPath 1.0 via a FAQ, JavaDoc, and the
like. It is not to cater to their misconceptions. Allowing developers to
continue in their mistaken beliefs causes problems for other products that do
correctly implement XPath 1.0. Rather than learning the way XPath 1.0 works in
XSLT, Jaxen, AJAX, XPointer, and a dozen other things, developers will instead
grow accustomed to JXPath's pseudo-XPath and expect the other products to
provide the unnecessary feature as well. Embracing and extending an open spec is
a bad idea no matter who does it. 

-- 
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message