[Oslc-Automation] Proposal: change namespaces, leave specs (was:Bi-direction Actions/Auto spec dependencies, & action metadata at resource type (shape) level)

[Steve K Speicher]

+1 for moving to core namespace, seems less confusing

- Steve

> From: Martin P Pain <martinpain at uk.ibm.com>
> To: oslc-automation at open-services.net
> Cc: Anamitra Bhattacharyya/Bedford/IBM at IBMUS
> Date: 09/16/2014 05:45 AM
> Subject: [Oslc-Automation] Proposal: change namespaces, leave specs 
(was:Bi-
> direction Actions/Auto spec dependencies, & action metadata at resource 
type
> (shape) level)
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> On second thoughts... 
> 
> I propose: we move the ":futureActions" and ":executes" predicates to 
the 
> Core namespace/vocab, but leave the specs otherwise as-is. (Subject to 
this 
> being acceptable to Anamitra - that he still has time to change his 
> implementation). This should involve minimal re-reviews, as the spec 
content
> has hardly changed, and allows a cleaner Actions 3.0 spec at OASIS. 
> 
> (My only hesitation is the fact that a predicate called ":executes" 
sounds 
> like a general purpose one that would suit being in Automation and 
re-used 
> form elsewhere, but as we don't use it for anything else in Automation, 
and 
> there's zero problem in using a Core term from Automation, I'll stick 
with 
> my proposal as worded above.) 
> 
> Martin
> 
> 
> "Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
16/
> 09/2014 10:32:31:
> 
> > From: Martin P Pain/UK/IBM at IBMGB 
> > To: John Arwe <johnarwe at us.ibm.com> 
> > Cc: oslc-automation at open-services.net 
> > Date: 16/09/2014 10:33 
> > Subject: Re: [Oslc-Automation] Bi-direction Actions/Auto spec 
> > dependencies, & action metadata at resource type (shape) level 
> > Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net> 

> > 
> > (1) I've talked to Anamitra to make sure he has the meeting details 
> > and to get him on the mailing list. 
> > He won't need to use Automation to have the need to find the 
> > concrete actions, but I'll let him talk about his scenario. 
> > 
> > (2) The only "problem" I can see is not really a problem, just a 
> > slight strangeness that Actions 3 might end up being the main spec 
> > to define the usage of  2 terms in the Automation namespace (when we
> > have the chance to move it now). I'll see if I can get an opinion 
> > from Core on that. 
> > 
> > Martin 
> > 
> > 
> > 
> > 
> > "Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote 
> > on 15/09/2014 17:38:54:
> > 
> > > From: John Arwe <johnarwe at us.ibm.com> 
> > > To: oslc-automation at open-services.net 
> > > Date: 15/09/2014 17:40 
> > > Subject: Re: [Oslc-Automation] Bi-direction Actions/Auto spec 
> > > dependencies, & action metadata at resource type (shape) level 
> > > Sent by: "Oslc-Automation" 
<oslc-automation-bounces at open-services.net> 
> > > 
> > > I don't object to any of the potential changes discussed here in 
> > > Martin's email. 
> > > 
> > > (1) I do want to be clear on motivating scenarios though. 
> > > 
> > > It's fair to say Anamitra does [would] need it *if his scenario 
> > > requires the ability to select and configure an action "to be 
> > > executed once it [the action]has been instantiated [actually becomes
> > > available]").  All I'm saying is that Anamitra should be the one to 
> > > say if he needs that now, or forsees that need as a likely 
> > > consequence even though he's not going to tackle it now.  Maximo 
> > > does not use Automation today, so it's not completely obvious to me 
> > > that they'd ever have this need. 
> > > (2) I do want to be clear on the resulting schedule.  Remember I'm 
> > > out for 3 weeks, starting later this week. 
> > > Any change carries non-zero risk.  I would say to some degree that 
> > > when Anamitra's feedback on future actions arrived, we (certainly, I
> > > did this) intentionally *avoided* moving future actions down into 
> > > Core, in part to mange the risk of the larger change.  Would, for 
> > > example, moving a function entirely between specs require us to 
> > > restart the review process with Core?  Not obvious to me. 
> > > If we believe that "Actions 3.0" is going to be needed "soon 
> > > enough", we might choose to do move the 'function' in 3.0 not 2.0. 
> > > Core's guidance has been to lock down in-flight specs and move to 
> > > OASIS.  If the spec change doesn't affect implementations (which it 
> > > should not, I believe is the commonly held assumption), what's 
> > > leading us to "jam" it in now versus enter OASIS with a change that 
> > > we'd really like to see on its work queue?  Is it needed now, or is 
> > > doing it now polishing the nose cone? 
> > > 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
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
> 
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140916/914a4063/attachment-0003.html>