[Oslc-Automation] Core Actions updates
Martin P Pain
martinpain at uk.ibm.com
Fri Jan 31 08:00:01 EST 2014
> 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: 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
30/01/2014 18:27:38:
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net,
> Date: 30/01/2014 18:27
> Subject: Re: [Oslc-Automation] Core Actions updates
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
>
> 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 <martinpain at uk.ibm.com>
> To: John Arwe/Poughkeepsie/IBM at IBMUS,
> Cc: oslc-automation at open-services.net, "Oslc-Automation"
> <oslc-automation-bounces at open-services.net>
> 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: martinpain at uk.ibm.com
> 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" <oslc-automation-bounces at open-services.net> wrote
> on 28/01/2014 15:29:12:
>
> > From: John Arwe <johnarwe at us.ibm.com>
> > To: oslc-automation at open-services.net,
> > Date: 28/01/2014 15:29
> > Subject: [Oslc-Automation] Core Actions updates
> > Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> >
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140131/26d5220c/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/20140131/26d5220c/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/20140131/26d5220c/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/20140131/26d5220c/attachment.gif>
More information about the Oslc-Automation
mailing list