> Is POST in HTTP 2.0 really going to be incompatible? I assume this > property is multi-valued, if my provider can handle 1.1 or 2.0.
My interpretation is that it could be multi-valued - we ought to add this to the interpretation in the appendix. Good thought. > I guess one could say there are many types of resources, not just > CM, that have 'state' and there could be a case for oslc:state + > oslc:targetState (noticed I picked the core namespace). See other emails: http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000641.html http://open-services.net/pipermail/oslc-automation_open-services.net/2014-January/000644.html 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 13:31:27: > From: Steve K Speicher <[email protected]> > To: [email protected], > Cc: [email protected] > Date: 30/01/2014 13:31 > Subject: Re: [Oslc-Automation] Some comments on Actions spec (most > from CM perspective) > Sent by: "Oslc-Automation" <[email protected]> > > A few items below... > > Thanks, > Steve Speicher > IBM Rational Software > OSLC - Lifecycle integration inspired by the web -> http://open-services.net > > Martin P Pain <[email protected]> wrote on 01/30/2014 05:57:17 AM: > > > From: Martin P Pain <[email protected]> > > To: Steve K Speicher/Raleigh/IBM@IBMUS > > Cc: [email protected], "Oslc-Automation" <oslc-automation- > > [email protected]>, [email protected] > > Date: 01/30/2014 05:57 AM > > Subject: Re: [Oslc-Automation] Some comments on Actions spec (most from CM > > perspective) > > > > What you call the "domain specific types" were an attempt to find things > > from the domain-driven requirements that might be useful across domains or > > in the general case. However, as the oslc_cm:targetState property has to be > > OSLC CM-specific (as it implicitly refers to the oslc_cm:state property) I > > guess there's no use in including the oslc:StateTransitionAction type in > > core, if we have it at all. > > > > As for the usefulness of having that type at all, the intention was having a > > single place to look to determine the type of actions - the rdf:type values. > > But if you've got another way of identifying them (the oslc_cm:targetState > > property) then I guess that's enough. > > > > I guess one could say there are many types of resources, not just > CM, that have 'state' and there could be a case for oslc:state + > oslc:targetState (noticed I picked the core namespace). Though part > of me says "it is just a namespace" and if defined properly, people > could just reuse from CM. I haven't heard enough people asking for > this from various domains but in practice I have seen many tools > support something like this. > > > A couple of points on your examples: > > 1. The resource shape interaction pattern [4] says the name of thepredicate > > pointing to the resource shape is oslc:requestBodyParameters (although in > > recent discussion I've suggested using http:body, as it is being used to > > construct the body). > Right, I just copied an old CM example and didn't change it. > > > 2. The profile you mentioned invokes the "Standard restrictions on > http:Request > > resources for simple specification profiles" from appendix A [5], which > > includes "the providers MUST... provide at least one binding that... > > specifies "1.1" as the value of the http:httpVersion property." (This is to > > allow us to specify HTTP 2 [6] in the future, in a way that lets older, pre- > > HTTP 2 consumers know that HTTP 1.1 is not supported). Your example is > > missing this property. > > Is POST in HTTP 2.0 really going to be incompatible? I assume this > property is multi-valued, if my provider can handle 1.1 or 2.0. > > > 3. oslc:request is now called oslc:binding. > > I just used the examples from Appendix B as a guideline, that is > where I picked up oslc:request [1]. > > [1] - http://open-services.net/wiki/core/Exposing-arbitrary-actions- > on-RDF-resources/#Appendix-B.3A-Examples > > > > > > Other than those minor points, that example looks exactly what > I've got in mind. > > > > > > [4] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF- > > resources/#pattern-resource-shape > > [5] http://open-services.net/wiki/core/Exposing-arbitrary-actions-on-RDF- > > resources/#Standard-restrictions-on-http.3ARequest-resources-for-simple- > > specification-profiles > > [6] http://tools.ietf.org/html/draft-ietf-httpbis-http2-00 > > > > 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] 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
