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" <[email protected]> wrote on 15/09/2014 15:24:22: > From: Martin P Pain/UK/IBM@IBMGB > To: John Arwe <[email protected]> > Cc: [email protected] > 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" <[email protected]> > > 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 > _______________________________________________ > 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
