Re: latest DOM spec 19980720

Mike Champion <mcc@arbortext.com> writes:

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

Point taken.  I'd be happy to assist with such a draft.

> 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

Perhaps a couple of place-holder nodetype constants would do.

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

A Java cast hides a very inefficient implementation:

  Element bar = (Element)foo

is roughly equivalent to: 

  if (foo.getClass().implements(Element.getClass()) { bar = foo; }
  else { throw new ClassCastException...}

and the ``implements'' operator requires comparing each interface mentioned
in foo's Class object and all of its parents against Element.  Nasty.

On the other hand, the implementation of asElement is:

class NodeImpl implements org.w3c.dom.Node {
  ...
  public Element asElement() { return null; }
  ...
}

class ElementImpl implements org.w3c.dom.Element extends NodeImpl {
  ...
  public Element asElement() { return this; }
  ...
}

All the necessary type-checking is done at compile time, so the
implementation is as fast as possible.

> >o I'm very sorry to see NodeIterator, TreeIterator, and their create methods
> >  disappear.  

> Sigh.  Another much-lamented feature that had to be dropped because of time
> pressure (and because it would be overkill for many HTML users).

I'll be looking forward to it.  Actually, the full glory of TreeIterator
turned out to be overkill for us, too; we needed a single forward-only
traversal. 

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

It was the fact that value returned a NodeList that sold me on the original
DOM spec.  Even for HTML users, the fact that you have to convert characters
back to entities on the output end turns out to be quite painful, and means
that you can't just use "value" to convert a Text to a String -- you have to
examine each character and do a table lookup to get its output equivalent.

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

I had that in mind, in fact.  We've discovered that _absolutely_ the best
way to develop a framework is to make the source code browsable as a
website, and to make sure that all code and its documentation come from a
single source (typically this means extracting the documentation from the
code, but of course in your case it means generating both the code and its
documentation from the XML original).

> Mike Champion

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Monday, 20 July 1998 20:51:59 UTC