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. Raises questions of "does client that constraint apply to POST-create", i.e. is this really trying to be "write-once"? What about a client performing a GET/add triple/PUT flow, does this require the client to remove the r/o property values (supplied by the server GET response) before sending the PUT request (even if the r/o values have not changed)? Interpretation 1b: R/O itself is nonsense (incoherent, if you prefer) - if it's truly read-only (implicitly: to all parties) then it can *never* have a value, so it's useless. Example 2: occurs one-or-many. Interpretation 2a: Both a client and a server MUST be capable of accepting a representation containing 30K triples using the predicate. Or 30 billion. [else: non-compliant] Interpretation 2b: A server MUST be capable of storing a representation (POST-created, PUT, PATCH) containing 30K triples using the predicate. Or 30 billion. [else: non-compliant] Interpretation 2c: A server MUST reject a representation containing zero of those triples, and MUST NOT produce such a representation itself. Interpretation 2d: A server MAY accept/store a representation containing zero of those triples, and MAY produce such a representation itself. 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. Interpretation 2b: A server MUST be capable of storing a representation (POST-created, PUT, PATCH) containing the in-line resource as an object. [else: non-compliant] [1] http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#OSLC_Defined_Resources Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
