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

FW: [Design] New proposal for DOM TS ML

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Sat, 26 May 2001 19:52:10 -0600
Message-ID: <B2C1451A181BD411B88A00E018C1C19C08ACA8@thor.aeathtl.com>
To: "'www-dom-ts@w3.org'" <www-dom-ts@w3.org>

-----Original Message-----
From: Arnold, Curt
To: 'Mary Brady '
Sent: 5/26/01 8:51 PM
Subject: RE: [Design] New proposal for DOM TS ML

[mb] That's exactly my point.  I want to do things like
Element.nodeType, and Comment.data.

[ca] I think these are better done as two operations, an
<assertInstanceOf type="Element"/> and the 
invocation of the Node.nodeType property.  Since
ECMAScript in particular is not strongly-typed, 
I think it is best that type assertion tests be explicit.
The production of <assertInstanceOf obj="node" type="Comment"/>
could be assertTrue(node.nodeType == 8) or maybe
an invocation of a harmless method that only exists on 
the desired interface on ECMAScript.

[mb] I don't know what you mean -- maybe the <assign/> statement in your
schema def?  Please expand on the problem with an example.

In my schema def, I had an element for assignment of the value 
of a literal or a variable to another variable and had also
used a "var" attribute for the left hand side:

<assign var="x" value="8"/>
<assign var="x" value="y"/>

Also, simple math:

<substract var="x" op1="1" op2="2"/>

Using "returnVar" for these would be inappropriate and there is
an appeal to have the same attribute name, hence I would stick
with "var" for the return value of functions.

[mb] Yes, you do need to track the type, and in the original example,
were generated of the type var_Node, var_Element, etc -- tracking was
not so
difficult -- if clarity is the issue, we can make the obj required.

[ca] I'd prefer it to be required.
Received on Saturday, 26 May 2001 21:53:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:02 UTC