[Oslc-Automation] HTTP req impl pattern: template indirection

Martin P Pain martinpain at uk.ibm.com
Tue Jan 14 05:23:45 EST 2014


Here is an example that attempts to demonstrate the need for indirection 
in the "body as RDF"/"template" Actions interaction pattern:

<context>
        #...
        oslc:action [
                a oslc:Action;
                dcterms:title "Do something";
 
                # Binding 1: W3C-defined ContentAsText
                oslc:binding [
                        a http:Request;
                        http:body [
                                a content:ContentAsText;
                                content:chars "do(:something)";
                        ];
                        #...
                ];
 
                # Binding 2: template with indirection
                oslc:binding [
                        a http:Request;
                        http:body [
                                a oslc:ContentAsRdf;
                                oslc:resource <template>;
                        ];
                        #...
                ];
 
                # Binding 3: template without indirection (currently 
invalid)
                oslc:binding [
                        a http:Request;
                        http:body <template>;
                        #...
                ];
        ];
.

---
# A GET on the <template> URI returns:
<template>
        a ?:Command;
        ?:command ?:do;
        ?:arg "something";
.
# Using the style of binding 3, would the consumers have to know all the 
rdf:type values that were valid templates? Or all the ones that had 
specific meanings?
---
# e.g. if <template> returned the following, what would that mean? To 
extract and use the characters (based on the rdf:type, which implies that 
RDF templates also need to be matched by their rdf:type values [making the 
previous template invalid as the consumer doesn't recognise the rdf:type 
value]), or to use it as a template (inferred simply by it being a 
reference rather than a local inline resource):
# Alternative scenario: A GET on the <template> URI returning:
<template>
        a content:ContentAsText;
        content:chars "do(:something)";
.



(And no, indirection does not solve the inference issue)



Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
Open Services for Lifecycle Collaboration - Automation WG joint chair

E-mail: martinpain at uk.ibm.com
Find me on:  and within IBM on:  




IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU



From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     Martin P Pain/UK/IBM at IBMGB, 
Date:   13/01/2014 22:28
Subject:        Re: Templates: Submitting as blank nodes?


I'm starting to wonder if part of the indirection problem is not having an 
example to look at.
Searching the Core-Actions spec, I see words but no examples.  Ditto Auto 
2.1.  Do you have one, maybe that you worked on the side, to help us 
crystallize what's in your head/words?
I think you know from past discussions that I tended to put together 
before/after or thisway/thatway examples, even if I didn't always rub 
people's collective nose in them.
While I'm here: one of your worries was inferencing based on http:body and 
the related RDFS.  I'm suspecting that one use of your "extra" level of 
indirection is to interrupt/prevent that, but (perhaps the example absence 
again) I'm not sure how.  E.g. if I look at [1], you still have an 
http:body, with :ContentAsRDF ... that would still be subject to the 
"rdf:type = http:ContentAsBase64" inference, would it not?

[1] 
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#pattern-rdf-body

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario





From:   Martin P Pain/UK/IBM at IBMGB
To:     oslc-automation at open-services.net, 
Cc:     John Arwe/Poughkeepsie/IBM at IBMUS, Umberto Caselli/Italy/IBM at IBMIT
Date:   01/06/2014 11:24 AM
Subject:        Templates: Submitting as blank nodes?


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/20140114/9e5a3740/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140114/9e5a3740/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140114/9e5a3740/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140114/9e5a3740/attachment.gif>


More information about the Oslc-Automation mailing list