[Oslc-Automation] OSLC Actions: Dialog for later execution interaction pattern - moved to Automation

[John Arwe]

> > 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140114/9a8eaefb/attachment-0003.html>