> But in the pure-resource shape case, there is nowhere existing I can > think of where a client could infer the acceptable content types.
I think we have two or three options: (1) force use of http:headers to specify it (although specifying multiple alternatvies isn't covered by the HTTP-in-RDF spec) (2) say, as I think you were getting at in the previous email, that the consumers should use the media type that the bindings themselves were encoded in. (3) force consumers to do a request to check Accept-Post Having said that, one option is just to say that we're not supporting the resource shape scenario in this version. It came from the CM proposal, with the comment "it puts considerable implementation burden on clients." We should ask CM if they really want resource shapes in this version. > I think something's "template-ness" is a question of how it's used, > not what it is. What does the HTTP response as part of the following request/response mean? GET /abc123 HTTP/1.0 200 OK Content-type: text/turtle @prefix oslc_auto <http://open-services.net/ns/auto# >. <> a oslc_auto:AutomationRequest; dcterms:title "Request"; oslc_auto:state oslc_auto:new; oslc_auto:executesAutomationPlan </plan>; . The Auto spec says that oslc_auto:AutomationRequest means that this is "A resource representing the intention to execute an Automation Plan." However, if this was served only to be used as a template, then receiving this resource representation does not imply such an intention exists. It is merely there to beused once such an intention does exist. (Perhaps demonstrating it more clearly, if we did have two states "not ready for execution" and "ready for execution", to decouple creation from execution, then this template would have the "ready for executon" state - as that is the state we'd want the new one created in - but this resource would never actually get executed as it is only intended to beused as a template. [NB The template would still be needed even if we decoupled creation from execution, as the consumer needs/wants to be in control of when it gets created, not just when it gets executed]) What I'm looking for, I think, is terminology to talk about this situation. And also whether it needs representing in the RDF. > I read it more widely; in my tiny mind, the Automation Request IP is > just a special case of CF IP The AR IP is the driver for the static-template-based IP (as opposed to the dialog-generated template), so if we merged the CF and AR IPs, we would need to define the static template predicate on that (but also allow for it to be used without such a static template predicate, for the template dialog's immediate execution binding - in other words, it might still be seen as two IPs). But at least that might simplify the HTTP request down to two cases: nil body and resource shape. Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint chair E-mail: [email protected] Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU "Oslc-Automation" <[email protected]> wrote on 13/01/2014 19:13:18: > From: John Arwe <[email protected]> > To: [email protected], > Date: 13/01/2014 19:13 > Subject: Re: [Oslc-Automation] OSLC Actions: Dialog for later > execution interaction pattern - moved to Automation > Sent by: "Oslc-Automation" <[email protected]> > > > Am I right in inferring that you suggest that the "with resource > > shape" pattern bindings should provide default body contents? i.e. a > > No; I got tangled up myself between them. No objection if they can > (or do), but I have no guarantees that it's always possible. > I *do* think however that if a client sees a single :binding with > both a "fixed" body (e.g. :contentAsRdf) and a resource shape, that > the client is allowed to infer by the draft rules that the provider > *has* done exactly that, and the consumer May decide to use it. > > But in the pure-resource shape case, there is nowhere existing I can > think of where a client could infer the acceptable content types. > We could align with Core for the minimum base, we just need to "be > careful" how we do that given that Core 2 requires RDF/XML and Core > 3 likely requires Turtle (perhaps JSON-LD) as the minimum. It would > be a feechur if we didn't need to rewrite Actions when/if Core > changed, aside from updating the normative reference. > > My current thinking is that I want to change "with RDF body" to be > > "with template" (or "providing template"), and define the concept of > > a "template" more fully (possibly in Automation, but in the Actions > > spec might make more sense now). That can then contain the > > information about how to serialize. > > I think something's "template-ness" is a question of how it's used, > not what it is. If you subscribe to the idea that creation > factories should be able to accept something as input that allows a > client to influence (in large part, determine) what the CF > constructs - regardless of the type of the output - then one might > conclude you feel the same way (even if only by implication). The > CF doesn't care (generally speaking) whether its input "is" an > existing resource or not, or where the client obtained that input. > I can feed identical inputs to the same CF twice in succession and > get different results, I can feed the same input to two different > (but similar) CF implementations and get similar-but-different > results (1 CF looks at 3 of the input properties, another at 4), and so on. > > I don't see any way to cover cases where the client "calculates" the > input other than having the CF advertise its media type support. We > Might deem the draft Accept-Post header from LDP good-enough, but > (fair disclosure) that tells a client which media types are accepted > on POST, not that the semantic will be create (the CF's context ... > how the client finds the CF ... might be deemed sufficient to close that gap). > > In my mind the Creation Factory IP is only really useful as a > > "secondary binding"/"immediate execution binding [in the context of > > a template dialog]". Although I suppose it's possible that it too > > points to a resource shape, which perhaps makes it equally as useful > > as the resource shape IP, which means it could be in Actions. > > I read it more widely; in my tiny mind, the Automation Request IP is > just a special case of CF IP, since (all the Actions terms aside) AR > builds on Core CFs. I'm not sure that Actions needs to define an IP > for "vanilla" CFs (the "superclass" IP), since no scenarios today > need it *at that level of abstraction* ... CM and AR both > incorporate it already. If someone "in the future" wanted a > vanilla-CF IP they could still define it without disturbing CM or AR > ... the spec factoring might no longer be minimal, but that's purely > a spec issue. > Best Regards, John > > Voice US 845-435-9470 BluePages > Tivoli OSLC Lead - Show me the Scenario > _______________________________________________ > 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
