[jdom-interest] JDOM && Jaxen

[bob mcwhirter]

On Wed, 1 Aug 2001, Elliotte Rusty Harold wrote:

> At 2:59 PM -0400 8/1/01, bob mcwhirter wrote:
> >Yah, even without getParent(), though, not using flyweights on the
> >Namespaces would help.
> >
> >In a given document, how many times do you typically see the exactly
> >same namespace decl?  Is it worth the overhead of flyweighting them?
> >
> 
> Please distinguish between namespaces and namespace declarations. Which
> one is causing you trouble? The reason JDOM flyweights namespaces
> is because every element and some attributes has a namespace
> object. Namespaces are not just attached to the elements where you find
> xmlns atttributes. The memory overhead is significant.

Yes, to be accurate, it's purely namespace declarations I'm looking
for. 

For example, in EXML, which doesn't have any objectification of
Namespaces, I just query the attribute list for those with a
prefix of 'xmlns'.

In dom4j and jdom, getAdditionalNamespaces() certainly helps.
But, unfortunately, two different decls on two different
elements might produce the same Namespace object, while they
are clearly, well, two different decls that just happen to
be semantically the same.  The fact that they are, in terms
of actual object instances, the exact same object, is what's
causing the problems.  

EXML maintains two semantically equal, but non-identical
namespace decls as two distinct Attribute objects.

dom4j handles it by providing a way (I haven't researched exactly
what's going on) to provide the previously flyweighted Namespace
object as a unique instance, causing the two decls to be two decls,
but the namespaces actually still shared with regards to association
with an element.

As I see it, we have basically 3 scopes of namespaces:

	1) The namespace of some Element ( Element.getNamespace() )
		-- This may have been declared on that Element, or some other

	2) The namespace declarations of some Element ( Element.getAdditionalNamespaces() )
		-- None of these declarations are required to be related
		   in any form, to the namespace of the Element
		   (see (1) above).  

	3) The complete set of all prefix->URI mappings in scope of ( Element.getNamespace(prefix) )
	   the current Element.
		-- This will always include at least the namespace
		   of the element itself (see (1) above), and of
		   all other namespaces declared on that Element
		   (see (2) above), and possible a subset of all
		   decls of all ancestors. 

Specifically, I'm looking for (2), in such a way that I somehow
get 1 distinct object per namespace declaration.  That's the rub.

	-bob