> 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
