Steve, I replied in a separate note. The attached note is very hard to parse. If you'd like a vote, could you summarize your assessment? Thx.
Regards, ___________________________________________________________________________ Arthur Ryman DE, Chief Architect, Reporting & Portfolio Strategy and Management IBM Software, Rational Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) From: Steve K Speicher <[email protected]> To: [email protected] Date: 04/18/2012 03:21 PM Subject: [oslc-core] Fw: what is the actual intent of resource definition table columns? Sent by: [email protected] 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@IBMUS > To: [email protected], > Date: 04/17/2012 03:33 PM > Subject: Re: [oslc-core] what is the actual intent of resource definition > table columns? > Sent by: [email protected] > > 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 > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
