[jdom-interest] Is JDOM dying?

[Malachi de AElfweald]

On Sat, 15 Mar 2003 10:23:14 -0700, Alex Rosen <arosen at novell.com> wrote:
> But after we flamed about it on this list for a long time (one of
> several times that we did this), I realized that the current JDOM system
> is the best system, or maybe just the least bad:

That was how it came up again. I made an off-hand comment that I don't have
this kind of problem with JAXB.

>> I have a lot of sympathy for your suggestion when it comes to
>> creating documents. Basically it sounds like you're suggesting using
>> namespace declarations instead of namespaces in the API. This is how a
> lot
>> of people tend to think of it, and it's not at all inconsistent with
> XML if
>> you describe it in that way. However, when reading documents instead
> of
>> creating them, this model falls apart. To read a document correctly,
> you
>> absolutely want to look at the namespace, not the namespace
> declaration. In
>> this case, people who want to do getChild("name") to find a child
> that's in
>> the default namespace are simply wrong; it'll work fine most of the
> time,
>> but then they'll run in to a document that declares its namespaces
>> differently but is logically equivalent, and it'll fail. To me this is
> proof
>> enough that we've got the right API, even though it may be confusing
> to
>> people at first. (I suppose we could support both systems, one for
> reading
>> and one for creating, but that seems way worse.)

That does not follow with the majority of Java APIs. If I have an Element
in namespace NS1, and I call getChild("name") on that, it should ASSUME 
that
I want NS1 unless I say getChild("name", otherNS) -- why? because XML 
inherits
namespaces.

But if I understand you, I think you are right about the namespace 
declarations.
I originally tried adding it as an attribute (like I saw in the text format 
I was
duplicating), then had to search the list to figure out why it didn't work. 
 Then,
I tripled my code length, and now it works.  Unfortunately, I am not going 
to change
every single method of the application AND the reusable modules, so, I had 
to take
Namespaces out to continue to ship our product.

>> I think a big problem is that it's easy to confuse the concepts of a
>> namespace and a namespace declaration. What you see in an XML document
> is
>> the namespace declaration, and even if you know how namespaces work
> it's
>> easy to space out and think that the parent element has a namespace
> but the
>> child doesn't. Pointing this distinction out in a few more places in
> the
>> JavaDoc might help.

What I think is more confusing is when you do something like:
Element rootElem = new Element("myName", myNS);
Document doc = new Document(rootElem);
then output it, and have a ns="" in the XML output. I never told it to do 
that.
It is because JDOM doesn't want to call super.getNamespace() if it is null
that this problem exists.  I read the complaints on the list saying that it 
would
be too big of a performance hit, but I have lots of Swing extensions that 
do this
with no noticeable degrade in performance (like Filesystem handling).  The 
choice
was made (said so on the list) to choose performance over correct 
functionality.
I think it was the wrong choice, but the fact is that choice was made.

> As I mentioned above, an API that works on the textual representation
> of an XML document works fine for writing, but is wrong for reading.

I don't agree. I can set the namespace in JAXB on the root node
right before outputting it. Again, that is what brought this discussion up 
again.

> There are many different textual XML files that correspond to a given
> logical XML document, and your system would force the user to do a lot
> of checks, running up and down the document, to figure out which
> namespace the element is *really* in. (Plus, as Philip points out, I
> think that SAX wouldn't let us do this even if we wanted to.)

On the contrary. The user would do no such code. And, their Namespace'd 
version
of the code would be almost identical to the non-Namespace'd version -- 
which it
isn't now. It doubles or triples the code to add Namespaces to my 
application with
JDOM right now.  Seems like that would be more of a performance hit than
	if(ns == null) return super.getNamespace()
in the actual API.


Malachi