[Oslc-Automation] oslc_auto:state property for AutomationRequest - Should this be read only?

[John Arwe]

Domain specs are written from the perspective of setting expectations for 
"most" clients/servers.  You might want to take a look at the discussions 
around Core issue 43 that I've been drafting changes for over the past 2 
months [1].  The live TWiki Core specs now have all the pertinent parts of 
43 fixed.

The case you are talking about could view the worker agent several ways: 

1: narrowly ... it's an HTTP message exchange, and the worker agent's role 
in the exchange is HTTP client

 or 
2: broadly ...the worker agent is part of the Automation provider's 
implementation details, so the rules for "most" clients do not apply.

The goal is integration that works for most cases, not a strict compliance 
test; compliance tests make good chartware, but plenty of history out 
there to demonstrate that spec compliance != guarantee of interop. 
Implementations (provider *and* client) may violate domain specs when 
needed; if any violation meant "non-compliant", many trivial cases could 
be used to show that NO implementation is compliant with ANY domain spec: 
"infinite" sized literal objects cannot be parsed, multi-valued properties 
could not be used, etc. [2]

If we accept the proposition that the majority of Automation clients the 
spec is written for are NOT part of the provider implementation whose 
Automation resources they are interacting with, then r/o seems like the 
correct expectation to set.



[1] http://open-services.net/bin/view/Main/OslcCoreV2Issues
[2] http://www.youtube.com/watch?v=8nm1gbMhYDY

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-automation_open-services.net/attachments/20120726/bbecb6a8/attachment-0003.html>