[jdom-interest] Re: static data needs to be thread data for multithreaded applications

[Peter V. Gadjokov]

>Are you all thinking about using the getDocument to find locate the home
for
>the namespaces and or prefix mappings?  At the time NameSpace was written,
>there was a lot of discussion about the static hashtables but because
nobody
>wanted to maintain parent relationships, there was no way to put namespace
>information in the Document for any given element.  It seems this has
>changed since then.
[...]
>I apologize in advance but I don't understand what you mean by "lack of
>separation between namespace name and namespace declaration".  I think that
>the static variables in Namespace can't work on a server, or at least that
>it's more compromises that it's worth.  It does work in what I think would
>have to be the more common use case of many similar xml documents processed
>by a server app.  My use case is a problem.  I would think that
>serialization would be complicated as well.

By 'separation' I mean having separate classes that represent what the
infoset calls 'namespace name' (basically, just the URI, a globally unique
id that distinguished one namespace from another, regardless of document
context) and a namespace declaration (a namespace, with a document-specific
prefix used for serialization and a document specific scope). 

Namespace names need no centralized static storage. It could be useful if
you want to save memory and it allows identity comparison but the global
storage has other problems (concurrency issues, potential for unbounded
growth, etc). 

Namespace declarations are document-specific so they need no centralized
storage either. The prefix map could live in Document. I think you are
raising the issue of getting the Document if you only have an element -
typically, an Outputter that cares most about prefixes gets the Document so
it doesn't have the problem. The recent change to isRootElement, though,
allows for the addition of a trivial getDocument method on Element which
would simply walk the path to the root until it hits the root element, if
any, and then return the root element's document. 

So, what I'm talking about is this:

 - A Namespace (or NamespaceName) class that is just the URI. This class has
a fast .equals method but does not rely on identity comparison. A sync'ed
Namespace.intern() method can be provided to trade performance for memory,
potentially, the parser can have an option to intern every NamespaceName it
encounters. 

- A NamespaceDeclaration class that is typically stored in an Element. It
describes the binding of a prefix to a NamespaceName and the scope of the
Namespace (which is the inclusive scope of the Element). 

- Facilities on Document and/or Element that let you 
   - look up the NamespaceName given a prefix and a scope (Element)
   - find the in-scope (i.e. both declared and 'inherited'
declarations)NamespaceDeclarations of a given Element

- Magic that shuffles conflicting or redundant namespace declarations when
Elements are moved within or between Documents. This could end up being
somewhat slow. I'd say make it 'deferrable', i.e. allow (optionally?) NS
declarations to be 'out of sync' after a move until something like
Document.notmalizeNSDeclarations() is called. 


If this covers the needs of NS handling (a big if, granted, but if it
doesn't I'm sure we'll hear about it), I don't think it actually needs
global static data anywhere. 

-pvg