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-11-03 18:42 ------- (In reply to comment #36) > 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. > What about my example -> An XML Document cannot contain valid XPath expressions involving the same namespace prefixes as its own nodes, when one of the prefixes is the default namespace. That's ugly. > 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.) > Ummm... why is GUMP failing? Did someone add a test case involving the new method? It was my understanding that if the new method is not called, the behaviour is as before. It doesn't make sense to blame the GUMP problems on this feature, or am I wrong? > 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. > This is not logical from a technical viewpoint. You keep repeating that something breaks, but cannot seem to point out what. The examples with elements and attributes were already refuted earlier in this discussion. So what, precisely speaking, is the problem? Give us a quantitative answer, hard facts, not this wishy-washy "the default namespace is special" stuff. I'm not an idiot. I do spend time reading the specs, trying out code and thinking about the issue. However, I'm also not infallible. I'm totally willing to admit that there IS a real problem, but I won't just take your word for it. You'll have to PROVE it, at least by giving an example. However, I'm also not infallible. I'm totally willing to admit that there IS a real problem, but I won't just take your word for it. You'll have to PROVE it, at least by giving an example. > 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. This I cannot argue with. You're right. By going beyond the spec, you run the risk of bad interoperability for people who decide to use the enhancement. In the XML world, where everything should be interchangeable, this is indeed a bad thing. So maybe you are winning me round - but you still have not shown the actual technical problems with keeping the feature... having people dependent on your feature is not a technical problem. I've thought about my problem, and what I could do, and the answer is actually simple: I can just use an XPath 2.0 Processor, which will do exactly what I want. Now it's just a matter of finding an XPath 2.0 processor :( -> any recommendations? Saxon? Any predictions on when a future JXPath version will implement the 2.0 spec? So, if everyone else agrees with elharo, I am willing to back down and drop the issue, after all there is another solution for me (XPath 2.0), and I am running out of energy to argue this point. In closing, I do want to point out that, as far as I am concerned, the difficulties we have with this feature are organizational and ideological problems, not technical ones. -- 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]
