[Oslc-Automation] OSLC Actions: Dialog for later execution interaction pattern - moved to Automation
Martin P Pain
martinpain at uk.ibm.com
Tue Jan 14 06:10:47 EST 2014
> But in the pure-resource shape case, there is nowhere existing I can
> think of where a client could infer the acceptable content types.
I think we have two or three options:
(1) force use of http:headers to specify it (although specifying multiple
alternatvies isn't covered by the HTTP-in-RDF spec)
(2) say, as I think you were getting at in the previous email, that the
consumers should use the media type that the bindings themselves were
encoded in.
(3) force consumers to do a request to check Accept-Post
Having said that, one option is just to say that we're not supporting the
resource shape scenario in this version. It came from the CM proposal,
with the comment "it puts considerable implementation burden on clients."
We should ask CM if they really want resource shapes in this version.
> I think something's "template-ness" is a question of how it's used,
> not what it is.
What does the HTTP response as part of the following request/response
mean?
GET /abc123
HTTP/1.0 200 OK
Content-type: text/turtle
@prefix oslc_auto <http://open-services.net/ns/auto# >.
<>
a oslc_auto:AutomationRequest;
dcterms:title "Request";
oslc_auto:state oslc_auto:new;
oslc_auto:executesAutomationPlan </plan>;
.
The Auto spec says that oslc_auto:AutomationRequest means that this is "A
resource representing the intention to execute an Automation Plan."
However, if this was served only to be used as a template, then receiving
this resource representation does not imply such an intention exists. It
is merely there to beused once such an intention does exist.
(Perhaps demonstrating it more clearly, if we did have two states "not
ready for execution" and "ready for execution", to decouple creation from
execution, then this template would have the "ready for executon" state -
as that is the state we'd want the new one created in - but this resource
would never actually get executed as it is only intended to beused as a
template. [NB The template would still be needed even if we decoupled
creation from execution, as the consumer needs/wants to be in control of
when it gets created, not just when it gets executed])
What I'm looking for, I think, is terminology to talk about this
situation. And also whether it needs representing in the RDF.
> I read it more widely; in my tiny mind, the Automation Request IP is
> just a special case of CF IP
The AR IP is the driver for the static-template-based IP (as opposed to
the dialog-generated template), so if we merged the CF and AR IPs, we
would need to define the static template predicate on that (but also allow
for it to be used without such a static template predicate, for the
template dialog's immediate execution binding - in other words, it might
still be seen as two IPs). But at least that might simplify the HTTP
request down to two cases: nil body and resource shape.
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
"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on
13/01/2014 19:13:18:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 13/01/2014 19:13
> Subject: Re: [Oslc-Automation] OSLC Actions: Dialog for later
> execution interaction pattern - moved to Automation
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> > Am I right in inferring that you suggest that the "with resource
> > shape" pattern bindings should provide default body contents? i.e. a
>
> No; I got tangled up myself between them. No objection if they can
> (or do), but I have no guarantees that it's always possible.
> I *do* think however that if a client sees a single :binding with
> both a "fixed" body (e.g. :contentAsRdf) and a resource shape, that
> the client is allowed to infer by the draft rules that the provider
> *has* done exactly that, and the consumer May decide to use it.
>
> But in the pure-resource shape case, there is nowhere existing I can
> think of where a client could infer the acceptable content types.
> We could align with Core for the minimum base, we just need to "be
> careful" how we do that given that Core 2 requires RDF/XML and Core
> 3 likely requires Turtle (perhaps JSON-LD) as the minimum. It would
> be a feechur if we didn't need to rewrite Actions when/if Core
> changed, aside from updating the normative reference.
> > My current thinking is that I want to change "with RDF body" to be
> > "with template" (or "providing template"), and define the concept of
> > a "template" more fully (possibly in Automation, but in the Actions
> > spec might make more sense now). That can then contain the
> > information about how to serialize.
>
> I think something's "template-ness" is a question of how it's used,
> not what it is. If you subscribe to the idea that creation
> factories should be able to accept something as input that allows a
> client to influence (in large part, determine) what the CF
> constructs - regardless of the type of the output - then one might
> conclude you feel the same way (even if only by implication). The
> CF doesn't care (generally speaking) whether its input "is" an
> existing resource or not, or where the client obtained that input.
> I can feed identical inputs to the same CF twice in succession and
> get different results, I can feed the same input to two different
> (but similar) CF implementations and get similar-but-different
> results (1 CF looks at 3 of the input properties, another at 4), and so
on.
>
> I don't see any way to cover cases where the client "calculates" the
> input other than having the CF advertise its media type support. We
> Might deem the draft Accept-Post header from LDP good-enough, but
> (fair disclosure) that tells a client which media types are accepted
> on POST, not that the semantic will be create (the CF's context ...
> how the client finds the CF ... might be deemed sufficient to close that
gap).
> > In my mind the Creation Factory IP is only really useful as a
> > "secondary binding"/"immediate execution binding [in the context of
> > a template dialog]". Although I suppose it's possible that it too
> > points to a resource shape, which perhaps makes it equally as useful
> > as the resource shape IP, which means it could be in Actions.
>
> I read it more widely; in my tiny mind, the Automation Request IP is
> just a special case of CF IP, since (all the Actions terms aside) AR
> builds on Core CFs. I'm not sure that Actions needs to define an IP
> for "vanilla" CFs (the "superclass" IP), since no scenarios today
> need it *at that level of abstraction* ... CM and AR both
> incorporate it already. If someone "in the future" wanted a
> vanilla-CF IP they could still define it without disturbing CM or AR
> ... the spec factoring might no longer be minimal, but that's purely
> a spec issue.
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Tivoli OSLC Lead - Show me the Scenario
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
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/d7620039/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/d7620039/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/d7620039/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/d7620039/attachment.gif>
More information about the Oslc-Automation
mailing list