Re: Anybody for a server-DOM spec?

At 03:08 PM 8/14/98 -0400, Mike Champion wrote:
>I personally think that such an unofficial interest group would be most
>effective in generating clear REQUIREMENTS for Level 2 and aggressively
>reviewing drafts as they come out to make sure they suit your needs.

Sounds good. I'll start making up a list.

>Suggestions for which "features" of the DOM Core you consider "baggage"
>would also be very welcome; they won't get removed from the overall spec,
>but we may well define conforming "packages" of functionality, e.g., a
>"server DOM", an "editor DOM", an "iterator package", etc.

This would be fine as long as the "xxx DOM" package can selectively
deprecate or at least not implement certain core DOM features such
as Node.previous/nextSibling, etc. that hinder the use of that package
and still be "conforming". Also, these new "packages" should not at
all be required to be saddled with stuff just because Microsoft,
Netscape, et al have some customers with old scripts that can't be
rewritten. Most of the server-side and editing use of the DOM are
relatively new and probably don't depend on the more byzantine
parts of the DOM and could instead use (or already use) things
like iterators, etc. It is really sad that NodeIterator never
made the cut for DOM Level 1.

>My personal opinion is that the WG would benefit from frequent, detailed
>interaction with the people who post on the www-dom list, and perhaps we
>should figure out ways of working more productively with our "customers"
>out there, i.e., you folks.  Yet as much as I emotionally sympathize with
>the notion of producing "clean" APIs that are untainted by the constraints
>of the big vendors' need to maintain compatibility with their current
>products, I've come to realize that a "good enough" standard that meets a
>wide spectrum of needs and *actually gets implemented* is the best we as an
>industry can hope for. 

Ok, as long as there is a clearly defined path that vendors
can follow who selectively implement or extend parts of the DOM.
For example Document.open/write/close should be clearly labeled a client
side scripting interface and a server-DOM can choose to
not implement these and still be fully compliant within the
definition of a "server DOM". A server implementation would most likely
have its own Document factories, parsers, and renderers that
are external to the DOM itself. There may be cases where you
need a HTML3.2 parser, an XML1.0 parser, and a loose HTML4.0
parser that can all be used to generate DOM trees. These engines
may use any conforming DOM implementation, even remote ones
(eg via CORBA).
Document.write() is kind of silly for this.

Maybe some of these methods/attributes could be eventually lifted out
of Level 1 and plopped in a seperate package ie org.w3.dom.scripting
that contains things like ScriptNode, ScriptDocument, etc. To have
things like this in the core is really kind of messy. I suppose
its a little late though...

>There's not that much traffic on www-dom that a new mailing list is
>necessary, IMHO, and I'm quite sure that you'll get the attention of the WG
>better if you conduct your advocacy campaign here.  So, I'd encourage you
>all to post to this list detailed, frank proposals for what the DOM Level 2
>should do and how to do it most effectively. I think that's the best way to
>accomplish your goals, which are shared by many others.
>

Sounds good. You're right about the lack of support for informal
specs like SAX from the big vendors. The backing of W3C is definitely
needed.
So, anybody who's interested in alternative DOM uses speak up!

Thanks,
- Claude Zervas

Received on Friday, 14 August 1998 17:39:09 UTC