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

Re: [Design] New proposal for DOM TS ML

From: Curt Arnold <carnold@houston.rr.com>
Date: Sat, 26 May 2001 01:39:24 -0500
Message-ID: <000e01c0e5ae$9aecbc10$4d44a018@curtbnmqewb54k>
To: <www-dom-ts@w3.org>
I guess one thing that I would find helpful is a list of issues (other than those that have been raised) about the instance syntax implied by my schema.

For example, I wasn't aware until this afternoon that Mary apparently didn't like the <InterfaceName.propertyName/> tag names.  Her resolution was to use nested elements <InterfaceName><propertyName/></InterfaceName>.  My resolution would have been to drop the interface name except in the handful of cases where it is ambiguous.

Metadata - I assume this is a placeholder until we figure out what RDF constructs we want to use.

Do you have a strong preference for "variable" over "var", I used "var" since it is reminisent (sp) of at least one language?

I'm not sure where you intend to pass the name of the invocation target variable.  In my schema, I had represented that with the attribute "obj".  The only place that I could see in your DTD is to do that within the element content, that is:

<Node><attributes variable="attribs">addressElem</attributes></Node>

I think:

<attributes var="attribs" obj="addressElem"/>

is cleaner.

In my initial schema, I had used an expectException attribute to contain the code of an expected exception code that seems to be similar to the DOMException attribute of nodeValue.  I changed my mind on that since I wanted to have all assertions to have an ID so that metadata could be associated.  If I kept expectException as an attribute on the method, then I would need to require ID's even on method invocations where exceptions were not expected.  I just thought it was cleaner to add an explicit assert element for expected exceptions:

<assertDOMException code="INDEX_SIZE_ERR" id="some_metadata_anchor">
    <substringData obj="test" offset="-1" count="5"/>
Received on Saturday, 26 May 2001 02:39:16 UTC

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