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

[Martin P Pain]

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

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 guess, as it currently stands, it would be up to the implementation to 
either replace the URI in the representation POSTed to the factory, or to 
create the new AutoRequest at the same URI (although this might cause 
problems if submitted more than once).

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).
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). We could reuse this with template 
dialogs if the resource that is linked to from the returned oslc:results 
data is a ContentAsRDF resource. Otherwise, the template will always have 
a URI, as it is always retrieved by a dereference.
(To be honest, in the Actions case, we could still achieve this without 
the ContentAsRDF resource, as http:body can be a link or a blank node, but 
this way we can get the same behaviour in both cases with a single 
definition - by defining this behaviour on the ContentAsRDF class.)

(This would also allow the template dialog to return a ContentAsText or 
ContentAsBase64 [4], which may or may not be useful in the "Delegated UI 
dialog for later execution" Action interaction pattern [5], where we 
haven't specifically specified that we're POSTing to a creation factory - 
or if the provider wants to encode the RDF as text to avoid asserting a 
triple which is not true until the action is executed.)

Does anyone think it might be useful to always have a 'content' resource 
(ContentAsRDF/ContentAsText/ContentAsBase64) around a template? Or would 
it be unnecessary noise?

Martin




[1] 
http://open-services.net/wiki/automation/OSLC-Automation-Specification-Version-2.1/#Resource-Template-Creation-Dialog
[2] 
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Creation_Factories
[3] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-rdf-body
[4] http://www.w3.org/TR/Content-in-RDF/
[5] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-dialog-delayed-execution

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140106/6c1a7bc6/attachment-0003.html>