> 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, ...
My only concern with this is having two different uses of template - this proposed one, and the whole "template creation dialog" topic in Automation. If we're all buying the "template-ness is a function of usage, not being" narrative, then we should rename what's in automation 2.1 now. "Deferred execution" (vs "immediate execution" for the 2.0 cases) is one idea I've had along those lines. I do think that Action bindings' intended use of any http:body *is* a template usage. > Am I right in inferring that you suggest that the "with resource > shape" pattern bindings should provide default body contents? i.e. a > default "template". I suggest that server implementations will be driven to; at least "kind" ones, in the "be kind to your clients" sense. I did not intend that the spec would require this. Same as the current status quo for resource shapes on creation factories: keep the minimum entry point as small as possible. > Or did I misunderstand you when you said "could just "copy" the > contents of :contentAsRdf"? (I expect you were just saying "only I'm not sure that my ideas then (before I had worked through that whole "extra" level of indirection detour I took) were completely coherent. There were some cases where I was making assumptions that were not true in all cases. We do need some story about how a client knows what content-type(s) it can use when it's sending input along on http requests that allow message bodies. There may be two stories, one for "arms length" cases (client treats body as completely opaque, sourced from a binding) and one for cases where the client constructs the input itself, in whole or part. The latter might be as simple as: use HTTP substrate mechanisms, for example Accept-Post... and if we find those underspecified for our tastes, work on fixing it at the right (http) level instead of band-aiding it in our tiny application-specific layer on top of http. > In my mind the Creation Factory IP is only really useful as a > "secondary binding"/"immediate execution binding [in the context of This might turn on the contextual meaning of CF IP, and how one recognizes it. We know CM's desired result (naked post to Action resource URI, perhaps with a message body) makes it look a lot like a creation request, so I might have been thinking of that as a CF. IIRC however their desired normal response is 200 not 201, which seems to rule out the C in CF. If the CF IP also requires an oslc:CF resource, that's never shown up in CM's desired result. So maybe again my thinking got muddied. When I get confused, I don't go half-in ;-) > Outside of dialogs, there's the question of one or many HTTP request > IPs (Issue 16), I think that's the only big questions still to I think I don't care about that exact question (yesterday's responses). If there are fundamentally say 5 different "variations" a client might need to understand, whether that ends up being 5 IPs or 2 IPs with 2 and 3 variations respectively, don't think I care much. The client still has 5 things to worry about either way. If you prefer: I care about how many pieces of fruit there are, not whether they're apples or oranges or how many of each subset I have. The fact that some are citrus and some not, may or may not turn out to be interesting. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
