W3C home > Mailing lists > Public > www-dom-ts@w3.org > May 2001

SV: 28 May 2001 WAI ER WG Telecon

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Mon, 28 May 2001 20:45:19 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A661D@VXOIMP1>
To: "'Curt Arnold'" <carnold@houston.rr.com>, www-dom-ts@w3.org
Comments inlined

-----Ursprungligt meddelande-----
Från: Curt Arnold [mailto:carnold@houston.rr.com]
Skickat: den 28 maj 2001 19:08
Till: www-dom-ts@w3.org
Ämne: Re: 28 May 2001 WAI ER WG Telecon

I see three specific phases where we could use EARL.  One is the test
results reporting, which is appropriately out of the scope of the test suite
definition.  The second is to capture the relationships between tests and
the debate and judgement on tests after their submission, but we aren't
there yet.  The third is self-description of submitted tests.

[dd] In the discussion I had with WAI on EARL an argument was made the EARL
could be used for the second phase as well, at least in part (on the
relation modeling).

In this third use, using EARL and other RDF vocabularies places a pretty
steep learning curve to test submitters and high potential for error in the
test description.

[dd] Unfortunately, yes. Something tells me they'll be exhausted after
having learnt to master the DOM TS ML to begin with.

My current thinking is that we keep the <metadata> element that is in my
current schema and continue to allow it to contain an <rdf:RDF/> element for
power users or unanticipated metadata but also allow it to contain elements
from the test definition namespace.  These elements should have the same
semantics as some attribute in an established RDF vocabulary and it should
be straightforward to use XSLT to either generate external RDF or to recast
the test using exclusively rdf expression.

        <creator>John Doe</creator>
        <publisher>Example Software, Co</publisher>

Then it just becomes of question to identify what properties defined by
Earl, Dublin Core, etc are appropriate for self-description but are not
obvious (such as <dc:format>text/xml<dc:format>) and define a representation
for them in our schemas and/or DTDs.

[dd] Sure, I can't see any reason why not to. Let's not make it required,
though, since developers may not want to go that deeply into providing
metadata. I agree with you, but hink we should keep the small set of
information in the description element in the original NIST DTD and possible
expand the amount of information you can give there.
Received on Monday, 28 May 2001 14:45:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:02 UTC