SV: Test Matrix [Process]

comments inlined

-----Ursprungligt meddelande-----
Från: Mary Brady [mailto:mbrady@nist.gov]
Skickat: den 15 juni 2001 21:14
Till: Arnold, Curt; www-dom-ts@w3.org
Ämne: Re: Test Matrix [Process]



----- Original Message -----
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: <www-dom-ts@w3.org>
Sent: Friday, June 15, 2001 12:20 PM
Subject: RE: Test Matrix [Process]


> I meant to outline an metadata driven approach to
> maintaining the test matrix a few days ago, but
> got distracted.
>
> First, we already have URI's for the interface, methods and properties
> from the DOM spec.  The base part is debatable, but you could
> refer to the hasFeature() method as defined by DOM Level 1 as:
>
>
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core#ID-5CED94D
7
>
> or as defined in DOM Level 2 Core as
>
> http://www.w3.org/TR/DOM-Level-2-Core/core#ID-5CED94D7
>
>
> or createDocument() as defined by DOM Level 2 as:
>
> http://www.w3.org/TR/DOM-Level-2-Core/core#Level-2-Core-DOM-createDocument
>
>

[mb] Okay, I found these.

> Then you need to define a URL to correspond to the "Purpose" column in
> your matrix.  If this is a specific passage to the text of the spec,
> this could be represented by a XPointer type URI:
>
>
http://www.w3.org/TR/DOM-Level-2-Core/core#xpointer(id('Level-2-Core-DOM-cre
ateDocument')/raises/exception[1])
>
> If it was some outside of the spec comment, then you'd be on your own.
>

[mb] This didn't work for me, so I'm not sure I'm following you here.  I
suspect you
are saying that there is a way to discretely access each interface,
method/attribute,
parameter?, and exception.  I'll look into this further.

> It should be fairly straight forward to generate RDF with at least
> minimal information to describe the URI's associated with methods,
> interfaces, exceptions, parameters, etc using an XSLT transform
> on the XML version of the spec.
>

[mb] I haven't done anything with rdf, although I am familiar with its
intent.
I thought we had decided to keep the metadata simple, and specifically, not
to use rdf...

> Then what is needed is to incorporate in the test metadata,
> the fact that a specific test refers to particular URI's.
>
> <test>
>    <metadata>
>       <rdf:about>
>     <somens:someproperty
rdf:reference="http://www.w3.org/TR/DOM-Level-2-Core/core#xpointer(id('Level
-2-Core-DOM-createDocument')/raises/exception[1])"/>
> </rdf:about>
>    </metadata>
>    <!--  body of test goes here  -->
> </test>
>
> Or do it externally
>
> <rdf:RDF>
>     <rdf:about
rdf:reference="http://www.example.com/domtest/myfirsttest.xml">
>     <somens:someproperty
rdf:reference="http://www.w3.org/TR/DOM-Level-2-Core/core#xpointer(id('Level
-2-Core-DOM-createDocument')/raises/exception[1])"/>
>     </rdf:about>
>     <rdf:about
rdf:reference="http://www.example.com/domtest/mysecondtest.xml">
>     <somens:someproperty
rdf:reference="http://www.w3.org/TR/DOM-Level-2-Core/core#xpointer(id('Level
-2-Core-DOM-createDocument')/raises/exception[1])"/>
>     </rdf:about>
> </rdf:RDF>
>
[mb] I would propose that we want to have a master list of test purposes, as
the key for our framework, with ptrs to the spec.
I don't think that we can always point directly to the sentence that a
particular purpose maps to, but we can get close.  That is,
sometimes you are testing a particular aspect of a given parameter, and it
may be embedded in the text for that interface, but not
necessarily have an id on that line.  For each test purpose, we add tests
that we have.  This will make it easy to identify where
we do not yet have tests.  If, as above, in the first example, we do it the
other way, with a given test as the key, we will only
have information on areas of the spec that we have tests.

What kind of metadata do we want in our framework?  Perhaps the following:

- Info to categorize spec for testing:
    category, interface, method/attribute, xml/html/xhtml?, exception?
    test purpose

- Actual tests
    author, submitting organization, modified by?, date?, description
    I'd like to see this information used in the transformation to generate
    prologue documentation (ie, javadoc style documentation for the java
translation)

What have I left out?

[dd] perhaps some description on (possible) iterations done by the DOM
moderator group with pointers to previous versions of the test

--Mary


>

Received on Wednesday, 20 June 2001 06:22:53 UTC