Re: Test Metadata in RDF

Hi Patrick, Hi Dom,


Le 06-04-07 à 06:53, Patrick Curran a écrit :
> Thanks, Dom: I'm glad to see the beginnings of a concrete  
> implementation of the ideas we tried to express in the metadata  
> document. I'd be interested to get your feedback now that you've  
> tried to create an implementation. Is our list of elements  
> reasonably complete? Do we have the right data types? Are the names  
> appropriate?


Dom has not answered yet, but I was wondering if it could be possible  
to find a few test cases in different technologies and see if the  
tests they created could be expressed with this document.

That would help to create one or more practical example.

> Tim Boland has already made some of these points, but for  
> completion I'll respond anyway. Since I'm not very familiar with  
> RDF I have no idea whether the syntax is correc I'll simply try to  
> focus on how well the implementation seems to map to the metadata  
> elements defined in http://www.w3.org/TR/2005/NOTE-test- 
> metadata-20050914/. I've focussed on the N3 version because it's  
> easier to read and because it seems as if the XML/RDF version was  
> derived from it.

Yes the RDF/n3 is usually easier to read.
http://www.w3.org/2006/03/test-description.n3
http://www.w3.org/2006/03/test-description.rdf

I have generated a png file using the RDF validator
http://www.w3.org/2006/03/test-description-graph.png
but it might not necessary helps you to read the full thing.


> Here's what I noticed:
>
> 1. There's no "Identifier" entry.

http://www.w3.org/TR/test-metadata/#identifier-def
Do you mean the RDF Schema doesn't contain the Identifier class?

I may see a possible issue a conflict between two identifiers, one  
which has been given and a natural one when the test is available on  
the Web, but that would be better to hear Dom about it.

> 2. "ReviewStatus" should  be "Status" (this element need not  
> necessarily have anything to do with reviewing - as the comments  
> section points out).




> 3. "SpecificationReference" is actually named "SpecRef: in the  
> Note. Should we spell it out in full?

I think that could be a good idea, some people will argue that less  
to type would be better. :) no strong opinion on that.

> 4. "preCondition" should be "Preconditions". (Is the singular form  
> in fact preferable? Would we have multiple entries if there were  
> multiple "preconditions"?)
> 5.  "input" should be "Inputs". (Is the singular form in fact  
> preferable? Would we have multiple entries if there were multiple  
> "inputs"?)
> 6. The following required elements are missing: Version (we weren't  
> sure this is necessary), Contributor, Rights.



> Also, while thinking about this after reviewing the "Test Assertion  
> Howto Guide" (not

http://www.w3.org/2006/03/test-assertion-guide.html

> yet published to the full www-qa list) I realized that we seem to  
> have a problem with the SpecRef element. I had intended this to  
> substitute for an Assertion element (not wanting to enforce the  
> concept of assertions on everyone). However, I now realize that  
> while it works when the text of the assertion can be identified  
> within the text of the specification, it does not work when the  
> assertion has to be "derived from" the spec. To handle the latter  
> case it seems we need an assertion metadata element which in turn  
> would (optionally) contain the text of the derived assertion,  
> together with a pointer into the spec.

http://www.w3.org/TR/test-metadata/#specref-def
"Identification of the portion of the specification tested by this  
test."

It doesn't say that it is the reference to a test assertion but to  
the part of the specification which is relevant.

The reference to the actual test assertion might be a very good idea  
indeed.


-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

Received on Thursday, 1 June 2006 06:49:15 UTC