[Oslc-Automation] OSLC Actions - implementation patterns

[John Arwe]

I'm looking at the latest revisions to Core actions, that resulted from 
some offline meetings to try and keep this moving despite the holidays.

For me, we have to have terminology straight +and+ consistent in the draft 
before we put other peoples noses into it.  Just to help them understand 
it, vs engaging in sense-making (i.e. guessing) whenever they hit an 
ambiguity.

Hence, step 1 is terminology.  I myself am not crystal clear on that 
section yet.  I read down into the overview to see if that helped, but 
that has not obviously been realigned yet; it talks mostly about actions 
and impl profiles (including "finding" them, which gets into the next 
question below).  Terminology (the section) right now relates: 

0: Action as the semantic (also the stopping point, so it's not turtles 
all the way down)
1: 1 Action has n Action implementations (good), 
2: 1 Action implementation uses 1 interaction pattern (good, "I think" ... 
since we have extension, 1 IP is questionable), 
and then 
3: Implementation profile is neither referenced by the other 3 nor does it 
obviously reference them (bad, and quite possibly a "feechur" in the 
base).

Would it be correct to say/add something like:

An implementation profile adds its constraints to one (? or more?) 
interaction pattern(s).



I think the current draft also says that clients "deal in" interaction 
patterns, since interaction patterns are (provide?) the uniquely 
identifiable syntax that a client (looking for an implementation that the 
client's capabilities are "compatible with") uses to filter out action 
implementations it cannot actually use.  If that's the case, are 
implementation profiles actually required, and if so why (for whom)?  If 
clients cannot identify them, as a Devil's Advocate I'd have to ask why 
they're interesting at all.  If they're "just" a spec authoring device, 
(a) we can be clear about that (b) they're probably a non-normative 
footnote in essence.

As an example: all the  "CM profile" [2] does is restrict choices that 
reduce the *server*'s degrees of freedom.  CM clients (who cannot tell 
that the CM profile is in use via any assertions, only via duck-typing 
what it finds in the implementation) just take whatever request URI they 
find, whatever method they find, deal with a body from a resource shape if 
necessary, smash it all together, and send it.  Any client that wants to 
claim it can process actions using the “Resource shape HTTP request” 
interaction pattern MUST be able to do so with ANY request URI, and ANY 
method, since it has no way to identify/assert (given that implementation 
profiles are not identifiable) that it only supports the CM implementation 
profile.





[1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/
[2] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#POST-RDF-described-by-a-OSLC-Resource-Shape-to-the-Action-resource

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131218/7dbfcc44/attachment-0003.html>