I did a reasonably slow, focused, top-to-bottom read of the Core Actions draft, and made some updates over the past 2 days. I think we're getting really close.
The 12/26 edits should be completely non-controversial. Typo, adding links, etc. Today(12/27)'s edits are very likely non-controversial. Smaller-scale cleanup of certain sections. Probably worth a look from Martin to be sure I didn't accidentally vary from his intent. The big-animal outstanding questions/comments I had are listed below. 1: Secondary bindings: I think we should cover that entirely in Automation, not Core. 1a: Let Core be about Actions -- the parts that multiple parties need (UI introspection, bindings, and "execute now" discovery). The only thing I'd leave in Core around delayed execution is the interaction pattern heading, and make its content consists entirely of text (probably non-normative) pointing to Automation as having defined such an interaction pattern. 1b: Let Automation cover the delayed execution angle. That's the only place the need has arisen. Any "complications" like secondary bindings it can pay for, rather than obscuring further what Core is doing. It's every bit as re-usable from Automation as from Core. 1c: Secondary bindings might become "immediate execution action bindings" instead. Once they're relegated to Automation, it's harder to confuse them with Core's bindings ;-) 1d: I think Automation (when it defines delayed execution's pattern) states (as part of that pattern) which existing action bindings are/not allowed as secondary bindings, along with any additional constraints those usages have. If we can't do that, something is fundamentally wrong. I.e. if the only way to define the zero-body http request interaction pattern (or any other in Core) so that it "works right" when we later want to add a delayed execution interaction pattern is to know about the future when defining zero-body, we're toast already. Automation will need some generic statement like "we're silent on; might work, might not" to cover cases where new Core patterns/bindings/profiles are added in the future, but that's life in the big city. 1e: In the existing "Use for secondary bindings" text, there is a consistently repeated phrase "then it is to behave like" ... am I correct in thinking that one is expected to read "it is" as a normative MUST? 2: In the final paragraph of [1], a statement is made: "However, as already stated, implementations MUST NOT rely on this behaviour from other implementations". I was going to lowercase the must-not (since it's a restatement), and make the bulk of that text a hyperlink to the original, but I'm unclear after reading it what it's referring so I cannot create the link. It might be referring to the beginning of the same paragraph (which has a MUST NOT); I cannot be sure what the final sentence's "this" refers to. 3: In the RDF body pattern [4], we say "It is possible for bindings to match the identification rule of both the HTTP request with empty body pattern and this pattern." I don't think that's actually true; the zero-body pattern [3] says " MUST have an rdf:type value of http:Request, and MUST have an http:body value of rdf:nil.", whereas the RDF body pattern says "MUST have an http:body property whose target resource:" ...other constraints that rule out rdf:nil. 4: In the RDF body pattern [4] and resource shape pattern [2], we say "It is possible for bindings to match the identification rule of both the HTTP request with empty body pattern and this pattern." In that context "bindings" (plural) could mean "different bindings on the same Action resource", but I think the intent might have been "each [or: a single] binding". I was not sure enough to update it on the wiki however, given that others will be reading that possibly in parallel. 5: In the resource shape pattern [2], we say "finding or constructing an RDF resource that matches the defined resource shape and using an appropriate serialisation of that resource as the HTTP request body." I don't see how a client is going to know which serialization(s) are "appropriate", and given that this is an input we'd certainly *like* it to be both concrete and asserted (Content-Type: header) on the request rather than relying on the provider (recipient) engaging in content-sniffing or on out of band means. We could use http:headerName etc for that; doing so would require changes to Appendix A's "common restrictions" [5]. The RDF body pattern [4] has the same issue. 6: In the RDF body pattern [4], I'm not sure what the extra(?) level of indirection through oslc:ContentAsRDF buys us. Is this simply to follow the patten of [6]? 7: The Automation pattern [7] made reference to "the HTTP request pattern" (sic), which no longer exists. I think from the context it intended to say "request with RDF body" i.e. [4], so I did create that link (just in case I guessed wrong, others now know). The same case+fix arose in [9]. 8: In the final bullet of [8], we talk about something that sounds like a server implementation issue. If that's the case, seems like a Best Practice (at most), not normative text. 9: In the delayed execution pattern [10], [11] left me in the dust (I saw no sign of this in the examples or ODT, either). Conceptually I'm "sure" I know what you're saying, it's simply omitted syntax/examples I think. 10: The construction of Appendix A [12] seemed at odds with itself. In the first section: "a consumer MUST...include the headers specified by the http:headers property, if present", and in the second section "providers MUST provide bindings that: do NOT include the http:headers property". This might be smart spec factoring if we're trying to separate "simple profile" constraints from "support all of http:Request". 10a: If consumers are required to support http:headers anyway, then this must be about saving providers' implementation budgets. But that's in their own best interests anyway, so what do we gain again? Promising consumers that we'll never use the code we just said they had to write? FWIW I've (recently) seen implementations completely dependent on extension headers for authentication; although that "just" means they'd need to define profile(s) instead of re-using these. 10b: [12] end first section says "Note: If OSLC implementors want to specify literal HTTP request bodies (which are not covered by any interaction patterns in this specification)" I think that's no longer true (RDF body?), or did you mean something different by "literal body"? [1] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Types-of-actions [2] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-resource-shape [3] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-empty-body [4] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-rdf-body [5] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Standard-restrictions-on-http.3ARequest-resources-for-simple-specification-profiles [6] http://www.w3.org/TR/Content-in-RDF/#ContentClass [7] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-autoreq [8] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Additional-provider-constraints [9] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Execution_3 [10] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-dialog-delayed-execution [11] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Additional-provider-constraints_1 [12] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#constructing-http-requests Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
