SV: My iteration

Also, as you may have noted already, the obj is not present everywhere (see
disussion in
http://lists.w3.org/Archives/Public/www-dom-ts/2001May/0087.html
<http://lists.w3.org/Archives/Public/www-dom-ts/2001May/0087.html> ).
Imagine it to be present, I forgot to put it there.

-----Ursprungligt meddelande-----
Från: Dimitris Dimitriadis [mailto:dimitris.dimitriadis@improve.se]
Skickat: den 28 maj 2001 18:17
Till: www-dom-ts@w3.org
Ämne: SV: My iteration


Previous version of DTD now updated with
 
Document, DocumentFragment, DOMImplementation and extended.
 
Also, the source contains comments where things have been changed (newChild,
for example, is not a method on Element). In addition, duplicate attributes
have been removed (to the best of my knowledge).
 
Some of the issues that have been raised: there are ambigous contexts. Some
interfaces contain more attributed than they should (for example data). 
 
One way to selve this is to not have them as required, but as implied with a
default value to none in the cases where they should not exist according to
the spec. Another could be to work primarily against the schema version and
use context dependence. We could also make the attribute group definitions
more granular in entity form and 
include them in the way they should where applicable, but I feel this adds
complexity.
 

Please sanity check for tomorrow's telcon. I'll get back with an agenda for
tomorrow soon.
 
/Dimitris
 

-----Ursprungligt meddelande-----
Från: Curt Arnold [mailto:carnold@houston.rr.com]
Skickat: den 27 maj 2001 09:15
Till: www-dom-ts@w3.org
Ämne: My iteration


I've updated http://home.houston.rr.com/curta/domtest/domtest.zip
<http://home.houston.rr.com/curta/domtest/domtest.zip> , this file 
contains a schema, DTD and documentation.  I haven't had a chance to double 
check it against the DOM specs, so if I got a return type wrong or
something,
please forgive me.
 
Here is a summary of differences between my previous schema.
 
1. IDL property names instead of Java accessor/mutator names
 
Read-only properties are pretty simple, both var (the variable assigned the
returned value) 
and obj (the invocation target) are required.
 
<nodeType var="nodeType" obj="node"/>
 
Read-write is more complicated.  obj is still required, var and value are
optional.
The question then is how do you interpret the element if both are supplied
or neither is supplied.  When neither is supplied, I'd interpret it as a 
a property access and discarding the value.  If both are supplied, for
instance:
 
<Attr.value var="oldValue" obj="attr" value='"New Value"'/>
 
I'd interpret it as a access followed by a mutation, that is:
 
oldValue = attr.getValue();
attr.setValue("New Value");
 
2. Removed interface prefix before non-ambiguous method or property names
 
There were more ambiguous names that I had previously mentioned, but not
too many.  Here is the list of names used introduced in multiple interfaces
that
I came up with:
 
Document.getElementByTagName and Element.getElementByTagName
Document.getElementByTagNameNS and Element.getElementByTagNameNS
NodeList.item, NamedNodeMap.item
NodeList.length, NamedNodeMap.length, CharacterData.length, 
CharacterData.data, ProcessingInstruction.data
DocumentType.name and Attr.name
DocumentType.publicId, Notation.publicId, Entity.publicId
DocumentType.systemId, Notation.systemId, Notation.systemId
ProcessingInstruction.target, Event.target
DOMException.code, EventException.code, RangeException.code
 
Distinct elements are introduced for each method.  It might be possible
to imply the intended variant from context, but I'd much prefer having
that explicit.
 
All other DOM properties and methods have had the interface name
removed from their tag name.  
 
I had anticipated using the interface name part of the tag name
in the code generation.  To provide the information lost, 
I've added annotation elements into the schema that will provide the
introducing interface and expected type for use by the code generators.
 
implementation and hasFeature act both as static methods and
instance methods.  
 
<implemenation var="impl"/>
 
Will give you an DOMImplementation from the implementation under test
to use in tests that build documents from scratch.  While:
 
<implementation var="impl" obj="doc"/>
 
will give you the implementation from the specified document.
 
hasFeature is a little more complicated.
 
<hasFeature feature="XML" version="1.0"/>
 
is an implementation conditional that can be used to determine
if a test is appropriate for the processor under test and can
be used in <if> statements.
 
<hasFeature var="hasEvents" feature="Events" version="2.0" obj="impl"/>
 
Would be a "traditional" method invocation.
 
 
3. Added <metadata> element to tests and asserts
 
Expected to contain one rdf:RDF element.  Will continue to refine and
possibly assert a
required set of EARL or DC properties.
 
4. Fixed a lot of instances where I had used the DOMFunction complex type
instead 
of the DOMSubroutine complex type
 
There were a substantial number of methods that had no return value that I
had
inadvertantly used the wrong complex type resulting in unintentional "var"
attributes on
void methods.  This may have been the cause of some of the earlier 
confusion, I was not aware of it until I started adding return types into
the <appinfo>
 
5. Changed <assert> to <assertTrue> and synchronized <assertFalse>
 
JUnit 3.7 deprecated the assert method in favor of assertTrue.  Also
allowed you to assign a conditional expression to a variable with
the <assign/> element and introduced <isTrue> and <isFalse>
so that variable can participate in more complicated logical
expressions.
 
6. Removed garbageCollect
 
Confusing and probably unnecessary.  Was intended to be used in 
tests that might succeed if some unreachable object had not been
finalized, but would fail if it had.
 
 
------------------
Additional comments regarding schema and DTD convergence:
 
In an earlier comment, I had thought that the character content of method
and property 
elements might be used to identify the invocation target since there was no
obvious provision for it.  Not providing an obvious provision was
acknowledged an oversight, but
I forgot to follow up on the intention of the character content.
 
If an invocation target attribute ("obj") was added, you could do something
like:
 
<Node><nodeValue obj="someNode" var="someVar">Some text goes
here</nodeValue></Node>
 
The obvious potential use for the character content is some type of comment
which I had used in my earliest iterations of the schema before I made it
public.
However I think it is preferable for the content model to be empty for a
couple of reasons:
 
1. Leaving the content model empty allows for future enhancement.  I've
already
encountered a few instances where I needed to add element content to an
element
that originally was empty.
 
2. It provides a tempting place to put information that should be specified
in either
the test or assertion metadata.
 
3. Can complicate schema when you are trying to combine element containing
and 
character data containing elements into one substitution group.
 
Without using character content of property and method elements, there are
still
three places to put descriptive text:
 
a) In the metadata for an test or assert
 
This is the appropriate place for any descriptive text that would be
beneficial for a
person running the tests.
 
b) In [XML] comments in the test definition
 
This is appropriate for any descriptive text that would help someone
examining the
test definition (for example, complaints about the test definition
language), but
would not add any value to someone running the tests.
 
c) In a <comment> element
 
This is appropriate for any descriptive text that would help someone
examining the
generated source code.
 
Typo alert:  Multiple <!ATTLIST attributes...> where I think you intend to
defined the
attributes for a different tag name.