Re: Comment about DocumentType

keshlam@us.ibm.com wrote:
> 
> DocumentType has to be able to tell us:
> 
> ...
> 
> b) ...                   I'd suggest making this a query that
> asks "If I was to do  nodeX.insertBefore(nodeY,nodeZ), where X and Z are
> known, what types of nodes would be permitted as Y?" ...

wouldn't the follow-on states be easier to compute and just as useful? 

> ...
> 
> d) Whether a node's contents are valid, given the rules used above. This
> could be more tightly optimized than checking the single-node calls
> repeatedly. This is the real validation test; the preceeding two are
> primarily provided for directed editing. The application would decide
> whether it wants to check each node as it's built or defer that to a
> go/no-go test on larger chunks of the document; this may mean the validate
> call should be able to operate either as a shallow check (if the tree is
> being checked bottom-up) or as a deep tree-walk (if an entire subtree is to
> be validated at once).

i would not expect, in the context of editing, to need an interface which
allowed more specificity than "shallow" v/s "entire document". since the
context models are context-free, only a shallow test on the immediate content
set is strictly necessary to edit. were one to wished to defer validation, i'd
be surprised if the editing user were able to control more than three modes:
the element i just edited, all changed elements, the entire document. an
option such as "the trees (with depth n) starting from all changed elements"
would be seldom used and produce results which would be hard to use.

> 
> ...
> 
> e) ....

Received on Thursday, 22 October 1998 12:55:54 UTC