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
