- From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
- Date: Fri, 1 Jun 2001 11:33:04 +0200
- 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 UTC