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

[Martin P Pain]

On reading the spec again, I realised that the plain HTTP-in-RDF vocab's 
way of having a fixed literal body would be to use a cnt:ContentAsText [1] 
resource. (This also allows to specify the character encoding [presumably 
the one to use to encode it into bytes, not the one used in the RDF 
graph], whereas I expect we would use the http:headers property to set 
that, if it needs specifying.)

If we don't want to invent a new way of doing it (don't want to re-invent 
the wheel), then we would have to make the opposite change, and restrict 
it to resources. Then if someone asked for fixed textal (or base-64) body 
we point them at [1], and consider at that point whether we need to define 
an interaction pattern for it.
(Although I wouldn't be surprised if people - if they needed fixed textual 
bodies - just put a string literal as the value of the http:body 
property).

On the other hand, perhaps using ParameterInstance for fixed textual 
bodies is indeed better in the context of OSLC. I'm not sure.

Martin

[1] http://www.w3.org/TR/Content-in-RDF/#ContentAsTextClass


"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
11/09/2014 17:31:07:

> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-automation at open-services.net
> Date: 11/09/2014 17:31
> Subject: [Oslc-Automation] Proposal to address Ian's Core comment 7.
> 5 ParameterInstance and content-type
> Sent by: "Oslc-Automation" <oslc-automation-bounces at open-services.net>
> 
> 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 
problem. 
>    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 
> 
> 
> [1] http://open-services.net/wiki/core/Exposing-arbitrary-actions-
> on-RDF-resources/#pattern-body-repn 
> [2] http://open-services.net/wiki/core/Exposing-arbitrary-actions-
> on-RDF-resources/#Resource_ParameterInstance 
> [3] http://open-services.net/wiki/core/Exposing-arbitrary-actions-
> on-RDF-resources/#constructing-http-requests 
> [4] http://open-services.net/wiki/core/Exposing-arbitrary-actions-
> on-RDF-resources/#Resource.3A-Request 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Cloud and Smarter Infrastructure OSLC Lead 
> _______________________________________________
> 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/20140915/517aa750/attachment.html>