[jdom-interest] Re: Radical Suggestion

[Dennis Sosnoski]

That's true, accessing elements potentially gets really awkward when 
you're dealing with arbitrary documents that have been read in. So what 
could be done to simplify namespace handling for developers? Maybe a way 
of creating an element without an explicit namespace would help, where 
the element would assume the default namespace of whereever it was put 
into the document. This would at least make document creation easy, and 
would not interfere with building a document from a parse with explicit 
namespaces on every element. This might fall under your case of 
supporting both systems, though.

For the access side, maybe what would really help would be easy ways of 
accessing elements and attributes by local name while ignoring their 
namespaces. I realize that from the XML POV this is a horrible idea, but 
it suits what most developers are doing most of the time. It also 
reflects the way XML is actually used - cases where child elements can 
have the same local name but different namespaces are exceedingly rare 
in practice, as far as I've ever seen.

  - Dennis

Alex Rosen wrote:

>Dennis, 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.)
>
>Alex
>
>  
>