[Oslc-Automation] Proposal to address Ian's Core comment 7.5 ParameterInstance and content-type
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 , , and  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. 
has it fully correct) this seems to come down to putting the other
sections on a more equal footing.
Proposal to address:
In  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  parameter instance
In  appendix A
...no changes (?) The "simple profiles" restriction on "no headers"
(which includes Content-Type) is not used by , 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  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...
More information about the Oslc-Automation