Re: EARL-producing testing tool

>What you could do is something like the following:-
>
><WebContent
>rdf:about="http://hkn.eecs.berkeley.edu/~nadiah/tester/ns#http%3A//www
>.w3.org/%20name%202002-02-13">
>        <testSubject rdf:resource="http://www.w3.org/" />
>        <date>2002-02-13</date>
></WebContent>
>
>it's not pretty, but it's fairly robust. Simply take URI+" "+name+"
>"+date, and URI quote it. Alternatively, you could just use short
>generated IDs, and keep track of them in a local database or
>something.

Hmm... I've changed it to produce that for now, but I'm not sure I
understand what this new and improved URI is supposed to represent.  Does
this mean that I have to make my own namespace so that this can be
translated into something meaningful later?  Is this supposed to be able to
retrieve the results? (Sorry, I'm still new to this whole earl/rdf thing,
so my questions will tend to be kind of basic.)

>* The predicates are wrong. In fact, EARL 0.95 only defines
>earl:passes, and earl:fails. If you want to use "NotTested" etc.,
>you'll have to compose them in the following way:-

Oops. :) I basically copied my output from ATR, as you guessed.  You should
make "Learning EARL by Example" public, it's quite helpful.

>* Perhaps you can use RDF for the test cases. Something like the
>following syntax (in Notation3 [1]) would be cool:-
>
>@prefix : <http://hkn.eecs.berkeley.edu/~nadiah/tester/ns#> .
><http://www.w3.org/Style/CSS/Test/CSS1/current/test15.htm> :id "1.5" .
><http://www.w3.org/Style/CSS/Test/CSS1/current/test16.htm> :id "1.6" .
><http://www.w3.org/Style/CSS/Test/CSS1/current/test17.htm> :id "1.7" .

That's kind of cool.  I'm going for easy to produce and easy to parse here.
 I'll play around maybe.

Would it be worthwhile to produce EARL in n3 too?

>* http://hkn.eecs.berkeley.edu/~nadiah/tester/css.txt#1.1 has a
>dubious fragment, although it doesn't concern me too much.

Another place where I wasn't sure of the purpose of the resource.  I'm not
sure what's supposed to be there.

>* [pedantic-mode] The form uses GET, but the frames hide that, which
>is a shame. I don't think that's "fixable". Acutally, the form at the
>end uses POST, whereas a long GET may well be acceptable, given that
>the field names aren't all that long. If not, perhaps you could save
>the results temporarily to the server (like the W3C's RDF Validator
>does for the visual output), and give them a short ID.

Actually the script uses POST by default, but it accepts either.  The one
call with GET for the sub-frame is an exception because it was the only way
I could think of to pass on state information when I couldn't force the
form to submit itself. (I'm new to cgi scripting too, is there a better way
to do this?)  I wanted to avoid having to save any information to the server.

>* Please make the source code for the client public if you can, and
>attach suitable licensing conditions

What's suitable?

>MUTAT is a cool name for the tool, BTW, although it feels as if it
>needs an "N" added to it :-)

Hmm... Network?  Nullifier?  Node? :)

Thanks for all your help with the EARL.  I'll work on fixing things up more.

Nadia

Received on Thursday, 14 February 2002 09:10:41 UTC