- From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
- Date: Sat, 24 Feb 2007 10:22:32 -0500 (EST)
- To: "McBride, Brian" <brian.mcbride@hp.com>
- cc: Harry Halpin <hhalpin@ibiblio.org>, public-grddl-wg <public-grddl-wg@w3.org>
On Thu, 22 Feb 2007, McBride, Brian wrote: > Harry, > > As best I can understand it, your argument is: > > 1. there are different audiences for the different docs I agree with this point, and is my primary concern with a scenario where only the specification is the most prominent document that both implementors, authors, and people with general interest read. > 2. we have show that we take each audience seriously I personally, couldn't imagine a scenario where a person with just an introductory understanding of RDF had to contend with the specification and I don't think it is reasonable to expect that the specification serves all of these audiences. > 3. ergo each document should be rec track. > I don't see taking a document rec track as some sort of certificate of > seriousness. It may be a certificate of stability and of consensus (so > its worth implementing the spec). This is the *real* problem, in my mind. We don't seem to have a consistent (or even coherent) criteria for what rec track means with regards to the documents we decide to take that route. Dan suggested (in the last telecon) that the criteria is completely up to the WG, so I think rather than try to decide which documents we take down the REC track (without any consensus on what it means for *us* to do so) we should ask instead what REC track means for GRDDL. To me, it is twofold: coherent functional requirements and a coherent set of literature for introductory and intermediate-level audiencess. The two are mutually exclusive and therefore one document will simply not do both. If functional requirements (unambigous engineering details) is the only criteria then the documents we should be aiming for REC track should be the specification and the test cases. Now, IMHO, the test cases are nowhere near coherent in their coverage of the functional requirements we have consensus on so far and it is *still* unclear to me how we are handling situattions where we have multiple outputs from a single input. It seemed to me (niavely perhaps) that conformance labels spoke specifically to functional 'conformance' and not 'setting the tone in the market' as was suggested in the last teleconference. If indeed we are using SHOULD / MUST / etc.. language to set the tone in the market then that is a stronger suggestion that our criteria is not functional requirements alone. > I speculate that what a CIO cares about is a) whether GRDDL will be good > for his organization b) that it is an open standard with > implementations. A CIO will *never* be able to determine a) from the specification alone. > A spec that is a rec takes care of b. > The primer explains what it does > so takes care of a - whether or not it's a rec. Actually, I think the question of a) is answered by *both* the usecase document and the primer. We could decide to take only the spec to a REC (on the grounds that functional requirements are our only immediate interest). However, if as a result of this the primer and the usecase document don't get the exposure for review they need that would only put them at risk for being able to answer a) for a CIO. The time restrictions (which I think are unfortunately short) seem to make functional requirements the only feasible criteria for REC track and so unless our time constraints are relieved a bit, we really have no choice but to take only the specification down the REC track - but we should at least be aware that it puts us at risk for readability for the intermediate audience (which will comprise the majority of our audience) > Brian > > Chimezie Ogbuji Lead Systems Analyst Thoracic and Cardiovascular Surgery Cleveland Clinic Foundation 9500 Euclid Avenue/ W26 Cleveland, Ohio 44195 Office: (216)444-8593 ogbujic@ccf.org
Received on Saturday, 24 February 2007 15:22:56 UTC