Radical Suggestion (was Re: Antwort: RE: [jdom-interest] Namespace help)

[Dennis Sosnoski]

Most APIs take the approach of making the common cases easy for the 
developer, even when they allow full access to the underlying details 
and special cases. This doesn't make them wrong; it just means that 
they're designed with developers in mind.

The XML spec deals with interpreting text documents, and makes certain 
requirements of programs that process XML. The Namespaces spec adds 
another layer of interpretation on top of XML. The DOM spec defines a 
particular model (actually several more-or-less compatible models) for 
representing XML documents as structures of objects. There is nothing 
sacred about this particular representation - if there *were*, JDOM 
would be a misguided effort from the start, since it does not follow the 
DOM model and associated API. Applications are free to use any 
representation they find convenient for working with XML internally, so 
long as they convert properly to and from text. If JDOM were to 
implement a different way of handling namespaces internally, this would 
not take it out of compliance with the XML spec.

The suggestion I made would bring JDOM manipulation of the document 
representation in line with what happens when you edit the text of a 
document - namespaces don't magically move along with the elements when 
you cut and paste them in a text editor, after all. This seems to be 
what most developers intuitively expect to happen, and it's generally a 
good thing for APIs to match developers' expectations. Insisting that 
the JDOM model rigorously and literally reflect every ugliness of the 
various specifications doesn't really contribute to making it "provide a 
solution for using XML from Java that is as simple as Java itself" 
(http://www.jdom.org/mission/index.html).

  - Dennis

Elliotte Rusty Harold wrote:

> At 10:43 AM -0700 7/25/02, Dennis Sosnoski wrote:
>
>
>> If JDOM's goal is ease of use it seems like matching the programmer's 
>> POV rather than the XML POV would be the right way to go.
>
>
> No. This is the ElectricXML fallacy. An API for processing XML should 
> be as simple as it can be and no simpler! In particular, it cannot be 
> simpler than XML itself is. Namespaces are confusing, but that is not 
> our fault and not something we can fix in JDOM.
>
> This whole thread made it obvious that the developer did not 
> understand how namespaces worked in pure XML syntax, in  a plain text 
> document, without JDOM anywhere in sight. That's not really his fault. 
> Namespaces are a mess. However, since we need to faithfully model XML, 
> we need to model that mess. If we can make it easier and remain 
> faithful to the namespaces and XML specs, great; but we can't do 
> anything that flies in the face of those specs. If a programmer has 
> trouble with JDOM because they don't understand namespaces, better 
> they encounter cognitive dissonance as quickly as possible so they'll 
> fix the flaws in their understanding rather than have JDOM reinforce 
> their mistaken ideas.