SV: [Xmlconf-developer] Updated domtest.xsd and simple attr.xml

My two cents' worth: 

1. Given that we have a series of issues to discuss, it seems like a good
idea to have a telephone conference in order to resolve them as quickly as
possible. I'll get back to the list with details on when this will be. In
the meanwhile, please indicate if you would be interested in taking part.
2. I do not have any principal argument against defining elements as methods
in the schema (except for the _very_ important time aspect) instead of
entities as has previously been done. As the DOM TS ML 0.9 is work in
progress, it would need to be changed in any case. Since we are going to
change both the schema and the test files themselves, adding another item to
the agenda is not that problematic.
3. I would refrain from putting too much "intelligence" in the DTD/Schema,
as I want it clean, small and efficient (which I think goes for all of us).
I seriously do not think that giving developers the ability to have entry
helpers while writing tests is a good enough argument to make the schema
more advanced than need be. Presumably, they are confident enough with DOM
to be able to write tests with the help of the various help documents that
will form part of the DOM TS as well as the specifications (the help
documents will be written once we decide on the framework). I think this is
a fair assumption to make. Please do not forget that the TSML is a
representational language, not the DOM spec itself.
4. Mary, please calculate the time you would need to make changes to the
existing tests so that we can have a clearer picture of when we could
publish the DOM TS.
5. Perhaps given my background I am not in favour of using one language over
another (this is relevant for the "using JAVA or IDL to describe tests"
question). I propose that we use the IDL definitions and accept their
shortcomings since we want the DOM TS to be language-neutral (as is the DOM
itself). Any intelligence needed to generate specific bindings should be put
in the XSLT. From there we can move on to having _one_ set of test
definitions and different XSLT per binding (as indicated in a previous mail;
you will forgive me for not including pointers as I am offline while writing
this). This is particularly relevant as I am investigating the possibility
to automatically generate tests directly from the spec itself in the future.
6. DTD/Schema: No personal preference, but can we demand that developers use
implementations with schema support? We could of course use a DTD
translation of the Schema, but I feel it would lose lots of Schema-specific
information (especially if we were to involve inheritance and so forth)
which would not be captured. In that case we would still be on a purely
syntactical level with no added value.

Allowing for my possible misreading (in case of which I apologize): Curt,
are your closing sentences in your email ("I'm going to try to get (a-b)
done today, (c-e) over the next few days.  As I put things in the xmlconf
CVS or make releases, I'll announce it on xmlconf-developer but won't on
www-dom-ts ") in any way indicative of your commitment to work on a single
solution within the DOM TS framework? Would you rather have two parallel
frameworks?

/Dimitris


-----Ursprungligt meddelande-----
Från: Curt Arnold [mailto:carnold@houston.rr.com]
Skickat: den 19 maj 2001 20:33
Till: xmlconf-developer@lists.sourceforge.net; www-dom-ts@w3.org
Ämne: [Xmlconf-developer] Re: Updated domtest.xsd and simple attr.xml


> I do have a couple of questions.
>
> 1)  For the Document interface, it appeared that the following were
missing:
>
>         doctype
>         documentElement
>         createCDATASection
>         createComment
>         createDocumentFragment
>         createElement
>         createProcessingInstruction
>         createTextNode
>
>         getElementById (maybe a typo -- I saw getElementsById)
>         implementation  (should this be Document.implementation)?

doctype and documentElement are <Document.getDoctype> and
<Document.getDocumentElement>.
The others are in the schema documentation on
http://home.houston.rr.com/curta/domtest/domtest.html.  I did typo
getElementById

A test has to start by either loading an XML file using <load> or accessing
the DOMImplementation under test with the <implementation> tag (in case you
are building a document dynamically) both of these would get transformed to
an code specific for the parser under test.

> I just looked at the Document interface -- there may very well be others.
> Is this schema
> possibly still in process?

Definitely very much a work in process, I initially posted it only after a
few hours of work to let you know I was thinking.

