Re: [RDFa] Some QA-related issues regarding RDFa documents

Hi Michael,

(sorry for the late reply, I was in meetings and travelling)

Le 8 févr. 2007 à 18:06, Hausenblas, Michael a écrit :
> Based on [1] I would like to raise some issues regarding our
> RDFa documents [2]. This is done, at least for now, from the
> point of view of the RDFa Test Suite; might be valid in general
> as well ...
>
>  1. Regarding section '2.2.2 What needs to conform?' in [1]:
>     Do we address this requirement? In this context it might help to
>     specify the 'products'.
>
>     Does it help here to propose a division in REST-style extractor,
>     and DOM-operating extractor? Did we even define how we call the
>     'XHTML+RDFa -> RDF' service, anyway? Is it a transformation, an
>      extraction, etc. ?

Think about it in terms of implementations.
When a developer implements the RDFa specification, are there  
differences depending on the products? For example, you said

	REST-style extractor,
     and DOM-operating extractor

Does these two types of extractor have different requirements with  
regards to the specification?
For REST-style extractor, I MUST meet to  the requirements A and B  
and NOT C
For DOM-style extractor, I MUST meet to  the requirements A and B and C

Then it means that there are different types of Conformance  
(Implementation requirements) for different type of products. It  
would like distributing stones (requirements) in bags, if two bags  
have the exact same number and type of stones then they belond to the  
same class of products.

The conformance section is
	a tool for the developer
	to quickly know what things have to be implemented (requirements)
	for his/her own implementation (class of products)


>  2. Regarding section '2.3.2 What is mandatory?' in [1]:
>     Though I found two occurrences of 'must' in the RDFa syntax  
> document
> [3], I am not sure if we already make use of the RFC 2119 [4]  
> keywords in
> a sensible way.

Note that it is not mandatory to use RFC 2119 keywords, but
	1. to adopt a consistent style to define requirements
	2. to explain what is this style

Regarding the specification, are there RDFa constructs which would  
not make sense? and then should be forbidden?
Are there some constructs which are absolutely mandatory to be  
meaningful for a parser? (nesting requirements, association of  
attributes, etc.) If so, make these requirements clear, there are the  
base for their implementers.
For example in an RDFa implementation, if there are 'if' or 'case'  
statements, does that mean there exist requirements in the  
specifications depending on syntax constructs?


>  3. Regarding section '2.4.5 Error Handling' in [1]:
>     Do we need to specify an error handling mechanism? Though it might
>     be a bit of an overkill and this is not a strict requirement, but
> rather a good practice, we might want to contemplate on this one as  
> well.

Error handling is very important if we do not want it to be  
implementation dependent. Think about the history of HTML browsers.  
The work of WebApps 1.0 is almost all about this, how to handle tag  
soup.

Think about it in terms of two implementations, when an RDFa parser  
(for example book address extractor) meets a construct which is  
almost understandable but contains errors, what should the  
implementation do?
	- exit? (XML type, not recommended, too draconian for many developers)
	- inform the user of potential errors?
	- recover with a defined process, giving the possibility to markup  
the results as suspicious.
	- etc.

What's happening when a chunk of RDFa information has been extracted,  
how another processor knows that it contains errors? What kind of  
messages a validator should reply to another application, to a human?  
How an RDFa tidy should work?

That would be a good opportunity for someone of your group to  
implement an RDFa module for the markup validator, or Unicorn. You  
could contact Olivier Théreaux, W3C for this.

> I admit that all of this might seem to be a bit early, but again,  
> in the
> light of setting up the RDFa Test Suite, some of these and other  
> related
> issues bother me :)

Not at all early, right on time. The earlier, the better. In a test  
driven way, creating your test cases AND your implementations, when  
developing, will help the WG to refine specification prose and  
discover ambiguities and/or mistakes.

Thanks for your message, hope it will help other people.
Cheers!


>
> Cheers,
> 	Michael
>
> [1] http://www.w3.org/TR/qaframe-spec/
> [2] http://www.w3.org/2006/07/SWD/wiki/RDFa#RDFa_documents
> [3] http://www.w3.org/2006/07/SWD/RDFa/syntax/
> [4] http://www.ietf.org/rfc/rfc2119.txt
>
> ----------------------------------------------------------
>  Michael Hausenblas, MSc.
>  Institute of Information Systems & Information Management
>  JOANNEUM RESEARCH Forschungsgesellschaft mbH
>  Steyrergasse 17, A-8010 Graz, AUSTRIA
>
>  <office>
>     phone: +43-316-876-1193 (fax:-1191)
>    e-mail: michael.hausenblas@joanneum.at
>       web: http://www.joanneum.at/iis/
>
>  <private>
>    mobile: +43-660-7621761
>       web: http://www.sw-app.org/
> ----------------------------------------------------------

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

Received on Tuesday, 13 February 2007 06:08:45 UTC