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|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
