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

[Elliotte Rusty Harold]

At 7:41 PM -0700 7/26/02, Dennis Sosnoski wrote:

>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.

Absolutely. Internally, we could use some fancy hash table structure 
of strings and indexes into those strings and pointers every which 
way that looked nothing like XML, if that helped us out. However, the 
*public* API needs to look and act a certain way in order to 
faithfully represent the XML and namespaces specs.

And it's not just a question of converting properly to and from text. 
Lots of other specs depend on namespaces: RDF, Schemas, XPath, XSLT, 
XInclude, XPointers, SVG, DocBook 5, XHTML, and many more. The JDOM 
namespaces API needs to be able to support all of these. All of them 
are implicitly or explicitly based on the notion that a namespace is 
an intrinsic property of the element, not simply a positional 
artifact of various namespace declaration attributes. If we switched 
to the positional artifact model, then using any of these 
applications on top of JDOM, especially mixtures of them, would 
becomes noticeably harder and slower.

>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,

That's only what developers who don't understand namespaces expect to 
happen. Developers who do understand namespaces expect exactly the 
opposite. Or perhaps more accurately, they expect that when they cut 
and paste a section from point A to point B, they then have to be 
careful to fix up all the necessary namespace declarations too.

We could take a very XML 1.0, pre-namespaces, approach in which 
namespace declarations were just attributes, qualified names were 
just names, and so forth. We could even still provide most of the 
existing namespace API on top of this. However, in so doing we would 
significantly complexify all namespace operations. For example, 
simply asking an element for its namespace would require walking up 
the hierarchy to the nearest declaration.

>  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).
>

We can only be as simple as Java if XML is as simple as Java. Here 
I'm afraid it's not. A better mission statement would state "provide 
a solution for using XML from Java that is as simple as Java and XML 
themselves"
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+