Mary Brady wrote: 
>Type casting could probably be handled in the
>transformation side -- since not all dom calls have the 
>same name across bindings, this mapping to
>a specific binding will have to be handled somewhere -- 
>are you proposing in the transformation?

I was suggesting definiting elements that correspond
to the generic properties and methods of the DOM interfaces
and that they can then be transformed to the appropriate
binding specific form.

>> Since the tests can be identified by a URI, the metadata could be
>>specified using RDF:
>What does this buy us?

I'm not an RDF junky, so maybe someone else can fill in here.
It just seemed an area where me might be reinventing the wheel
and it might just be easier and interoperate better if we just
adoped RDF.

>>In cases where there is an expectation of an
>> exception, the exception is expected on one particular call 
>>and that expectation could be specified as part of the element 
>>for the call.
>> <CharacterData.substringData start="-1" end="10"

>Yes, it could, but you are then dependent on a particular harness.

I don't see that.  When this element is transformed into the 
appropriate language and test framework, it will need to be
expanded into an appropriate construct (probably a try, catch, 
fail combo), however that the specification
that this call is expected to result in a DOMException with a 
code of INDEX_SIZE_ERR seems to be totally independent of
the target framework or language.

>So far in these comments, I see syntax issues -- 
>are there any functional issues that we have missed?

How were you going to handle cases where the expectations are 
different depending on whether the parser is ignoring element 
content whitespace, expanding entity references or using a
pseudo-PI for the XML declaration?

Received on Tuesday, 15 May 2001 11:59:47 UTC