Re: Sending Docs to Rec?

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