[Oslc-Automation] Templates: Submitting as blank nodes?

[John Arwe]

> The new template dialog section [1] of the spec does not include any
> instructions on what to do with such a template.
> 
> I know (or at least think I know) from the previous discussions that
> the intention is to submit it to a creation factory.
> Firstly, this is not stated. (Admittedly, consumers can do anything 
> they like with it when they have it, so we don't want to restrict 
> this, but perhaps we should express our intention. Perhaps a link to
> the scenario page?)

Agree we should say something explicit. 
Link to scenario flow too.  Since scenarios are not normative, need more.
IIRC we have link(s) FROM each Action-template-dialog TO 1:* 
Creation-dialogs known to be capable of consuming the template dialog's 
output resource... and that should be MUST be capable of consuming, since 
that's what's needed for interop.

> Secondly, this template will be a resource with a specific URI. When
> you submit it to the creation factory, if you do no processing of 
> the resource you will be submitting it with that template URI. The 
> Core spec on creation factories [2] doesn't state whether the RDF 
> being POSTed to it should be a blank node or have a URI - and if the
> latter, what it does with that URI.

I would simply make the requirement that the template-dialog-output 
resource's representation MUST be consumable as input to a standard 
creation factory (which already has all the same problems).  The provider 
has to forge the linkage, as the simplest thing that can work.  Do we have 
any scenarios that require the two dialogs be provided by separate 
providers?  If so, we'd have to specify more probably.

> I guess, as it currently stands, it would be up to the 
> implementation to either replace the URI in the representation 
> POSTed to the factory, 

I.e. act as a standard creation factory. The question of how to interpret 
input subject URIs is underspecified today, although LDP addresses it for 
the case we normally consider (null relative URI, "<>" in Turtle terms). 
Or if you prefer, today it devolves to HTTP POST's allowance to use any 
request-body as "instructions" for what to do, which is underspecified 
with respect to create if you demand interop based purely on the HTTP spec 
contents.

> or to create the new AutoRequest at the same 
> URI (although this might cause problems if submitted more than once).

Actually I don't think Create (201 response) is an issue;  "create at the 
same URI" is a technical worst (violation of best) practice in WebArch. If 
the server replies 201, the client expects that a resource unique in time 
and space has been newly created.  Since it's unique, it has a new URI.

Automation's various permitted patterns however already assign a meaning 
to a 200 response, so things could be confusing.  We should specifically 
say I think that *if* the implementation uses the 2.0 200-response 
pattern, then... something (I'd have to refresh myself on the 2.0 base to 
be more precise).  IIRC in that case the response has no 
guaranteed-retrievable URI for the resource.  I'm confident there's enough 
wiggle room in the spec stack to Allow this to work, less so that there's 
any strong guarantee w/o new words.

> We also use the template concept in Actions, in the "HTTP request 
> with RDF body" interaction pattern [3].
> 
> In both these cases - both with template dialogs and Actions - it's 
> possible that implementations might want to specify whether the 
> template should be POSTed with the subject URIs intact, or whether 
> it should be copied to a blank node (as it's a new resource that 
> will be created, at a factory-assigned URI).

The whole point of the template pattern is to keep the representations 
opaque.  Maybe we need to say that, describe all actors' responsibilities 
*in that case*, and then stop; explicitly say that once you break that 
opacity, it's up to you to figure out all the corner cases that will 
arise.

> With Actions, if we go down the route of defining a ContentAsRDF 
> class, then this would be possible as the provider could set the 
> value of the (proposed) oslc:resource either to be a link to a URI 
> to be dereferenced (if the template is to be submitted with-URI) or 
> as a blank node (if it is to be submitted as a blank node). 

Could, yes.  Need to now (in order to make existing scenarios work), I 
don't think so.  I have not seen anyone pleading for the input-link form. 
If we see a way to extend things later to support that *should it become 
needed*, then I don't see any need to specify it now.  If we don't see 
such a way, we probably have a larger problem.

Devil's Advocate: I'm not sure I see the need for ContentAsRDF yet (or 
maybe I forgot it; if so, sorry).  Assuming opaque representations 
(again), all the client needs to do is GET it from the template dialog's 
result, stash "what's needed" (content + Content-Type header, at least), 
and feed that in to a creation factory *specified by the template dialog's 
provider* later. 




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/962d7c3e/attachment-0003.html>