- From: Curt Arnold <carnold@houston.rr.com>
- Date: Sat, 26 May 2001 01:39:24 -0500
- To: <www-dom-ts@w3.org>
- Message-ID: <000e01c0e5ae$9aecbc10$4d44a018@curtbnmqewb54k>
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"/> </assertDOMException>
Received on Saturday, 26 May 2001 02:39:16 UTC