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

[David N Brauneis]

I completely agree with what John is stating here - we are trying to make 
the specification work for most clients, therefore some 
AutomationProviders may have to deviate to achieve their use cases... 

Remember that this is not an RQM specification but is much broader, in 
this specific case I would consider the worker agent a part of the 
AutomationProvider's implementation details.

Regards,
David
____________________________________________________
David Brauneis
STSM, Rational Software Delivery Automation Chief Architect
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874



From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     oslc-automation at open-services.net, 
Date:   07/26/2012 07:41 AM
Subject:        Re: [Oslc-Automation] oslc_auto:state property for 
AutomationRequest -     Should this be read only?
Sent by:        oslc-automation-bounces at open-services.net



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 
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120726/d14d4bb6/attachment-0003.html>