> I re-worded your #2 slightly. Hopefully without loss of intent.
I think it now breaks the contract of http:Request/http:requestURI though. As in appendix A we say "use the request URI specified by http:requestURI ", which to me means "use the request URI that is the object of the http:requestURI property". Which is different from "obtain the creation factory’s URI from the oslc:creation property". (I believe I wrote the original when I was thinking that a Creation Factory's creation URI was always the same as the resource's URI, but that's not true as all Creation Factories to date are "local resources" in an oslc:Service.) I think we have three options: 1. Drop the idea of pointing to a creation factory all together. 2. Say that we RECOMMEND that providers return an oslc:CreationFactory representation in responses to the URI that is the target of http:requestURI, where that factory's creation URI is the same as the URI that the representation was retrieved on (that is, the target of http:requestURI). 3. For the Automation Profile, replace the use of http:Request interactino pattern with oslc:CreationFactory (this puts greater distance between Auto and CM, which is not a good thing as this is supposed to be finding common ground, but does increase commonality between the template dialog (which was the reason for adding creation factory as an impl pattern) and general Automation actions). 4. RECOMMEND that providers multi-type the AutoRequest bindings as both http:Request and oslc:CreationFactory (where the oslc:Creation and http:requestURI proeprties should/must(?) point to the same target) (I thought of #2 while writing... so that makes 4 options now) #1 is by far simplest. The motivation for pointing to a creation factory is for similarity with existing use of AutoRequest, which would hopefully make it easier to plug this into existing Automation code infrastructure. Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint 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-Automation" <[email protected]> wrote on 30/01/2014 18:27:38: > From: John Arwe <[email protected]> > To: [email protected], > Date: 30/01/2014 18:27 > Subject: Re: [Oslc-Automation] Core Actions updates > Sent by: "Oslc-Automation" <[email protected]> > > All these changes are live now. They're small enough that the diff > should be useful if needed. > > In addition: > > I re-worded your #2 slightly. Hopefully without loss of intent. > > I found new conflicts between [3] and [4], so I moved most of the > content in [4] up to [3] and added a link from 4 back to 3 then > removed dups. > The new conflicts before this change were > (1) re-use of existing profiles was May in old-[3], Should in old- > [4], and is Should in new-[3]; > (2) talking to Core WG about listing, defining, or adding new > profiles in Core vs domain specs, which was in old-[4] only so moved > to new-[3] now. > > [3] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#Re-use-by-domain-specifications > > [4] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#constructing-http-requests > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > > > > > From: Martin P Pain <[email protected]> > To: John Arwe/Poughkeepsie/IBM@IBMUS, > Cc: [email protected], "Oslc-Automation" > <[email protected]> > Date: 01/29/2014 07:58 AM > Subject: Re: [Oslc-Automation] Core Actions updates > > > > Results of a read-through from the top to the beginning of the > "resources" section (and a scan through the rest). > > 1. As we've defined oslc:ContentFromRepresentation to be used as the > type of targets of http:body, should we change [5] to use http:body for > oslc:ResourceShape resources? That would remove oslc:requestBodyParameters > , which I don't think adds anything over http:body. > > 2. "are RECOMMENDED to set the http:requestURI property of the > action binding’s http:Request resource to link to a standard > creation factory for Automation Requests for the appropriate serviceprovider. > " - I think to get my intention across, this needs to say: > "are RECOMMENDED to set the http:requestURI property of the action binding’s > http:Request resource to link to a standard creation factory for > Automation Requests for the appropriate service provider, where that > creation factory's oslc:creation URI is the URI of the creation > factory itself." > or it could just say "to the creation URI of a standard creation > factory..." however then the consumer can't know. I'm not sure that > matters. The next MUST covers the consequences of it. > > > And in response to your comments: > > > I also see that when we resolved issue 8 [2] during [1] with > > "strongly RECOMMENDED", we were unaware of existing text at [3] > > specifying a MUST for what I think is the same statement. So we > > need to settle on one value. > I think changing the text at [3] to strongly RECOMMENDED would be in > line with the agreement in the meeting. Changing it sounds simplest > to me, rather than discussing it again. > > > In [4], the final bullet of the first list seems completely out of > > place/does not apply to consumers. Do we really have to tell > > producers to use HTTP at this point? > Personally I think it's useful to remind implementors to consider > the status code they use (although we cover that in the next > paragraph anyway). Due to the paragrapoh that follows it, I'd be > happy for us to remove that bullet. > > > In [4], the text beginning as follows seems ripe for deletion based > > on our last meeting's resolution allowing arbitrary media types in > > representations: Note: If OSLC implementors want to specify literal > > HTTP request bodies, e.g. for `text/plain` or binary data... > Agreed > > I haven't made any changes to the Core Actions page as a result of > this, as I have now run out of time to spend on this until Friday > afternoon at the earliest (except the Thursday meeting, where we > will be talking about Availability anyway). John, if you have time > to make those changes then it would be good to egt them in ASAP to > avoid forgetting about this email, but if you don't I can come back > to this Friday or next week. > > [5] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#pattern-resource-shape > [6] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#Additional-provider-constraints > [7] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#constructing-http-requests > > Martin Pain > Software Developer - Green Hat > Rational Test Virtualization Server, Rational Test Control Panel > Open Services for Lifecycle Collaboration - Automation WG joint chair > > E-mail: [email protected] > Find me on: [image removed] and within IBM on: [image removed] > > [image removed] > > > > > > 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" <[email protected]> wrote > on 28/01/2014 15:29:12: > > > From: John Arwe <[email protected]> > > To: [email protected], > > Date: 28/01/2014 15:29 > > Subject: [Oslc-Automation] Core Actions updates > > Sent by: "Oslc-Automation" <[email protected]> > > > > I have updated Core Actions with the content noted at [1]. The > > templates section is just above [3] (templates is now final topic in > > overview) if anyone would care to sanity-check it. > > > > I also see that when we resolved issue 8 [2] during [1] with > > "strongly RECOMMENDED", we were unaware of existing text at [3] > > specifying a MUST for what I think is the same statement. So we > > need to settle on one value. > > > > In [4], the final bullet of the first list seems completely out of > > place/does not apply to consumers. Do we really have to tell > > producers to use HTTP at this point? > > In [4], the text beginning as follows seems ripe for deletion based > > on our last meeting's resolution allowing arbitrary media types in > > representations: Note: If OSLC implementors want to specify literal > > HTTP request bodies, e.g. for `text/plain` or binary data... > > I gave it a top-to-bottom read without finding any glaring holes. > > Seems like we need to scrub the issues page and red text notes to > > see what's really still open. What do we want to do about diagrams? > > [1] http://open-services.net/wiki/automation/AutomationMeetings20140123/ > > [2] http://open-services.net/wiki/core/Actions-2.0-Issues/ > > [3] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > > on-RDF-resources/#Re-use-by-domain-specifications > > [4] http://open-services.net/wiki/core/Exposing-arbitrary-actions- > > on-RDF-resources/#constructing-http-requests > > Best Regards, John > > > > Voice US 845-435-9470 BluePages > > Tivoli OSLC Lead - Show me the Scenario > > _______________________________________________ > > Oslc-Automation mailing list > > [email protected] > > 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 > [email protected] > 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