> 2)  What are you using as names for the methods and attributes -- the IDL
> names, the java
> binding, or something else?  This becomes important particularly for the
> attributes -- they
> are defined as get/set methods in java, and as attributes in ECMAScript.
> Differences are
> either handled here, or will have to be handled in the transformation, and
> was the primary
> reason for using IDL names as entity references in the other approach.
> Doing so with a
> conditional include allowed for the automatic substitution of
> binding-specific names.  I don't
> mind doing it another way -- do you have something else in mind?

I am using the Java binding names since there are distinct content models
for the accessors and mutators.  I am aware that the IDL and ECMAScript
binding are expressed in a property notation.  The fact that
<Node.getNodeValue> is a property accessor is maintained in the schema (its
type is DOMPropertyAccessor) and that information could be used in the XSLT
transform that generates the ECMAScript tests.

>
> 3)  Would it be possible to make use of inheritance for your
> attribute/method declarations?
> I would think that this would be an advantage that schemas could provide
> over a DTD
> approach?  I don't currently see attributes and methods defined for
> inherited interfaces.  For
> example, Text should inherit everything from CharacterData, which in turn
> should inherit
> everything from Node.

I don't believe that it is necessary or beneficial to replicate elements for
the inherited methods and
properties.

<Node.getNodeValue obj="node" var="value"/>

would get translated to:

value = ((Node) node).getNodeValue();  //Java

or

value = node.nodeValue;  //ECMAScript

Whether Node, CharacterData, etc appeared left of the "."  would only add an
"instanceOf" check that could already be handled with a:

<assert><instanceOf var="node" type="CharacterData"/></assert>

(Note: var probably should be obj and a distinct <assertInstanceOf> would
probably be useful)

> I'm not sure if I have mentioned that we have added about 200 tests to the
> the collection
> of NIST tests and I expect that about another 200 will have to be written
to
> fully cover
> DOM Level 2 -- we have covered namespaces, errata, and exceptions, but
have
> not
> fully accounted for inherited attributes/methods.  In a couple of days, I
> should be finished
> with a proposed list of tests for all interfaces, with a mapping of the
NIST
> tests.  We
> can then identify any holes and will be ready to write additional tests.
I
> would like to
> use the TSML for this purpose.

I've been doing some exploratory work on DOM 2 Events testing and have
encoded about 20 tests in the domunit CVS and have been working on
corresponding language elements to support that type of testing.

Here is basically what I was hoping to do:

a) Make a domunit release for Java (now with support for JAXP, Batik and
Oracle and additional "Unofficial" tests).

b) Relay my interpretations of results to Oracle, Batik and Crimson teams.

c) Make some additional refinements to the schema.  The most significant
would be the ability to nest code within assertions that would only execute
if the assertion was true.  This eliminates either asserting that an object
was not null and then executing a method on it and throwing an exception or
having to code an identify if immediately after the assertion.

<Node.getAttributes obj="element" var="attributes"/>
<assertNotNull actual="attributes">
    <!--  code that only gets executed if attributes != null -->
    <NamedNodeMap.getNamedItem obj="attributes" var="domestic"
name='"domestic"'/>
    <!-- ...  -->
 </assertNotNull>
<!--  other tests that don't depending on attributes != null  -->

d) Recode the domunit source to the schema and make any necessary
refinements or corrections.  I had originally thought that this should be
automated so you could round trip, however with schema validation of the
test definition it shouldn't be that bad to develop in XML.  So I'll
probably do this as a trial and error conversion using a programming editor.

e) Iterate on a XSLT sheet targeting JUnit

f) Regenerate domunit from the XML source using (e)

g) Modify e for ECMAScript and C++


I'm going to try to get (a-b) done today, (c-e) over the next few days.  As
I put things in the xmlconf CVS or make releases, I'll announce it on
xmlconf-developer but won't on  www-dom-ts.


_______________________________________________
Xmlconf-developer mailing list
Xmlconf-developer@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/xmlconf-developer
http://xmlconf.sourceforge.net

Received on Monday, 21 May 2001 09:03:27 UTC