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@IBMUS > To: [email protected], > Date: 04/13/2012 11:47 AM > Subject: [oslc-core] what is the actual intent of resource definition table columns? > Sent by: [email protected] > > 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
