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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: John Arwe/Poughkeepsie/IBM@IBMUS To: [email protected], Date: 07/26/2012 07:41 AM Subject: Re: [Oslc-Automation] oslc_auto:state property for AutomationRequest - Should this be read only? Sent by: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
