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

SV: [Design] New proposal for DOM TS ML

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Sat, 26 May 2001 17:12:31 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A65D2@VXOIMP1>
To: "'Curt Arnold'" <carnold@houston.rr.com>, www-dom-ts@w3.org
Comments inlined below

-----Ursprungligt meddelande-----
Från: Curt Arnold [mailto:carnold@houston.rr.com]
Skickat: den 26 maj 2001 08:39
Till: www-dom-ts@w3.org
Ämne: Re: [Design] New proposal for DOM TS ML

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.
[dd] Good point, please tell me if you want me to post it at regular
intervals. I expect to tie it up more formally in connection with the
telecon. I do of course keep track of issues raised on tha mailing list, but
given that 4 at most 5 people have been active, I haven't felt the need to
post the issues list at regular intervals. 
Of course I'll start diong so if people need this.
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.
[dd] OK, should we move in your direction? Is Mary's proposal too
incomaptible with what you think we should be able to do?
Metadata - I assume this is a placeholder until we figure out what RDF
constructs we want to use.
[dd] Yes, I'd like to see more integration proposals with EARL, which has
been raised on the list.
Do you have a strong preference for "variable" over "var", I used "var"
since it is reminisent (sp) of at least one language?
[dd] Personally, none whatsoever.
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.
[dd] Sure, will update the DTD:s proposed so far.
 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"/>
[dd] Could we put this in the framework that Mary proposed?
Received on Saturday, 26 May 2001 11:13:02 UTC

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