[jdom-interest] Common interfaces..

wes at tralfamadore.com wes at tralfamadore.com
Sat May 5 12:13:55 PDT 2001

--- Elliotte Rusty Harold <elharo at metalab.unc.edu>
> We've gone back and forth on this one. I think that
> XML documents are 
> text, not abstract structures in memory. Therefore
> returning the text 
> representation of one of our abstract structures is
> a fundamental 
> operation. In fact the text form is more fundamental
> than our object 
> form. That is, the model is the text. The object is
> the view.

I think it's important for programmers to understand
that XML documents can be modeled by objects in the
same way that Java source code can be modeled by byte
code.  A programmer gains something from realizing
that <tag></tag> and <tag /> are modeled exactly the
same, and it's merely the view parameters that are
changing.  Same with complex namespace reassignment.

Note also that the approach of implicit knowledge of
string serialization has a couple of problems.  One,
there's no analogous deserialization that can be
easily implemented on a per-JDOM-object basis, and
two, that approach would come close to the implicit
way Microsoft's APIs stringify an XML "object", which,
while I haven't worked with the API extensively, seems
to be a limiting factor in implementing complex
scenarios involving XML.

There are also plenty of use cases for JDOM that don't
involve outputting XML.  One of the most frequent
tasks I seem to use it for is to parse an XML
configuration file.  As the developer of these
utilities, I don't give a flying Duke what the text
representation is, I want to know the underlying model
that it describes.  Granted there are also plenty of
use cases that need to output XML, but I still see
these as things that act on the model.


More information about the jdom-interest mailing list