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: [email protected] 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" <[email protected]> wrote on 04/03/2014 22:27:38: > From: John Arwe <[email protected]> > To: [email protected], > Cc: [email protected] > 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" <[email protected]> > > > 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 > [email protected] > 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
