RE: First pass at generated schema for DOM 1 + HTML

> [mb]  I agree that this overcomplicates the transformation -- 
> it seems as though it would be easier to put them in.

I think it is easier for the transform to go to one resource for
its definition of the DOM than to try to reconcile some information
from the instance and some from a DOM definition or derivative.
However, we won't resolve that until we see each others attempts
at transforms.  If I'm wrong we can add the returnValues to the
DTD's at that time and it would not disrupt the tests that have
been authored.

> [mb] methods such as importNode, cloneNode, normalize, etc 
> make changes to
> the dom tree and you already have a handle to it that can be 
> used later.
> Introducing a var where one is meaningless is confusing to 
> the test writer.
> I don't follow your point regarding assiging a call to var 
> when nothing is
> returned.  

Something is returned from importNode and cloneNode and there 
are statements that you could make about the return value.
I think the user experience in a DTD or schema aware editor
would be better if var was required for methods that returned
a value.  However, maybe that is something we could experiment
with during test authoring.  Next time I generate the schema,
I'll make it optional.

> >
> [mb] Could you explain what the assertInstance of would do after
> transformation?

In Java it would be something like:

if(!(node instanceof Comment)) {
    fail();
}

In ECMAScript the transform might convert it to:

if(node.nodeType != COMMENT_NODE) {
    fail();
}


> [mb] Overkill?  Have you seen the size of the schema 
> recently?  Why would
> we tighten up constraints everywhere else and not follow 
> through here --
> it seems that we are 90% there already -- why not finish the last 10%?

Okay, so generate an assert element for every exception code whose
only valid content are those methods or properties that throw
that specific code.

Received on Thursday, 31 May 2001 16:28:10 UTC