Re: latest DOM spec 19980720

Thanks very much for your detailed and useful comments; some responses below:

At 06:52 PM 7/20/98 -0400, Stephen R. Savitzky wrote:
>  My group has been spending the last
>several months building a large document-processing application using the
>DOM as its basis; we had to make several extensions to the core to get it to
>handle generic SGML.  I think it's very important to be able to represent
>_any_ SGML document using the DOM core. 

For better or worse, that's not in our charter, XML and HTML is.  It would
be reasonable for those wishing to use the DOM for processing full SGML to
collaborate on some sort of working draft that would keep others from
having to re-invent this wheel, and to provide a basis for informal
interoperability and perhaps guide a future working group chartered to
extend the DOM to SGML. 

You are not alone in lamenting the loss of support in the DOM for
Declarations, validation, and other DTD-related matters.  It was simply a
matter of *having* to get a Core/HTML draft out now or miss the ability to
prescribe a standard API that could be supported by the NS/MS 5.0 browser
releases, and this did not allow time for full analysis and debate of the
XML DTD issues.  We *will* try to get a W3C Working Draft describing our
tentative solution out ASAP.

>

>A few more specific notes:
>
>o There is no type-safe way to convert a Node to any of its major
>  subclasses.  The newly-added nodeName, nodeValue, and attributes
>  attributes help a great deal, but it would be good to have conversion
>  methods as well.  We have, e.g., "asElement", which returns the node if it
>  is an Element, null otherwise.  This is _much_ more efficient than
>  casting, which involves run-time type checking in Java. 

I don't understand; we could specify an interface, but I don't see how the
implementation of that could be much faster than a Java cast.

>
>o I'm very sorry to see NodeIterator, TreeIterator, and their create methods
>  disappear.  It's easier to create iterators when you know the type (and
>  hence the implementation details) of the objects you're iterating over;
>  the resulting type-specific iterator can much more efficient than a
>  generic one, and its class need not be exposed to the programmer.

Sigh.  Another much-lamented feature that had to be dropped because of time
pressure (and because it would be overkill for many HTML users).  Expect to
see iterators back in Level 2, and perhaps in a Working Draft before then,
but they will probably be an optional package built on top of the DOM core
rather than a fundamental part of the API.


>o Making the parent of an Attribute refer to the Element that contains it is
>  almost certainly a mistake when coupled with the idea that the value of
>  the attribute is its children.  We tried it.  The problem is that when an
>  attribute has a default value, you have to copy the entire tree from the
>  DTD to each Element where the attribute appears.  The best solution would
>  be to return the effective value of an Attribute as a NodeList rather than
>  as a wstring.  

Interesting point; this may require re-consideration.  As for Nodelists as
the value of attributes, remember that anything other than a string as an
attribute value is massive overkill for HTML users and probably most XML
users as well.

>Finally, I note that there are no comments in the Java bindings.  While this
>is well-optimized for the appendix to the specification, it would be best if
>the compiled version (javabindings.zip) had the comments, so that JavaDoc
>and other documentation-extraction and source-code-browsing software could
>make use of them. 

The Java bindings are automatically generated from the XML source; it may
be possible to do what you ask, or perhaps to emit JavaDoc descriptions as
well as the Java bindings.  Gavin ???

Mike Champion

Received on Monday, 20 July 1998 20:12:08 UTC