[Oslc-Automation] Core Actions updates
John Arwe
johnarwe at us.ibm.com
Thu Jan 30 13:27:38 EST 2014
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 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/20140130/1ec89710/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/20140130/1ec89710/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/20140130/1ec89710/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/20140130/1ec89710/attachment.gif>
More information about the Oslc-Automation
mailing list