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

[Martin P Pain]

John, does my response below alter your position/proposal on this point?

If we can have your response to this via email, then I think we can 
proceed on all the items still under discussion at this week's meeting in 
your absence.

Thanks,
Martin


"Oslc-Automation" <oslc-automation-bounces at open-services.net> wrote on 
15/09/2014 15:24:22:

> From: Martin P Pain/UK/IBM at IBMGB
> To: John Arwe <johnarwe at us.ibm.com>
> Cc: oslc-automation at open-services.net
> Date: 15/09/2014 15:24
> Subject: Re: [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>
> 
> 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
> _______________________________________________
> 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/20140918/716140fc/attachment-0003.html>