> > 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)
I think it is covered. See [1] and look at Accept. It's a syntax only a mother could love, but for programmatic consumption either you do that or you force clients to parse it. Maybe this is something that profiles should specify (a min for interop) as a way to simplify. If we go there, it's the RDF/XML vs Turtle/JSON-LD debate again (do you align with Core 2=RDF/XML, or with where you think Core 3 will land?). > (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. (thinking out loud) That might get hard, if there are cases where the Action/binding representation is requested with Accept: foo (turtle, say) but the binding's target requires a different media type (rdf/xml, say). But we probably have this no matter how the media type we're discussing is communicated to potential clients. > (3) force consumers to do a request to check Accept-Post That will vary based on the request. So you could fix it at whatever level the HTTP method gets specified, but I cannot be the same across methods. A client has to check Accept-Patch for PATCH, Accept-Post for POST, and I don't think there is one for PUT (most people seem to take the position that whatever you can respond to GET with, you should accept on PUT). > 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. We can ask. I thought CM needed it though - when you Resolve a bug, they wanted 2 or 3 triples set. > 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 be used once such an > intention does exist. No doubt we could have long debates about what an AutoReq's mere existence (with state=new) means. To some degree because we got it wrong in 2.0 [flogs self *again* for missing that coupling], but also because it's prose and prose has limits on specificity. I could argue (Devil's Advocate position) that the template case *does* indicate intent, it's just fuzzier than the original spec was written to. The template creator *does* intend to execute the AutoPlan, just not right now and we're not sure how many times. Kind of like a class/instance distinction. DA says: the cited text does not say 'once', does not say 'right now', so my use is within the text. Which is a "long"/concrete-example way of saying that the narrow "GET context" may not be "The Usage Context" of interest. I don't think you know something is being used as a template until you get to the app layer where you see a set of HTTP messages and the pattern they form. Forest/trees, if you like analogies. It's not that either is wrong, is just depends what power your microscope is set on. > (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. This is sounding like violent agreement. You can't know from the representation alone that this resource will never actually be executed. You can only know that by looking at what the app does with it across the app's lifetime. A different app *could* use an identical resource in a different way. Thus I argue it's the usage not the state that determines whether it plays the role we call 'template' or not, and further that the answer might vary over time. > [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]) correct; also how many times. A template might be used 0:* times. We don't really know until it's destroyed, before that we're just guessing with varying levels of education driving the guesses. > What I'm looking for, I think, is terminology to talk about this > situation. And also whether it needs representing in the RDF. Perhaps we say that "template" is a role that a resource (any resource) can play. We have specific scenarios around Automation Requests, but we can see that (at the HTTP level, vs the scenario level) they're not special. We could even argue that the input to "create" requests (regardless of HTTP method used) plays the same role, as does a pre-filled form presented to a user (who can submit it more than once, if s/he Really Likes the contents of that shopping cart ;-) ). The RDF is something of a challenge, for the same reason. If you say something "is" a template (e.g. via its rdf:type), there's a reasonable-sounding argument that (since "being" a template doesn't STOP you from doing anything else with it) you can just compose that in and call it a day. There's also a reasonable-sounding counter: if it's not playing that role now (or always), then you "can't" say it's playing that role. Where I've heard people worry about templates is when the notion of "completeness" comes up. Often templates (as people use term) are assumed to be "incomplete" - they lack one or more properties that a given hunk of code "needs" or requires. That sounds a lot to me like the notion of validity (which does not exist in RDF in the same sense as it does in metamodels like XML). OSLC uses resource shapes for that (and ... since you can have Different Shapes for the Same Type depending on context, OSLC implicitly has a notion of context baked into shapes that's demonstrably separate from the vocabulary definition). So that given hunk of code has requirements that certain properties exist on resources of a given type _in order for those resources to be useful to that hunk of code_. It needs to check for the existence of what it needs, i.e. it needs to validate or validity check those instances. That can be done, but it's not an RDF concept today; there is a nascient effort at W3C (RDF Validation), but so far it's just a past-tense workshop. I guess this leads me to a strawman: since Automation is the one that over-coupled, it's what needs to talk (in the context of 2.1's template content) about how the new-for-2.1 creation factories create automation requests that do not automatically execute. It creates them in a "draft" state, and if the client wants to allow them to execute then the client must take an additional action (set the state to new? to "eligible for execution"?). if the client allows them to sit there as drafts, they can be garbage collected after a short period. Drafts can ALSO be used as templates (input to traditional Auto creation factories), or used in other ways to similar (point to scenarios). > > 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. I'm willing to live with it as-is. It just seemed a touch odd to me. If it comes up in later reviews from others, we can look more deeply at it. For the record: I handled the other two emails' changes today - moved the 200/201/202 boilerplate into appendix A and fiddled with the language to be clearer (I hope) about what HTTP requires vs what we add - removed the "http:headers not used by existing IPs" stmt Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
