[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