Re: DOM L2 comments, various

"Stephen R. Savitzky" wrote:
> David Brownell <> writes:
> > "Stephen R. Savitzky" wrote:
> > >
> > > It's a problem -- there _has_ to be some extension mechanism defined in the
> > > spec.
> >
> > The spec allows anyone to define, for example, new interfaces (outside
> > of the org.w3c.* space) and implement them, as well as persuade others
> > to implement them.
> But you might need (or _want_) to define new interfaces that descend from
> Node; in that case you would need node types for them.

Could you give an example?  Is there some syntax that's significant
and not part of the DOM already?  (Excluding DTD syntax.)

The HTML DOM defines interfaces that descend from Node, but they're
all just convenience functions over the core APIs -- they're all
still existing node types.

> > I guess I don't see why element and attribute declarations would need
> > to look like DOM "Node" objects except for a JavaScript environment.
> Because DocumentType is a Node, and the declarations ought to be children of
> the DocumentType.  Because some applications may want to be able to handle
> arbitrary SGML documents instead of just HTML and XML.  Because Javascript
> isn't the only language in the universe without type declarations.  Because
> someday the DOM _will_ be extended to handle the DTD, and in the interim
> people need a consistent way of experimenting with the expected structure.
> It's not that you can't kludge around the problem in some cases, it's just
> that it's much cleaner if you don't have to.

But I'd say "cleaner" is the job for the DOM itself to fix.  And yes, it's
probably overdue that it be fixed.

> 	It's always better to have an explicit extension
> mechanism in the spec, so that each application doesn't go off in its own
> completely incompatible direction.

True enough.  And it can reduce abuses like intentional violations of
such specifications ... ;-)

- Dave

Received on Monday, 4 October 1999 14:18:45 UTC