[Oslc-Automation] Core Actions updates

[Martin P Pain]

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 service provider." - 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:  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 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140129/ca719e5f/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/20140129/ca719e5f/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/20140129/ca719e5f/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/20140129/ca719e5f/attachment.gif>