[Oslc-Automation] Action resources - implementation patterns

Fri Dec 27 14:03:32 EST 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20131227/6c88cde9/attachment-0003.html>