SV: [Design] New proposal for DOM TS ML

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"/>
</assertDOMException>
 
[dd] Could we put this in the framework that Mary proposed?