wrt the draft I wonder if Availability scenarios would motivate the "raw" creation factory binding. Maybe Juergen/Tim can weigh in. I think they Can use Automation for what they've discussed, but maybe a raw CF would be cleaner for some pieces (e.g. if some of their interactions are just always synch, and we think that is likely true for "all" reasonable implementations).
You have changed (in the odt strawman) Auto Request from an IP to a request body type. But Automation requires a client to understand a larger pattern of requests (and the Automation vocabulary) - the meaning of 200 is *different* for a CM-style POST (action completed successfully) than an Automation-style POST (action completed, look at oslc_auto:verdict for success/failure). I don't think you can avoid making that a separate IP (at least I cannot see how). > (1) having a single URI to identify each interaction pattern > (which means only having a single HTTP request pattern, > identifying the different ways of building content separately) With my client hat on, I don't see what this saves me. I don't think it hurts me either, FWIW. Either factoring should work. I think in terms of implementation effort. Moving from dead-simple (relatively speaking) to maybe-harder-than-I-want-now is: 1: a single naked HTTP request - no request body, no special headers to fuss with, blocking request. 2: #1 plus a fixed request body ... something I never crack open, I just bitwise-copy from the binding. so the delta is I have to fish out the content type header :-( from the binding 3: #2 plus I crack open (parse) the body, but I never modify it, just serialize it (maybe with a different media type than the binding had) ... may drag Accept header-style info, unless we say introspect at run time which is fine. 4: #2 or #3 in a multi-request pattern, like Automation requests where I have to create something, then monitor/poll until it reaches &some-final-state 5: #2 or #4 where I modify the body, or construct it from scratch Having one IP URI that covers several of those cases is functionally no different than saying "look for X and then Y". I have to do that in the end either way. It's like saying "you have rdfs:Resource, why do you need any other types?" Because rdfs:Resource is not always the granularity that a client/app is interested in. It's fine for some purposes, not others. There are a couple of degrees of freedom involved, in branches: - body or not (branch: if body, how to construct it) - single request or not (more generally: which request pattern do I need to understand? single, Automation, ...) With my RESTy-spec hat on, I react in ways like "an OSLC creation factory isn't a HTTP request? really?" Yes, I can get past those, it's another forest/trees problem. I won't be the only one asking though, as you go through multiple reviews - assuming anyone reads them. With my OSLC-spec hat on, I see places in this that would make Core-Actions depend normatively on Automation (a domain spec), and Core has said it wants to keep all dependencies ON core FROM domains, not the reverse, less we end up in Dependency Hell. I'm talking about cases like "Request body type: Resource template" line 476 ... whatever's needed should be in Core. I'm not worried about cases where Core is just listing and pointing at IPs/profiles known to exist elsewhere (it's not a normative dependency), like line 552. > (2) re-using the idea of "templates" from automation for the "with > RDF body" case, to avoid solving the same problems (e.g. > content-type) twice. Conceptually, Automation's templates may be defined with some extra restrictions, but the general idea sure is obviously valid once you adjust the level of abstraction to the context. If the other emails have led "you" to buy the "template is a role a resource can play" language, I'd certainly go there over keeping template as some kind of "thing-ness". How vs what. > (3) Also, it brings the "creation factory" interaction pattern > into Core, but John has now suggested we only define the If defining it in Core makes it easier for Automation to define it's version via layering, that could be cause to do it (I think emails earlier today may have helped to clarify that). Aside from giving it a Interaction Pattern name, I don't think it adds any new requirements. Maybe it should, though. Maybe *if* you want to use a CF as an action binding, *then* it Must advertise resource shape(s) it accepts. We are allowed to add requirements for action bindings beyond those Core-2 defines for service providers. Such an action binding Might still be incomplete/abstract: since it doesn't tell a client what type(s) are created, as written it seems like it could be used either for immediate execution or something else (like Automation requests). Given that those are entirely different interaction patterns, I have a little bit harder time seeing the value *if* it is considered fully specified as-is. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
