- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Sat, 24 Feb 2007 18:17:57 -0500
- To: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
- Cc: "McBride, Brian" <brian.mcbride@hp.com>, public-grddl-wg <public-grddl-wg@w3.org>
Hmmm...one obvious solution is to table this discussion till after we get the GRDDL Spec to Last Call. However, I am still interested in hearing people's opinions on the issue. However, I am at this current moment even more concerned about getting GRDDL Spec Review... Chimezie Ogbuji wrote: > > 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 > -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Saturday, 24 February 2007 23:18:13 UTC