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

Curt, I second Dimitris, in that I'd be perfectly willing to
help in either generating the schema, or supplementing it
after the fact -- just let me know where you need help.

----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: <www-dom-ts@w3.org>
Sent: Thursday, May 31, 2001 4:27 PM
Subject: 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] Please forward details on how this would happen.  I am reading
it as the transformation that generates the code would have to read
both the instance test definitions and the DOM spec, look up for each
method what the returnType should be, and then generate the code.
On the other hand, if we specify them in the schema def, they will
be visible in the instance, and accessible to the transformation directly
without having to go elsewhere.

NOTE:  I don't want to proceed with more than one transformation.  According
to the minutes, NIST has responsibility for the Java transformation.  If you
plan
on writing one as well, let's discuss it, and try to avoid creating a mess
with the
transformation.  I would much prefer the divide-and-conquer method to the
everybody try everything and try to reconcile things in the end.

> > [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] Sorry, that's what I get for working without a net (the DOM spec).
Just glancing
through, I've picked up the following where the spec says No Return Value:

normalize, appendData, deleteData, insertData, replaceData, setAttribute,
setAttributeNS --

I'm sure there are others.  I just quickly looked at the Return Value
section, so if I've overlooked
something, forgive me.  I'll look a little closer in the morning.  I agree
that var should be required for methods that return values.  My point is
that is should not exist for methods that do not return values.  Ditto for
any other part of a DOM construct -- only define attributes on these methods
if
they actually are there in the spec -- if not, don't define them.  If they
are optional, we
should discuss whether they should be optional in the schema, or (null |
CDATA) --
in particular, I'm thinking of parameters that can either be null or
supplied.

>
> > >
> > [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] I'll have to look at particular tests to see what, if
anything, would come after this statement and what
the impact would be.


--Mary

>
> > [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 17:21:19 UTC