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" <[email protected]> wrote on 11/09/2014 17:31:07: > From: John Arwe <[email protected]> > To: [email protected] > 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" <[email protected]> > > 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 > [email protected] > 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
