Conformance to EARL

Hi folks, (this is cc'ed to the qa group, but please follow up to the ER  
group and don't spam them with out internal stuff)

according to the QA guidelines (and common sense) a spec should say what  
you have to do to conform.

On the agenda for when we get to it is the question of whether EARL should  
require certain things as information in an assertion. But there are some  
other things that I think we should agree on too.

Some quick thoughts...

We should have conformance criteria for tools that read EARL, tools that  
produce EARL, and for EARL documents, and some minimal criteria for each:

Documents...

  - Must be valid RDF.

Open issue - Perhaps documents Must include certain information (date,  
assertor, ...)

Producing tools

  I think these ones are pretty clear

  - Must produce valid RDF.
  - Must not produce any properties in EARL namespaces (list current one,  
and last few, but drop working draft ones when the drafts are no longer  
current?) that do not conform to the RDF, RDFS and OWL requirements  
specified in the spec. For example, if a property has a domain of  
earl:Result it is an error for a producing tool to put that property on an  
earl:Assertion

  the following are suggestions I think should be discussed

  - Any Web interface to any tool Must conform to WCAG 1 level A, and  
Should conform to level double-A
  For requirements for other interfaces we should follow whatever ATAG does  
for their equivalent requirement...

  - Should interpret rdfs:label and rdfs:comment information to provide  
labels and further explanation for elements in the earl namespaces,  
including xml:lang information.

  - may interpret other relevant RDF to provide alternative or additional  
information, especially for localisation.

Consuming tools

  think this is basic
  - Must process earl classes and properties according to RDF syntax  
specification, i.e. must accept any valid RDF and understand the earl in  
it.
  - Should process RDFS inferences using subClass, subProperty, domain,  
range.
  - Must not process such inferences incorrectly

I think we should also describe the OWL things that we think are important  
- such as dealing with describing that several results implies some other  
result, and make that a Should or must.

Rather than just have should or must, I would prefer to have a base level  
(all the things that are must) and a second level where things that are  
here described as should become must....

Anyway, this is for discussion when we get a draft out from the current  
round of discussion

cheers

Chaals

-- 
Charles McCathieNevile                              chaals@opera.com
          hablo español - je parle français - jeg lærer norsk
   Here's one we prepared earlier:   http://www.opera.com/download

Received on Tuesday, 24 May 2005 16:00:01 UTC