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
