RE: Sending Docs to Rec?

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