- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Sat, 24 Feb 2007 18:24:57 -0500
- To: Harry Halpin <hhalpin@ibiblio.org>
- Cc: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>, "McBride, Brian" <brian.mcbride@hp.com>, public-grddl-wg <public-grddl-wg@w3.org>
So in case that wasn't clear, we can get the GRDDL Spec to Last Call, and if the WG thinks (and opinion is clearly divided right now) that Primer and Use-Case docs (and possibly tests) should go Rec track, then we can do that *after* we send GRDDL Spec to Last Call. There is something to be said for having multiple documents go to Last Call as a group, but this is one way to get more time for other non-Spec docs if needs be. Harry Halpin wrote: > 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:25:09 UTC