> 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.
What would you make of this sort of definition? An resource (action) of type oslc:StateTransitionAction MUST contain an oslc:targetState predicate set to the value that the context's "state" property will be changed to by executing this action. Actions of this type, if successful, MUST change the object of the a triple, whose subject is the context resource and whose predicate is the "state" predicate defined by the resource's domain, to the value stated in the action resource, as part of a state machine[1][2] (which MAY be finite or infinite). Consumers MAY list all oslc:StateTransitionActions from a particular context together, for example in a drop-down list, as the list of valid states that this context resource may go to in its state model. [1] http://en.wikipedia.org/wiki/Finite-state_machine [2] http://en.wikipedia.org/wiki/State_transition_system (Of course, if making this general, we might want to make it explicit in the data what the state predicate is in the context resource, which might allow multiple state machines per resource as different actions could refer to different "state" predicates. This then makes it more complicated than the CM example as it currently stands.) 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 30/01/2014 13:40:07: > From: John Arwe <[email protected]> > To: [email protected], > Cc: [email protected] > Date: 30/01/2014 13:40 > Subject: Re: [Oslc-Automation] Some comments on Actions spec (most > from CM perspective) > Sent by: "Oslc-Automation" <[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. > > 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-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
