Re: Some more suggestions and a DOM OM

> From:          Craig Brozefsky <craig@duomo.onshore.com>

> You would probably not want to do your validation on insertChild,
> but rather either as a user callable third step, or a automagically
> called mechanism when the document is written out or saved.  Putting
> it on insertChild would be annoying if I was building a document
> thru an iterative process and a required element could not be gotten
> from the user until later in the process.  I think checking for
> validation against the DTD should be postponed.

The DOM WG came to the same opinion.Validation against the DTD will 
be after we've done Level 1. There are all sorts of things to worry 
about - how to allow invalid states temporarily, whether there needs 
to be some concept of batching or transitions, does there also need 
to be an undo mechanism... how should update events, change events, 
etc be tied into validation, or can those be separated out from the 
validation against a DTD... I think getting the basic foundation 
working is more important at this stage. Trying to take on too much 
at once is a guaranteed way of making it all fail miserably.

> A little mantra might be: "Provide the programmer with a set of
> abstractions for building something within a well defined and
> verifiable solution space, and do as little as possible to interfere
> with the flow and process used to build it."

I like this. There are a lot of trade-offs in building something like 
the DOM, particularly as it is (meant to be) platform- and 
language-independent. We have to make sure we don't try to define 
everything that everyone would ever want to do, since we'll never get 
it finished and nobody would implement it anyway because most people 
don't need everything. We have to make sure we define enough, so that 
interoperability has a chance. We want to make things not too 
difficult for script authors using ECMA Script, and powerful enough 
for programmers using Java or C++. And we don't want to constrain 
implementations if we can at all avoid it.

Oh, and we want short, clear, easy-to-understand names that don't 
clash with any existing implementations of dynamic HTML, just to 
summarise one of the impossible-to-satisfy-all-constraints that we 
have.


Lauren

Received on Sunday, 3 May 1998 20:05:50 UTC