W3C home > Mailing lists > Public > www-dom-ts@w3.org > June 2001

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

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Fri, 1 Jun 2001 11:33:04 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A669F@VXOIMP1>
To: "'Arnold, Curt'" <Curt.Arnold@hyprotech.com>, www-dom-ts@w3.org
comments inlined

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 31 maj 2001 22:28
Till: www-dom-ts@w3.org
Ämne: 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.

[dd] just to qualify my initial concern (I'll try to make it a one-liner):
The DOM TS should consist only of schema/dtd (for the test description
language), XML files and XSLT stylesheets. The code should be generated from
the XML and XSLT _only_ without roundtripping anywhere. (there you go, two
lines)

> [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 Friday, 1 June 2001 05:33:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:58:44 GMT