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

[John Arwe]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120413/b16b9a92/attachment.html>