Re: Comments on DOM 2

>I had a similar comment, showing the rather horrible situation
>that folk are in today if they want to populate a Document with
>a correct DocumentType .
>
>   http://lists.w3.org/Archives/Public/www-dom/1999OctDec/0263.html

The point has been granted. The current plan is to address it in DOM Level
3 via some combination of the Content Model and Load/Save chapters.

The problem is that there are conflicting goals, and it looks like
reconciling them will take a while.

Some folks want to select which subclass of DOM they create based on the
type of the document... and at the moment, that type info is only expressed
via the doctype. Since you can't change subclass after the objects have
been created, and since the document itself may want to be a different
subclass, this decision has to be made early. That's the scenario which
gave rise to the approach taken in DOM Level 2.

Others, such as David, point out that there may be data encountered before
the doctype, and stashing it away is a pain. Granted. That's hard to
address given the prior set of users, but we'll see what we can do. If
Level 3's Load/Save has some other way of obtaining document type
information -- mime? filetype? -- we may be able to make the subclass
selection before we start reading the content. Or we may simply have to say
that if you use the Document-first order, you can't conditionally subclass
the early nodes... but that may not make sense for all DOMs.

Still others, who are working on general-purpose XML tools, may want to be
able to change document types after the document has been built -- either
rewriting the content model, or replacing it outright -- to support tasks
like in-place transcoding, content-model editing, validating against a
doctype other than the one specified by the document, and so on. That
definitely prevents build-time subclassing, but it's another interesting
set of use cases... and represents an extreme late binding of document and
doctype.

The current solution doesn't address all these cases, but does tolerate the
most restrictive (the first), and it's reasonable for
programmatically-created documents. I suspect that we're going to wind up
with alternatives in Level 3, but some of them may have to be optional.

Meanwhile... Well, we're certainly no worse off than in Level 1, where
there weren't any factory methods for Document or DocType and everyone was
using a custom solution. The current solution _is_ a step forward, even if
it isn't the right answer for everyone.

______________________________________
Joe Kesselman  / IBM Research

Received on Wednesday, 1 March 2000 15:21:37 UTC