complaint regarding default namespaces was(RE: [jdom-interest] ge tChild and namespace)

[philip.nelson at omniresources.com]

> There should be some discussion of this, I can't believe we 
> are the only
> people faced with this issue.

I agree.  Researching this led me to the information that finally explained
this bizarre behaviour I have been trying to "fix" (I see now that my
approach was incomplete).  Others have been struggling with this though not
to the degree you would expect I suppose.  Frankly, while the xml world is
driving madly to the namespace aware, schema ready world of someday in the
future, most developers think that simple XML 1.0 is pretty cool.

I need to set this issue aside to get to some other things.  So here is a
summary of the problems I see with the current namespace api.  I am glad I
found Elliote's old post from September on this because without it, I would
probably still be trying to fix something that's not really broken in the
bug sense but is very broken in the api sense IMHO.

NO_NAMESPACE has got to be explained, both in the FAQ and in the api docs.
It means "absense of namespace" in some contexts and "empty namespace" in
the context of a parent element but only while outputting. Actually, I can't
even say off the top of my head what it means in the context of a fully
qualified namespace.  There is no way to tell if it's an empty namespace or
the absense of a namespace by looking at it.  Jason is right, DOM is the
same way except that somehow, magically, it does know the difference when
outputting, or at least Xerces does when using the TreeWalker.  Since
Elliote's point in this approach to a namespace api was to avoid contextual
meaning of the namespace, this seems inconsistent to me.

The term default namespace means something to xml.  It means absolutely
nothing to JDOM.   When an ancestor element declares a default namespace in
xml, it is a contract with it's children as well.  The child is allowed to
assume the default namespace of it's ancestor.  We are instead asking
developers to sign a contract stating they explicity care about each and
every node's namespace.  Break the contract and your code is broken ;^).  We
need to either change this behaviour which as I pointed out yesterday could
break a lot of code, or we need to say LOADLY in the FAQ and javadoc that
jdom does not support default namespaces differently from any other fully
qualified namespace.

One other note regarding Elliote's post on this.  He wonders out loud about
the use case for supporting this feature and for explicitly supporting empty
namespaces (heavily paraphrased and possibly even wrong, I hope he responds
himself).  Here, the use of use cases as a justification is probably wrong.
This to me is more of a compliance issue.  I know we must provide a way to
do everything the specs require.  How you do that can be affected by how it
will be used, but this so basic to xml, I think the api should support
default namespaces the way that xml specs and thus xml developers expect
them to be used.  

When (and if) schemas and all these industry specific vocabularies become
commonly used, an api that handles namespaces easily and the way people
expect them to work will be critical to that api's success.  I really don't
think we have that now in regard to default namespaces.

There, now somebody else can take this up for awhile :-)