> 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
