Part II: Typos & clarifications 1. Section "Terminology" - "provider": I'm happy with "is authority of" rather than "creates".
2. Section "Domain-specific consumers": 2.1 Do actions get "consumed"? The problem with the word "executed" is that there are two parts to the execution. The consumer/client sends an HTTP request (or similar) and the provider/server does something as a result. The "execution" could either refer to both sides of that, or just to the provider/server side. If you're referring to the word "consumed" in the phrase "Find potentially consumable, currently available ", I can't remember what we meant by "potentially consumable" other than what is described in the steps further down (regarding checking compatibility of interaction patterns). John, can you remember? 2.2 Suggested rephrase. I'd probably add in a "that is" in the brackets: "For each interaction pattern that is supported by the consumer (that is, the interaction patterns supported by the consumer, along with any restrictions, if any, de fined by the profi le(s) they were implemented against):" 2.3 Typo: Correction accepted. . 3. Section "Description" 3.1 Section Name: I can't think of a better name. It contains the bulk of the normative definition of the spec. Perhaps we could just remove this heading and promote each of the sections under it up one level. 3.2 I don't think this is aimed solely at OSLC working groups, but includes anyone who might want to define a public profile (just in case anyone else wants to). I think the normative "MUST" is perhaps incorrect (as it's referring to process, not the resulting spec), but the problem with removing it is that we lose the thought behind it - this spec is also where OSLC members get familiar with these profiles. 3.3 I think we do need to reword this, but I think you missed the intention. The point is that the oslc:action predicate is, according to this specification, THE way to link from a resource to actions that can, at the current time, be used to act on that resource. It is the concept of "at the current time" that lead to the phrase "currently available" in this sentence, not the idea of "currently defined by the spec". I don't know how strongly we want to put that in the spec. Perhaps: "This specification defines the oslc:action predicate as the sole way to link from a resource to actions that can, at the current time, be used to act on that resource. Domain specifications re-using this specification MUST use that predicate (not define their own equivalent), if the semantics of the relationship match. The semantics of the action itself are determined by the rdf:type values of the action, not the predicate that links to it. However, there are other types of relationships between resources and actions, for example ones that cannot be used at the current time, or that act on other resources. Domain specifications re-using this specification MAY define new predicates for such relationships, as OSLC Automation 2.1 does for 'future actions'." But this is quite wordy. Also, the first "MUST" could be "STRONGLY RECOMMENDED" instead. 3.4 I think the reference to "hash URIs" is just to make thoswe less familiar with RDF aware that you don't necesarily need a new HTTP resource/endpoint (as some implementors find that undesirable). (They might not understand what it means, but it gives them something to Google for.) Of these, I'm happy to accept 1, 2.3, and that somethign needs to happen for 3.3. No objection to 2.2, so if you think it;'s clearer I'm happy to accept that one too. I'll raise 2.1 for discussion. 3.1, 3.2 and 3.4 I don't intend to proceed with unless someone pushes them further, in the interests of getting most out of the time spent on this. (I might summarise them at the next meeting to give anyone more of a chance to +1 them). To be continued... 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: [email protected] 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" <[email protected]> wrote on 21/07/2014 09:45:14: > From: Ian Green1/UK/IBM@IBMGB > To: [email protected], > Date: 21/07/2014 09:46 > Subject: Re: [oslc-core] review of actions 2.0 > Sent by: "Oslc-Core" <[email protected]> > > I've uploaded my review comments to http://open-services.net/wiki/ > core/File:review_of_actions2.0_draftspec_img.pdf > > best wishes, > -ian > > [email protected] (Ian Green1/UK/IBM@IBMGB) > IBM Rational > > <[email protected]> wrote on 18/07/2014 19:19:42: > > > From: John Arwe <[email protected]> > > To: [email protected] > > Date: 18/07/2014 19:21 > > Subject: Re: [oslc-core] review of actions 2.0 > > Sent by: <[email protected]> > > > > 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 <[email protected]> > > To: [email protected] > > Date: 07/17/2014 08:50 AM > > Subject: [oslc-core] review of actions 2.0 > > Sent by: <[email protected]> > > > > > > > > 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 > > > > [email protected] (Ian Green1/UK/IBM@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 > [email protected] > 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
