Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: bugzilla@apache.org
To: commons-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 32360]  -
    [jxpath] Default Namespace not handled correctly
Message-Id: <20051103174303.5CF5F232@ajax.apache.org>
Date: Thu,  3 Nov 2005 18:43:03 +0100 (CET)

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