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

[Steve K Speicher]

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