- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 24 May 2005 17:59:54 +0200
- To: "public-wai-ert@w3.org" <public-wai-ert@w3.org>
- Cc: www-qa@w3.org
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