- From: Karl Dubost <karl@w3.org>
- Date: Tue, 13 Feb 2007 15:08:11 +0900
- To: "Hausenblas, Michael" <michael.hausenblas@joanneum.at>
- Cc: <public-rdf-in-xhtml-tf@w3.org>, <public-swd-wg@w3.org>, <www-qa@w3.org>
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:48 UTC