[jdom-interest] First pass at Namespace revision[eg]

[philip.nelson at omniresources.com]

> A lot of work and thought has gone into making the JDOM API reflect 
> the natural structure of XML documents. This means that if you're 
> using XML the way it was intended to be used, the JDOM approach seems 
> quite natural. However if you have misconceptions about how XML 
> works, e.g. you think that an attribute of an element is in the same 
> namespace as the element is, then JDOM will seem quite difficult. But 
> what you're really encountering is a problem with XML, not with JDOM.

For the record, Jochen appears to have no misconceptions of how xml is
intended to be used.  There will be other valid reasons to change namespace
uri's in the future so this statement really serves to underscore the
problem rather than explain. "If you knew what we meant you would have done
...."

I answer far more questions on JDOM than I have ever asked.  Yet, if *I*
gave this answer, I think it would be insulting.  It has to be clarified.  I
agree that a lot of thought went into how the JDOM api reflects the natural
structure of xml documents including the namespace api.  As a matter of
fact, I went through and read every post on this issue from the archives
this weekend.  I will post possible FAQ entries to explain why the JDOM
authors currently don't think it's a good idea to change namespace uri or to
set the name after an element or attribute is created.  The problem remains
however.  Developers will expect to find a way to change the name, uri or
prefix for documents, particularly ones that are read from storage.  The
*API* provides no hints, no documentation, no clue how to accomplish this.
So a developer will search javadoc (if we're lucky) and not find anything,
the FAQ (if were even luckier) or post to the list.  Depending on who's
reading that day, the developer may or may not get the right answer.  

The intent of the JDOM authors is not something easily conveyed by message
signatures and parameter names particularly when the intent is expressed by
the absense of method calls as it is in this case.  For something as basic
as name, prefix and uri this is unexpected I think.  It's particularly
strange considering how much time we spent arguing about the specific text
to use for getChild() to accomplish a similar end of conveying from the api
directly what is meant to be accomplished.  

I don't think we can ignore this issue forever but I am going to set it
aside other than to summarize for the faq how to handle changing names,
prefixes and uri.  Though other regular contributors have come forward to
say they think this functionality makes sense, I don't think we got critical
mass to require it to happen now.  It is fairly clear to me that the current
api can be extended to support this functionality but it won't be directy
through setNamespace methods on attributes or elements.  The reasons I can
document.  So it *can* wait.