[Oslc-Automation] Proposal to address Ian's Core comment 7.5 ParameterInstance and content-type

John Arwe johnarwe at us.ibm.com
Thu Sep 11 12:31:07 EDT 2014

I see from the Aug 28 meeting minutes that I'm delinquent in getting a 
thread going on this.

Ian noted the mismatch between [1], [2], and [3] in their treatment of 
rdf:value's object range, and (when the object is a literal) how a client 
knows the media type.
Since our intent has always been explicitly to allow any object (i.e. [2] 
has it fully correct) this seems to come down to putting the other 
sections on a more equal footing.

Proposal to address:

In [1] fixed body interaction pattern
1.1: hit text on MUST rdf:value - allow literal
1.2: hit diagram - allow literal
1.3: execution parag 1  - allow literal
1.4: recognition rule - ADD: if the rdf:value object is a literal, binding 
MUST have http:headers entry asserting Content-Type.

In [2] parameter instance
...no changes

In [3] appendix A 
...no changes (?)  The "simple profiles" restriction on "no headers" 
(which includes Content-Type) is not used by [1], so it presents no 
   Ian and Steve however might want to think about Ian's comment "where 
does the client get the Content-Type value from?" in the context of CM 
3.0's re-use of the "Resource Shape" IP. 
   The current text allows interop, but "compliance" does not guarantee 
interop (here, or in general IMO, hence it doesn't bother me here).

... possibly add hyperlink from "simple profiles" requesturi restriction 
to the earlier resource shape, which has the existing text that talks 
about this spec's deviation from "HTTP resources in RDF"

In [4] http:Request resource
4.1: ADD 0:* http:headers - strictly speaking this is optional, just to 
help readers stitch together the pieces


Best Regards, John

Voice US 845-435-9470  BluePages
Cloud and Smarter Infrastructure OSLC Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140911/80b2faf7/attachment.html>

More information about the Oslc-Automation mailing list