[Oslc-Automation] Bi-direction Actions/Auto spec dependencies, & action metadata at resource type (shape) level
Martin P Pain
martinpain at uk.ibm.com
Mon Sep 15 07:02:41 EDT 2014
Looking at the current wording of the text that allows this (use of
futureAction predicate on resource shape) in core actions:
http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF-resources/#Future-actions
I realise that there's something missing. In Automation 2.1 we explicitly
define the oslc_auto:executes link from the executable action ('action
available for execution at the current time') to the future action, in
order to unambiguously determine which concrete action relates to which
future action resource. Core does not mention this.
Which may mean either:
(1) Core does not provide a way to unambiguously determine which concrete
action to use for a given future action
or
(2) Core is importing part of the Automation spec (not just the
vocabulary) - which may be a bi-directional dependency.
Although perhaps the argument that it is not a 'required' part of the
specification, so does not introduce a dependency for the implementations
unless they choose to include it, may still apply.
Can anyone suggest whether it's worth addressing this, or leaving it as it
is? I wouldn't want to duplicate the definition of how to use
oslc_auto:executes. It's possible the existing link from the "future
actions" section in core to the "future actions" section in Auto 2.1 is
enough - as if anyone wanted to work out exactly how it works could follow
that link. So I expect we will leave this as-is, but just wanted to raise
it as Ian had brought up the bi-directional references between the two
specs in his feedback.
Martin
From: Martin P Pain/UK/IBM at IBMGB
To: John Arwe <johnarwe at us.ibm.com>
Cc: oslc-automation at open-services.net
Date: 31/07/2014 10:11
Subject: Re: [Oslc-Automation] action metadata at resource type
(shape) level
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
I've just looked back at this e-mail, which I don't believe I replied to
at the time.
Anamitra has said he will be joining the WG, so I'll leave most discussion
until then - when it's easier to ask questions about and clarify his
scenario.
In the mean time, just for the record, my general position on points 3 and
6 is that - given the Automation 2.1 spec leaves the meaning of bindings
on future actions being "undefined", and the executable Actions that
relate to them are executed based solely on the bindings on them (as any
other Action) - I would suggest that future actions on Resource Shapes
work exactly the same way. Unless Anamitra's scenario requires more
knowledge at design time about how to execute the actions.
I believe the specs as currently drafted explicitly state that position ("
This specification does not require... what the relationship is between
any bindings present on a future action and those present when it becomes
currently available for execution. ") but allow for future meaning to be
defined if &when required (which we may add shortly if Anamitra's scenario
really requires it).
Martin Pain
Software Developer - Green Hat
Rational Test Virtualization Server, Rational Test Control Panel
OASIS Open Services for Lifecycle Collaboration - Automation technical
committee 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
16/07/2014 16:58:43:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 16/07/2014 17:00
> Subject: Re: [Oslc-Automation] action metadata at resource type (shape)
level
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> >> Also I would like to hear any comments on the choice of predicates
> >> that we have for replacing spi:instanceActions. I am not sure if
> >> oslc-automation:futureActions is the right one for this - but will
> >> like to hear back from the group. I would rather not come up with
> >> our own - if there is something already defined for the same purpose.
>
> > With this proposed defintion of oslc_auto;futureAction, I believe it
> > would make sense within that definition to use that predicate on the
> > type or resource shape to point to actions that may be available on
> > resources of that type/shape. (However, this is just my individual
> > opinion - I'd appreciate other working group members weighing in too).
>
> Perfectly reasonable. Suggested it myself privately a few weeks
> back, although given the listserv SNAFU I'm not sure if that was
> before or after Anamitra's email was sent.
> Even if we made no other changes in 2.1 based on his usage, this
> seems reasonable to me to add a scenario for, and legitimize the
> usage in the spec text as another known usage. I.e. as an example,
> no normative changes required. I don't see any value yet in adding
> a new shape-specific predicate for this purpose.
>
> > 3) ... just to allow the mobile
> > app to list all the actions available on a given resource instance
> > and allow the user to select any of them. RDF is capable of
>
> My sense is that this was done for efficiency (send less content to
> the client over the "narrow" connection). If so, it's debatable
> where to place optimizations. Historically, the OSLC domain spec
> approach has been described to me as "what's the simplest possible
> way to support the scenarios in scope" ... simplest, not most
> efficient. "Efficient" will vary based on the variables being
> optimized, and those are a function of "things as they are now" in
> most cases, rather than "laws of physics". I have seen many
> attempts at local optimization (here, in the sense of "what's under
> my control") that turn out not to matter in the larger system. For
> example, if there's a gzip content coding being used on these
> requests, all that "common stuff" compresses well so the "extra" on
> the wire is much less than you'd think.
>
> What this might be getting at is a need to create bindings at run
> time by merging "what's unique to the resource" (in his case, the
> request URI) and "what's the same across many resources" (method,
> version, ...). Something like the Plan/Request model with default
> parameter values on the Plan, in its own way. If that's the case,
> one way to approach it might be:
>
> - There is one Plan per action per shape, linked to support the
> design-time introspection.
> - The HTTP version and method properties are unneeded as parameters,
> since the Automation Request interaction pattern is being used ...
> which, in the end, means that the method WILL be POST and the
> version is left unspecified by Automation (any sane implementation
> today would use 1.1).
> - The Plan has whatever parameters it has, including zero. Any
> parameters either have defaults, or not.... vanilla Automation 2.0.
> - The server implementation always responds with the synchronous
> style from Automation, which perfectly matches a vanilla HTTP request.
>
> The example Anamitra provided appears to have a body on his post
> requests (from the shape), which sounds like a fixed body
> interaction pattern rather than Automation Request; the mapping from
> fixed to AutoReq is pretty trivial though.
>
> Aside from Plan/Request, another place in existing OSLC where
> there's a type/instance dichotomy is in resource shapes. Actions 2.
> 0 defines an interaction pattern that uses a shape to describe the
> request body, but here the spi:instanceAction is being used to
> describe the content (not shape) of an action binding (ow, my head).
> Future actions with >0 bindings is outside the territory we've been
> thinking about up to now too.
>
> Yet another place is the "template" notion in Automation 2.1. It's
> not too much of a stretch, once you understand Automation Request
> templates, to see what Anamitra's got in his shape as a binding
> template. Just like creating an Auto Req from a template involves
> potentially modifying (merging) inputs (the non-scheduled case when
> a human is involved), creating a client-useful binding in Anamitra's
> example involves merging instance and shape (class) data.
> > that allows you to do that - there is no explicit support in there
> > for URI templates (as used in your example).
>
> That line is commented out, so I'm not sure to what degree it's
> relevant. Anamitra?
> I will note that URI templates are basically about name/value
> parameters in this example, which directly maps to Automation
> Parameters conceptually.
>
> >> As you can notice - http:requestURI - which is marked in the spec as
> >> Exactly-One - would be something that we would have no need of at
> >> this "blue-print" stage.
> > 6) Also, if you were to use oslc_auto:futureAction (or follow the
> > same pattern), then your action on the reosurce shape would require a
URI:
>
> Seems like feedback at 2 levels.
>
> 1: Should the spec say 1:1 or 0:1? We did debate that before, and
> (memory vague) it came out 1:1 due to an absence of scenarios
> needing 0:1. I.e. if we were to add a new scenario (now or in the
> future) that required the request URI to be optional, we'd change
> the spec to say 0:1 instead.
>
> 2: (meta) I won't be 'compliant' with Auto-2.1 and/or Actions-2.0 if
> I omit the request URI. As the previous comment shows, the 1:1 is
> more about client expectations within the scope of *current*
> scenarios than compliance (which, as a term of art, is intentionally
> undefined in OSLC). It would be true that a client only coded to
> Actions 2.0's HTTP interaction patterns would be unable to execute
> an httpRequest Action lacking a request URI. If the Plan-based
> alternative outlined above pans out, a client only coded to Actions
> 2.0's AutoReq interaction pattern *would* be able to execute his
> actions, though.
>
> > 5) And finally, a small point: the Actions specification suggests
> > that you identify what the action does by using an rdf:type value In
> > your examples you use oslc:usage. So to follow that suggestion your
>
> +1
>
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Cloud and Smarter Infrastructure OSLC Lead
> _______________________________________________
> 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
_______________________________________________
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/20140915/c763f705/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/20140915/c763f705/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/20140915/c763f705/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/20140915/c763f705/attachment.gif>
More information about the Oslc-Automation
mailing list