[Oslc-Automation] [oslc-core] review of actions 2.0 - Part I : General comments/questions
Martin P Pain
martinpain at uk.ibm.com
Thu Jul 31 06:12:52 EDT 2014
Thanks again Ian for your review. Here's my response to the first part -
I'll get on to other parts over time.
Part I : General comments/questions
> 1. I
find it easier to read and review these documents when sections
are
> numbered. Is this possible?
I don't believe any other OSLC specs do that. But that doesn't stop us
doing it. Any other +1s to that?
> 2. Is there any guidance on how an automation provider would offer
automa-
> tion around resources of another provider?
We have no guidance on this, as it wasn't a scenario that we were
considering. (Scenarios: [1]).
However, it should be possible. If you'd like to throw together a scenario
then the WG/TC (any of them) can consider putting together some guidance.
> 3. It seems that having AutomationRequests (and Delegated UI dialog for
> later execution and Automation Creation Factory) de
ned in the Actions
> spec creates a pair of dependencies which gives the impression that the
> two specs are mutally dependent. Is there a reason for this arrangement?
The reason for this arrangement was that we expected these
Automation-based interaction patterns to be generally reusable. (Someone
implementing Actions who didn't previously use Automation might now do so
if they need asynchronous execution... although perhaps we don't point out
the reason why they might do so in the spec.)
The dependencies on each other are in optional sections (i.e. no
unqualified MUSTs pointing to the other spec), so in that sense they're
not mutually dependent (although again we might not have taken any steps
to avoid that impression being given).
Do you think it would be best to address that impression but leave the
bidirectional references between the two specs in, or move the Automation
interaction pattern & profile into the Automation spec, and only have them
linked in section that are explicitly non-normative in Actions? (And make
the other two interaction patterns that currently link to Actions
explicitly non-normative too?)
As you raised the question, I think it is worth doing something to address
this question in the specs as it may well come to others' minds when they
read it too.
4. application/rdf+xml support:
I think we decided on text/turtle as the minimum requirement based on the
state of technology as it is now, rather than when Core 2.0 was written,
and also based on intentions for Core 3.0. However, as this is a 2.0 spec
not a 3.0 spec, perhaps we should make application/rdf+xml the minimum
requirement.
As Actions will normally be used in the context of another OSLC domain,
that other domain (if used at 2.0 version) is likely to require
application/rdf+xml, so I don't see the need to require it here, as not
doing so means we don't put unnecessary burdens on implementations using
it outside of an OSLC 2.0 domain. (But then again by requiring text/turtle
we are indeed putting extra burden on implementors who do want it to use
it with 2.0 domains.) We'll have to discuss this one in the WG.
5. Cherry-picking duplicate body/httpVersion properties in http:Request:
To the extent that this "cherry-picking" is defined, it's defined by a
combination of the HTTP interaction patterns' "recognition rules" [2] [3]
[4] and the section "Recogniszing the interaction patterns used by each
binding" [5] which says "Each action binding can match more than one
interaction pattern, in which case the consumer can choose which one to
use.", meaning that the client identifies which interaction patterns match
the http:Request resource, then chooses which of those interaction
patterns to use, which defines which of the http:body properties to use.
The cherry picking of the http:httpVersion properties is not defined, to
my knowledge (indeed appendix A doesn't acknowledge that there can be
multiple httpVersion properties).
It may well be simpler for each http:Request to only map to a single
constructed request instead of giving options. I'll see what the consensus
is at the WG.
I've added poitns 1, 4 & 5 to the next Automation WG agenda. (If Core
wants to discuss them instead, let me know, but as the spec was developed
by Automation I'll raise them there by default.)
If you Ian (or anyone else) wants to provide input/suggestions on how to
address points 2 or 3, please do so - I believe they need more input (in
terms of a written scenario for 3, and a suggestion of what solution is
required for 3) before we can discuss them at a WG meeting. (Don't read
this as me rejecting those comments - they are valuable feedback, and I'm
thankful - but I'm trying to be practical about what we can have useful
discussion about at the next meeting, or what needs to happen first.)
I'll get on to subsequent parts of your review in time - don't wait for me
to do so before discussing these points on the mailing list.
Thanks again,
Martin
[1] http://open-services.net/wiki/core/Actions-2.0-Scenarios/
[2]
http://open-services.net/wiki/core/Actions-2.0/#Pattern-recognition-rule
[3]
http://open-services.net/wiki/core/Actions-2.0/#Pattern-recognition-rule_1
[4]
http://open-services.net/wiki/core/Actions-2.0/#Pattern-recognition-rule_2
[5] http://open-services.net/wiki/core/Actions-2.0/#recognizing-patterns
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-Core" <oslc-core-bounces at open-services.net> wrote on 21/07/2014
09:45:14:
> From: Ian Green1/UK/IBM at IBMGB
> To: oslc-core at open-services.net,
> Date: 21/07/2014 09:46
> Subject: Re: [oslc-core] review of actions 2.0
> Sent by: "Oslc-Core" <oslc-core-bounces at open-services.net>
>
> I've uploaded my review comments to http://open-services.net/wiki/
> core/File:review_of_actions2.0_draftspec_img.pdf
>
> best wishes,
> -ian
>
> ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> IBM Rational
>
> <oslc-core at lists.oasis-open.org> wrote on 18/07/2014 19:19:42:
>
> > From: John Arwe <johnarwe at us.ibm.com>
> > To: oslc-core at lists.oasis-open.org
> > Date: 18/07/2014 19:21
> > Subject: Re: [oslc-core] review of actions 2.0
> > Sent by: <oslc-core at lists.oasis-open.org>
> >
> > Ian, IIRC Actions is still be worked in open-services.net since it's
> > not finalized.
> > Can you post a copy of the PDF there as well, so the IP policy
> > (open-services WG's entitlement to use it) is crystal clear? oslc-
> > automation is probably best, but oslc-core works too.
> > FYI, we also recently received some feedback from a new implementer
> > in my area, who's using it in a new way. I added a small section on
> > Future Actions earlier this week to address his questions about the
> > relationship between resource shapes and ... well... future actions
> > (a concept already needed + present in Automation, but until this
> > feedback we had zero scenarios to justify its existence in Core).
> > Best Regards, John
> >
> > Voice US 845-435-9470 BluePages
> > Cloud and Smarter Infrastructure OSLC Lead
> >
> >
> >
> >
> > From: Ian Green1 <ian.green at uk.ibm.com>
> > To: oslc-core at lists.oasis-open.org
> > Date: 07/17/2014 08:50 AM
> > Subject: [oslc-core] review of actions 2.0
> > Sent by: <oslc-core at lists.oasis-open.org>
> >
> >
> >
> > Hello
> > I have reviewed Actions 2.0 [1]. Please find attached my review
> > comments. I wanted to upload these to the TC wiki / oslc.net wiki
> > but wasn't sure where it should go.
> >
> >
> >
> > [1] http://open-services.net/wiki/core/Exposing-arbitrary-actions-
> > on-RDF-resources/
> >
> > best wishes,
> > -ian
> >
> > ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> > IBM Rational
> > 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[attachment "review_of_actions_spec.pdf" deleted by John
> > Arwe/Poughkeepsie/IBM]
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 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-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_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/4f490f05/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/4f490f05/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/4f490f05/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/4f490f05/attachment.gif>
More information about the Oslc-Automation
mailing list