> From: John Arwe/Poughkeepsie/IBM@IBMUS > To: [email protected] > Cc: [email protected] > Date: 02/26/2014 11:33 AM > Subject: Re: [oslc-cm] [Oslc-Automation] Some comments on Actions spec (most > from CM perspective) > Sent by: "Oslc-Cm" <[email protected]> > > > Comment on section [2] > > I'm not sure why the domain specific types are here. Seems like > > something that would be in CM spec. In fact, we probably wouldn't > > define a oslc:StateTransitionAction but instead just call it > > oslc:Action. Seems like the parent class is extraneous. Clients > > will be looking for oslc_cm:targetState to determine which action to pick. > > What value is there in having this separate type? > > Personally, I've been dubious about oslc:StateTransitionAction for a while > but I've been letting the rest of it settle a bit before calling it out.
> "Dubious" simply because all write requests... generic PUT, PATCH, POST, etc > but also all actions which a purist might argue act like POSTs (in terms of > their effect) with some hypermedia decoration for client discovery... are/ > might be state transition requests. It's so general that I am and have been > unclear what it adds beyond oslc:Action; it is entirely possible that such a > difference exists and simply has not been articulated such that I can grasp > it, but that's my current state. > That was my original comment [1] and Martin seemed to acknowledge its limited usefulness [2]. If I were a CM client, looking for a particular Action, I wouldn't look for rdf:type at all. I would navigate oslc:action from a change request, or if it had some oslc_cm: domain predicate, to a resource which had the properties I was interested in: namely oslc_[cm|auto]:desiredState to pick the right action and other terms to know where and what to POST. The object of :desiredState tells me all I need to know which one to pick. So from a client/server interaction, I don't need the sub type. From a query/reporting point of view, I don't have any queries I can think of. Brainstorming on it: show me all in-progress change requests that have oslc:StateTransitionActions. Not sure I see a use case or need for it. Seems like oslc:Action and :desiredState would be enough. I see you have oslc:UpdateAction, which doesn't really help the CM clients either (as not sure I'd even look at the type unless I REALLY wanted to validate everything I fetch). So I've propose to remove oslc:StateTransitionAction from the Action spec. It could be added back later if a clear need arises. [1] - http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000635.html [2] - http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000636.html Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net > Turning it around: if I have some action Foo that I want to expose, I would > hope that the type definition would tell me whether or not I should be using > oslc:StateTransitionAction amongst the types. If, in effect, all actions > are of types oslc:StateTransitionAction and oslc:Action, that's evidence > that they're redundant. If we find a scenario where clients cannot run the > scenario without oslc:StateTransitionAction (which is different than saying > it Can be used), that would be evidence that it's really needed and might > lead to a description that distinguishes it from :Action. > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > _______________________________________________ > Oslc-Cm mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
