Radical Suggestion (was Re: Antwort: RE: [jdom-interest] Namespace
dms at sosnoski.com
Fri Jul 26 19:41:36 PDT 2002
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"
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.
More information about the jdom-interest