[oslc-core] Core Issue 43 : "read only and friends" - representation requirements

[John Arwe]

Per my action from last week, I've started to draft clarifying changes for 
the subject issue [1].  In comparing the text in Core (defining resources) 
[2] and Core Appendix A (resource shapes) [3] I've run into some new cases 
that we have not discussed in [4] or [5] or IIRC the calls, so the 
original intent is unclear.  I'd like to get some feedback on that, with 
the hope of consensus emerging that I can work into the draft before 
posting it.  To make the threading help as much as possible, I'll be good 
and keep it to one issue per thread.

This thread: [5] never resolved whether spec constraints in the resource 
definition tables are MAY or MUST. 

Representation was used as the specific example in the email, but it's 
going to be a general issue.  I.e. 

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]

Some Core members thought the correct interpretation was

[6] 2a: A server MAY be capable of storing a representation (POST-created, 
PUT, PATCH) containing the in-line resource as an object.

Others said:

[7] Both representations are valid (your 2b) 
That being said, there will always be server limitations, so a server has 
the right to refuse a request that violates size or time constraints that 
are unstated anywhere in an OSLC spec.

and this discrepancy was generalized in [5]
Ok, we are arguing over MUST or MAY on this one.  So I agree that when a 
server advertises its support via the resource shape then it MUST support 
this.  I was taking the original "informative" approach to tables within 
the specification, which I do not think we can treat as a MUST.

The latter excerpt [5] cannot be blindly generalized, even if it is 
accepted for representation (which itself is not settled, based on the 
email trail), since by reductio ad absurdum it would mean that an 
implementation can completely ignore the specs as long as it does what its 
resource shapes advertise.


Core does not define compliance that I can see, but domain specs (example: 
CM 2.0 [8]) have a compliance section up front with language like: "This 
specification is based on OSLC Core Specification. OSLC [domain] consumers 
and service providers MUST be compliant with both the core specification 
and this specification, and SHOULD follow all the guidelines and 
recommendations in both these specifications."  I'm guessing that Core 
relies on the social definition. 

Thus "compliance" divides things into "specs" vs "guidelines and 
recommendations".  I had always assumed the resource definition tables to 
be part of the spec, which I inferred to mean they are MUSTs;  [7] 
supports that interpretation, as does [2] ("OSLC Specifications MAY 
provide a list of properties allowed and/or required for a particular 
operation on an OSLC Defined Resource. Specifications that do so SHOULD 
provide the following information for each property that they define." ... 
explicitly says specs provide lists of property requirements).  I don't 
see how to read [5] as a MUST, seems clear Steve's intent is "not MUST"; 
indeed, if Steve was being precise when he said "informative", then by 
definition the tables would fall into the "guidelines and recommendations" 
category.


I came in far too late in the game to have a clear idea in my head of what 
Core's intent was, so I need Core to settle this in order to draft content 
that communicates this intent.  It may be that in addition to settling the 
general question of intent (are resource definition tables "spec" or 
"guideline"), we need to see what implementation freedom Core intended to 
allow per-column, so if you think that distinction needs to be made then 
call those out in your answer.




[1] http://open-services.net/bin/view/Main/OslcCoreV2Issues
[2] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#OSLC_Defined_Resources
[3] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource
[4] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001288.html
[5] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-May/001314.html
[6] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001292.html
[7] 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001299.html
[8] http://open-services.net/bin/view/Main/CmSpecificationV2

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/20120523/ac684470/attachment-0003.html>