[oslc-core] Fw: what is the actual intent of resource definition table columns?

[Steve K Speicher]

Action to all Core WG members - please respond with +/- on whether you 
agree with my assessment on the intent of the items below by April 25th.

We hope to at least close on this from a conceptual level, then decide 
what actions we may want to take to fix the ambiguities in the spec.

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

> From: Steve K Speicher/Raleigh/IBM at IBMUS
> To: oslc-core at open-services.net, 
> Date: 04/17/2012 03:33 PM
> Subject: Re: [oslc-core] what is the actual intent of resource 
definition 
> table columns?
> Sent by: oslc-core-bounces at open-services.net
> 
> Thanks for the summary.  I only added a few "guidance" responses to 
> capture what the intent is and agree that we should clarify these 
> outlining the questions you have below.
> 
> > From: John Arwe/Poughkeepsie/IBM at IBMUS
> > To: oslc-core at open-services.net, 
> > Date: 04/13/2012 11:47 AM
> > Subject: [oslc-core] what is the actual intent of resource definition 
> table columns?
> > Sent by: oslc-core-bounces at open-services.net
> > 
> > Three independent threads (including a discussion in Automation 
> yesterday) 
> > converged on the same Core section yesterday.  I feel a bit like Alice 

> in 
> > Wonderland on days like this, but once more into the looking glass... 
> > 
> > [1], under the "Defining OSLC Properties" heading, lays out the 
> information 
> > we see in resource definitions, including the subject columns.  It 
does 
> not 
> > explicitly define the semantics for all of them however, which has led 

> > people to conflicting interpretations of the spec prose.  More 
> importantly 
> > from the perspective of some adopters, it does not lay out explicit 
> testable
> > compliance requirements on client and/or server implementations. While 

> I'm 
> > providing specific examples below to show how this causes problems, I 
> think 
> > we need to keep to the subject question and NOT attempt to answer all 
> > individual questions below now (perhaps we revisit those when/if text 
> > addressing the asserted need is drafted, as evidence of sufficient 
> coverage). 
> > 
> > Neither Steve Speicher nor I could find anything in Core providing a 
> more 
> > rigorous treatment after a good faith, but by no means exhaustive, 
> search. 
> > While not all the interpretations below are equally likely, it is 
> "pretty 
> > hard" to find anything those interpretations actually violate in Core 
> specs,
> > and some alternatives are opposing. 
> > 
> > Example 1: read/only. 
> > 
> > Interpretation 1a: This is "the client's view", i.e. the server MAY 
> change 
> > the value but clients MUST NOT. 
> 
> This is the intent.
> 
> ...snip...
> 
> > Example 2: occurs one-or-many. 
> 
> ...snip...
> 
> > Interpretation 2d: A server MAY accept/store a representation 
containing 
> 
> > zero of those triples, and MAY produce such a representation itself. 
> 
> This is the intent.  With the additional intent that a provider may 
apply 
> additional constraints, we need to make sure to be clear when this is 
> allowed and what is allowed. Provider could/may provide a resource shape 

> to help explain this to clients.
> 
> > Example 3: representation = Either 
> > 
> > Interpretation 2a: A server MAY be capable of storing a representation 

> > (POST-created, PUT, PATCH) containing the in-line resource as an 
object. 
> 
> 
> This is the intent.  See above (2d response).
> 
> > 
> > [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?
> > sortcol=table;up=#OSLC_Defined_Resources 
> 
> 
> - Steve
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>