[Oslc-Automation] action metadata at resource type (shape) level
Martin P Pain
martinpain at uk.ibm.com
Thu Jul 31 05:10:34 EDT 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140731/1a86fdeb/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/20140731/1a86fdeb/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/20140731/1a86fdeb/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/20140731/1a86fdeb/attachment.gif>
More information about the Oslc-Automation
mailing list