[Oslc-Automation] state property for requests

[John Arwe]

>> The spec says that requests must include at least one value for the 
>> "state" property. Does that apply also to POSTed request payloads, 
>> or only to request resources that are created on the provider? 


> The oslc_auto:state should not be on the Request when it is POSTed -
> it is Read Only.

is a non-sequitir.  It was (fairly recently) rendered explicit that the 
correct interpretation of read-only=yes in a resource definition [1] is to 
set an expectation for behavior -after- create.  It is silent on Create. 
The corresponding text in [2] is intended to convey roughly the same 
meaning, although the phrasing is harder to parse since [1] is about spec 
interpretation and [2] is about implementation introspection.

Since Core 2.0 is underspecified with respect to expectations on Create, 
as the question deftly proves, perhaps as you said in the other thread 
this is a good candidate for informative guidance.  I will also ask Core 
to work better coverage of this into the Core 3 proposal.  I suspect 
read-only => not allowed on create is the most common interpretation, but 
it is by no means the only one.



History buffs with strong stomachs and tall boots can wade into the deep 
waters of the famed Core Issue-43 via [3]

[1] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#OSLC_Defined_Resources 
in the bullet list entry for Read-only
[2] 
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;up=#oslc_ResourceShape_Resource
[3] http://open-services.net/wiki/core/OSLC-Core-V2-Issues/ new wiki, 
where old "core issue 43" is at this moment shown as "[Core] Finalization 
issue 11"


Best Regards, John (order of the Knights responsible for jousting with 
Core Issue 43)

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-automation_open-services.net/attachments/20120830/9a6682b8/attachment-0003.html>