[jdom-interest] Inconsistancy in Namespace.hashCode().

[Jeff Turner]

On Sat, Mar 03, 2001 at 10:34:08AM -0500, Elliotte Rusty Harold wrote:
> At 2:45 PM -0800 2/28/01, Jason Hunter wrote:
> 
> >Good eye.  I've changed the documentation on my local copy to be:
> >
> >      *  This returns a probably unique hash code for the
> ><code>Namespace</code>.
> >      *  If two namespaces have the same URI but different prefixes, they
> >may
> >      *  have a different hash code.
> >
> >This correctly defines the behavior, and I think the existing behavior
> >is correct.  Anyone (Elliotte esp) have concerns?
> >
> 
> Yes, I disagree. I'm not sure when the mistake got in, but the 
> comment is correct (i.e. it describes the right behavior) and the 
> current code is wrong. Two namespaces are equal if their URIs are 
> equal. The prefix should not be considered when testing for equality.
> 
> I suppose you can argue that two Namespace objects are not equal if 
> they describe different prefixes. Maybe that makes sense, but it 
> makes me deeply uncomfortable.
> 
> I guess the question comes down to what the use case for comparing 
> namespaces is. I would expect that the equals method would let us 
> take two set elements with possibly different prefixes, possibly one 
> in a default namespace, and determine whether or not they have the 
> same type; e.g. are both MathML set elements or is one a MathML set 
> element and one an SVG set element? This only works if we compare 
> based on URI and not prefix.

Hmm.. that's exactly the scenario I find myself in, having parsed a document
like:

<e xmlns="foo" xmlns:gml="foo"/>

I didn't see anything disallowing multiple prefixes in the namespace WD.

Now I'd like the following to be true:
( Namespace.getNamespace("foo").equals ( Namespace.getNamespace("gml", "foo")) )

Does that match most people's expectations?

--Jeff