[Oslc-Automation] Synchronous execution

[John Arwe]

Simple answer, my reading is that either representation is allowed; I 
think that is in line with the authors' intent (speaking as one of them, 
and as the motivator/advocate for this style in 2.0).  The implementation 
I am familiar with using this style uses the second form (multityping). 

"always 404" allowed?  yes.  2.0 does not specifically encourage this 
behavior, but again it is allowed by what is said.  Indeed it must be by 
some reckonings, otherwise server implementations would be constrained 
from ever garbage-collecting old resources even if failing to do so 
crashed said servers.

> If that is true, then is the URI still needed in the RDF in order to 
have a value to set for the oslc_auto:producedByAutomationRequest 
property,

That property is 0:1 in the spec, so (definitionally) I think the answer 
is no URI is required; could be a blank node.
If both are present and have different values (that is: the "create 
AutoRequest  response is or contains both an AutoRequest and an 
AutoResult, all components of the response have URIs, *and* this predicate 
has a different URI than any of the preceding"), then I think the server 
is providing an inconsistent response and I (as a client) would treat that 
as an error if I detected it.  A simple client would probably assume that 
any AutoResult contained in the response message was "the AutoResult", and 
would expect to dereference its URI (if any) in cases where the 
AutoResult's state/verdict are still changing (exact conditions noted in 
2.0 spec).


> or if an automation request also has an rdf:type property set to 
oslc_auto:AutomationResult, is it valid to assume that that is the result 
for that request?

I don't recall the 2.0 spec explicitly saying if such an assumption MUST 
be made, SHOULD be made, or MAY be made.  Many specs (including OSLC) are 
silent on some cases, sometimes intentfully and sometimes via simple 
omission.  Writing single specs usable by providers (who often want to 
know Only What I Must Do) and consumers (What Can I Rely On) is a 
balancing act, and one form of response is the existence of companion 
documents like the Primer.   In those cases, the common strategy is to 
mostly limit the normative spec to what providers need to know, and expand 
upon that (and its implications) in the informative companion documents. I 
think this is what Automation attempts, although I freely admit energy to 
flesh out the informative material wanes ... as you will no doubt find 
when following the link below.


> useful to explicitly mention the situation where the request and 
response are the same resource, and probably include an example too. 
Fine candidate for 
http://open-services.net/wiki/automation/OSLC-Automation-Primer-2.0/#Synchronous-scenarios
.  Should be able to point to the ibm.com manuals on the Jazz for Service 
Management Resource Registry (part of Registry Services) for the 
multityped case, too.  The Primer should not be access-controlled, so you 
can just edit and point the list at it for reviews.


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/20130613/4da4bb97/attachment-0003.html>