[oslc-core] Can we / should we add a 'Compliance' section to the OSLC Core domain

[Steve K Speicher]

John,

Also to point out in CM we have another spec summary table we use to help 
understand completeness of implementation reports.  This was one of your 
points.  I think its purpose is different and therefore we created a 
separate spreadsheet for that with more rows and make no assumptions or 
indications that it IS the spec.

See CM Implementation Reports - 
https://spreadsheets.google.com/ccc?key=0AsgaoPBj7epTdEw1MW41OEJmRlozQlpMM1Rxel9KRUE&hl=en&authkey=CKfzkPAB#gid=0 


Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


> From: John Arwe/Poughkeepsie/IBM at IBMUS
> To: oslc-core at open-services.net
> Date: 03/09/2011 02:06 PM
> Subject: Re: [oslc-core] Can we / should we add a 'Compliance' section 
to the 
> OSLC Core domain
> Sent by: oslc-core-bounces at open-services.net
> 
> I always hesitate when presented with can/should questions about specs, 
> especially in a standards context.  Can one build tables that (in 
theory) 
> summarize existing content?  Sure.  Should one?  Value judgement, which 
means 
> it devolves to a set of trade-offs and one's own opinion of relative 
probabilities. 
> Depending upon the use cases we are interested in solving, perceived 
effort, 
> assumed audiences, and perceived probability of various failure modes, 
people 
> often come to different conclusions.  I'm not sure exactly which use 
cases you
> have in mind from your post. 
> Take CM's table as an example.  Text before it says: " The following 
table 
> summarizes the requirements from OSLC Core Specification as well as some 

> additional specific to CM." 
> If you summarize in that way, there needs (?) to be some provision 
around what
> happens in the case of a conflict, i.e. the summarizing table says, or 
appears
> to say, something different than the summarized content.  Which wins 
(takes 
> precedence)?  Some people like to pick a winner in the spec in advance 
(e.g. 
> in case of conflict, the summarizED content wins), usually to avoid 
delays 
> while the owning "standards organization" resolves the conflict.  Others 
take 
> that tack that it's better to force humans to resolve the conflict, even 
if 
> that delays implementations, so they want the spec to explicitly say "no 

> winner, owners must revise to resolve". 
> If the summary does not win (it is, essentially, informative not 
normative) 
> then it's (probably) duplicate content.  The tradeoff is increased spec 
> maintenance effort to keep things consistent across changes, vs 
convenience 
> (assuming it is consistent) or confusion (if inconsistent) for consumers 
of the spec(s).
> A separate but related variety of the same problem is completeness.  CM 
> appears specifically say "table mays be incomplete".  This leads to the 
"if 
> it's not complete, how useful is it" meme.  FWIW I'm fine with 
incomplete, 
> just says I treat it as a starting point. 
> Summarizing can also be hard occasionally, due to context and chains of 
> implication.  As an example, "OSLC Services MUST support query responses 
in 
> RDF/XML format (media type application/rdf+xml) and MAY support other 
formats"
> looks like a MUST, but it's 'nested' under (a consequence of) supporting 
the 
> Query Capability (which is a 'may').  If an implementation does not 
support 
> the QC, the current language as I read it says it may or may not support 
RDF/
> XML.  It's a common problem in spec writing. 
> If I mentally put on my developers' hat(s), in the large I suspect 
they'd say:
> a compliance table is exactly what I (as a service provider 
implementation 
> owner) want to see.  I want the list of exactly what I need to think 
about, 
> and the minimum level necessary to assert compliance for the purposes of 
wide 
> interop, and nothing else. 
> Someone acting as a service consumer likely wants a similar list (scoped 
only 
> to them).  That would imply, for example, splitting CM's first row into 
two 
> separate assertions, and either adding a column or having a separate 
table for
> reqts on clients.  I don't know how to slice & dice 'best' it w/o going 
back 
> to use cases and then getting into the discussions about priorities, 
probabilities, etc.
> I find summaries are generally helpful for new people, and as sanity 
checks 
> e.g. when reviewing a new provider implementation.  The CM approach 
seems like
> a reasonable set of tradeoffs (to me, based on my unspoken assumptions) 
that 
> could be duplicated in Core. 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli Component Technologies 
_______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net