W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1999

Re: The DOM is not a model, it is a library!

From: Sean Mc Grath <sean@digitome.com>
Date: Thu, 7 Oct 1999 05:09:39 -0400 (EDT)
Message-Id: <>
To: www-dom@w3.org
[Stephen R. Savitzky]
>The XML specification, like the DOM, like SGML, only covers the behavior of
>an application that _reads_ a document, converts it into a parse tree, and
>does something with the tree, such as rendering it on a screen.  To such an
>application, only the data matters, and the specifications are very clear
>about what does and does not matter to such an application.

This is not true for SGML in which a vast edifice of data abstraction
(groves / property sets) make it feasible - in principle - for an
application to specify what is and is not of interest. A sufficiently
comprehensive SGML property set would allow an application to perform
a null transformation. i.e. a complete recreation byte-for-byte
of what was originally parsed.

Using this approach, the fabled ESIS (Element Structure Information Set)
becomes one example of an SGML Property Set. It handles
structure-sensitive apps well, but does not handle markup-sensitive
apps well. That is to say, it makes a good information set
for down-translation but a bad information set for

The DOM necessarily throws some stuff away that markup sensitive
applications might be interested in. Heck, even XML parsers throw
some stuff away! If you really need such fine grained access
to the original XML instances then the DOM is not the tool for
you and I would suggest you investigate groves and property

>In particular, I expect an application that transforms documents to be
>capable of implementing the null transform.  Putting it another way, I
>expect "diff" applied to the input and output documents to show me exactly
>what I told the application to change, and nothing else. 
>I don't think that's so very unreasonable, do you?

Yes. I think it is unreasonable because it would complicate
the DOM for everyone. You and I *transform* XML more than
we down-translate it. That puts us into a minority. A minority
that the DOM is not pitched at.

I would love to have access to tools capapable of doing
XML null transformations. No such beast exists to my knowledge.
James Clarks SP parser can build a grove for you and you can
access it on Windows via COM but is not a 100% compliant
XML parser.

For a large class of XML documents that I work with the
"copy" command provides a workable null transformation:-)


<Sean uri="http://www.digitome.com/sean.html">
Developers Day co-Chair WWW9, April 2000, Amsterdam
Received on Thursday, 7 October 1999 05:45:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:06 UTC