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
