[Oslc-Automation] Action resources - implementation patterns

[John Arwe]

> > 2: In the final paragraph of [1], a statement is made: "However, as 
> "This" refers to the SHOULD in that same paragraph. The "already 

OK; I'll assume that some clarification either has been or will be made, 
given that I just proved by example that it can parse incorrectly ;-)

> > 3: In the RDF body pattern [4], we say "It is possible for bindings 
> They do not say that the bindings "MUST have a single http:body 
> property, which MUST have a single rdf:type value of...". 

> I have now attempted to make this explicit in the "It is possible 
> for bindings to match [both]" paragraph. 

I suggest "an http:body" --> "at least one http:body" in these cases (not 
having looked at the revisions - so... grain of salt).

> > 4: In the RDF body pattern [4] and resource shape pattern [2], we 
> "a binding" (each binding/a single binding) would be correct. I have
> updated the text to say "a binding". 

I suggest "a single binding", since I read 'a' sometimes as 1:1 and 
sometimes as 1:*, depending on context.
So this is really: if you mean 1:1, club me in the head with it.

> > 5: In the resource shape pattern [2], we say "finding or 
> A) I'd expect that all communications between the client and server 
>    so far have probably used a single serialization/format. This is 
> B) I would expect the consumers to set the Content-Type header. We 
>    should state this explicitly. 

So we might differ here.  My response to the other thread lays out my 
"opaque" assumption for the template case.  Hopefully by the time of this 
week's meeting we can be clear which of those are demanded by in-scope 
scenarios, if they drive different spec content.  "Opaque" I'd really like 
to make work, since it's more loosely coupled IMO, although I would not be 
entirely surprised if "other" cases exist where "completely opaque" won't 
work; in that case we'd have to figure out where to draw the line.

> > 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]? 

My earlier reply reflects this; had not read this response when I Sent 
earlier.  I'll have to think on this.
I agree that if the provider's instructions say blob=x, 
content-type=text/plain AND we say that clients have to understand that 
"sub-type" of instructions, then it would be daft to say "...what he said, 
but -as RDF-".  I was assuming the instructions would amount to blob=x, 
content-type=y and then clients can just treat it like a blob.

> > 10: The construction of Appendix A [12] seemed at odds with itself. 
> In any case, these are not contradictory - the second section is 
> intended to require providers to offer at least onebinding per 
> action that meets these conditions, not imposing these conditions on
> all bindings (again, I've tried to make this clearer). Therefore 

I may have finally figured this out.  If it's clearer now, can't hoit.

> By "literal body" I mean something like text/plain (or binary data), 
e.g. : 

OK - good to know how that fits in; dovetails with my desire for opacity 
in those bodies.  I was thinking of the CM scenario where it's RDF that is 
expressible as, say, Turtle (which is under text/* so it's literal in that 
sense).  WRT non-RDF bodies, OK to allow it and understand how it fits in, 
not completely sure we need to specify it now (as long as we're sure it 
can be added compatibly).

> 11. In the "what are actions?" section [13] it now says "without 
> knowing anything about R other than its URI and (perhaps) how to 
> construct HTTP requests given instructions". However, "how to 
> construct HTTP requests given instructions" is not really "about R".
> Unless you mean "consumers must be able to retrieve R's triples". 

Ha!  I hear the parens in a different place.  Knowing what (I think) it 
says, I hear it as:
"without 
> knowing anything about R other than its URI and 
> (perhaps) how to construct [generic] HTTP requests given [generic] 
instructions"
not as 
> knowing anything about R other than its URI and (perhaps) how to 
construct [generic] HTTP requests [against/to R]
> given [generic] instructions"


> 12. Not related to your changes, but we have a "MUST" in the 
> "providers" section [14] under the "Overview (informative)" section 
> [15]. There is an equivalent MUST under the "instruction for 
> executing currently available actions" section [16], so I've just 
> removed the bold markup from the one in the informative section. 

Also remove the caps, if you haven't.  Practice I've picked up working on 
LDP.


> 13. Under "instructions for executing currently available actions" 
> [16] these words: "A consumer executes an action by following a 
> single interaction pattern that it supports, and applying 
> information supplied in the action binding to the pattern. A consumer 
MAY
> use any interaction pattern whose identification rule is matched by 
> the action binding. " seem to suggest that a consumer MAY use an 
> interaction pattern that it supports even if its rule did not match.
> Otherwise what is that MAY saying other than that they also might 
> not? While it does not make sense for consumers to do so, should we 
> include a MUST somewhere? e.g. "A consumer MUST use one of the 
> interaction pattern(s) whose identification rules are matched by the
> action binding it has chosen."? 

This was attempting to cover the case where a single binding matches n>1 
interaction patterns, and saying "we don't care which you choose, of those 
you support that match the binding".
Were you perhaps reading "A consumer MAY use any interaction pattern whose 
identification rule is matched" to say "use an" instead of "use any"?
In which case "use any ...pattern(s)" or "use any (of possibly multiple 
matching) ..." might help?


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/20140106/a77e80a6/attachment-0003.html>