[Oslc-Automation] [oslc-cm] Some comments on Actions spec (most from CM perspective)

[John Arwe]

> Either that second action needs rdf:type oslc:StateTransitionAction or 
it is stating a side-effect not an intention/desire. 

I was not going all the way there, but any illumination the question 
caused I'll happily accept credit for ;-)    Could have been that there 
was/is another reason for its absence that I just didn't see.

If it *is* added to the second, then the type alone simply is no longer a 
distinguishing characteristic, so the narrative that the client uses it in 
one case but not the other falls apart.  If the just-deconstructed 
narrative was the only justification for defining that action type, it 
appears we can define less without losing the ability to support the 
scenario - and that's what we should do, if true.

Just because I was reading in some "intentful" connotation, means neither 
that doing so is/was correct nor that distinguishing between intent-ful 
and side-effect in prose is feasible in any reliable way.  It seems we all 
agree *that's* a lost cause.  It seems likely to me that the distinction 
is based on how the client is using it, just like the template discussion.

Hence, running Steve's logic forward, a client that just wants to suspend 
the work item could choose to look only at desiredState, and since (in 
this example) it has a choice, it can choose any of them.  A client that 
understands all the types involved could use them to break the 
desiredState tie; a client that only knows oslc: types has no information 
it can use to prefer one vs the other, and will do whatever it's coded to 
do (punt to an error flow, pick according to some unspecified algorithm, 
ask a user, etc).  Maybe it prefers Actions whose type set it fully 
understands, in which case the (present but opaque) extra type on the 
second means it avoids that choice.  We can't stop this case from 
happening, that I can see, without abandoning the duck-typing (which is 
what pattern recognition rules boil down to) that we're relying on for 
flexibility and extensibility.  The client code either understands all of 
the content, or it doesn't, and in either case it has to choose if/how to 
proceed.


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/20140304/b365d33f/attachment-0003.html>