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

[Martin P Pain]

I've added a proposal to this week's agenda to remove the type. 



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
04/03/2014 22:27:38:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net, 
> Cc: oslc-cm at open-services.net
> Date: 04/03/2014 22:28
> Subject: Re: [Oslc-Automation] [oslc-cm] Some comments on Actions 
> spec (most from CM perspective)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> > 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 
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140305/182c278a/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140305/182c278a/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140305/182c278a/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-cm_open-services.net/attachments/20140305/182c278a/attachment.gif>