- From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
- Date: Mon, 28 May 2001 20:45:19 +0200
- 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. <test> <metadata> <creator>John Doe</creator> <publisher>Example Software, Co</publisher> <date>2001-05-28</date> </metadata> </test> 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