W3C home > Mailing lists > Public > public-grddl-wg@w3.org > February 2007

Re: Sending Docs to Rec?

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Sat, 24 Feb 2007 18:24:57 -0500
Message-ID: <45E0C949.10709@ibiblio.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:47 GMT