Re: Comments on DOM 2

keshlam@us.ibm.com wrote:
> 
> 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.

You ignored my comment about how the HTML precedent of a customized
document subtype is a bad one to follow -- since HTML isn't extensible.


> Others, such as David, point out that there may be data encountered before
> the doctype, and stashing it away is a pain. Granted. 

Before, and after, and all the way through the root element (since you
need to know the root element namespace to crate a doctype).

I used stronger language than "is a pain" ... more like "is unusable".
That wasn't even in the context of customizing a DOM.  It was just trying
to use the APIs in a common (and basic) use case:  populating a DOM tree
using a parser.


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

The other aspect of my post which you ignored was my pointing out
that the "type" of an XML document is _internally_ specified, not
externally.  The external type is basically "XML".  That may in part
be because you're assuming that subtyping "Document" is a "must have"
model, as opposed to a "strongly undesirable" model.


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

Doesn't seem reasonable for the cases I'd want my programs to create
customized DOMs.  Pretty much precludes them.  It'd be healthier to
tolerate the _least_ restrictive model. 


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

I disagree.  Having a broken model for DocumentType creation/insertion
is significantly worse than not having any model at all.  It's hard to
fix broken things once they're deployed.

Oh well ... we'll see what the next CR has to say!

- Dave

Received on Wednesday, 1 March 2000 16:29:59 UTC