RE: latest DOM spec 19980720

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

As soon as this level heads to PR, expect to see a flurry of drafts that you
can comment on/participate in.

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

This is generally true: for most uses simple depth-first and breadth-first
traversal are sufficient. Here again, we have a note that we can use as the
basis for a future WD.
> > 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).

As I said, once I get more time, I'll certainly add this into the generation
scripts (shouldn't be very hard even!)

Received on Tuesday, 21 July 1998 09:35:17 UTC