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

----- Original Message -----
From: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se>
To: "'Curt Arnold'" <carnold@houston.rr.com>; <www-dom-ts@w3.org>
Sent: Monday, May 21, 2001 9:02 AM
Subject: 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.

Count me in.

> 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.

Neither do I -- I can go either way -- as long as the test itself has enough
information so that proper transformations can be performed.

> 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.

You have to be careful here -- if the intelligence isn't in the DTD/Schema,
it
has to be somewhere -- as Curt implies, the transformation.

> 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.

2-3 days.

> 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.

I have to admit that I do prefer the IDL definitions to any
language-specific def's.
This keeps the tests language neutral, and differences could be handled in
individual transformations.

> 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?
>
Curt, are you thinking of making this work availabe under the GNU license,
or
as contributing it as part of the W3C test suite effort, which is destined
to be
under a W3C license?

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

> /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 14:29:12 UTC