Martin, seems like a plan (heh) we can discuss on today's call at least. Hopefully both you and Stephen can make it.
> * ... perhaps ":teardown") on the Plan ... value ...open for future extensions or provider-specific information (such as a parameterised plan). Perhaps ..., e.g. #required (i.e. highly desired) and #optional. Certainly seems reasonable at first blush that Automation could make that predicate's object a resource with it's own properties, and seed it with those you propose which I interpret basically as usage hints. Let the "spirited naming discussions" commence [ducks, as he always does for those] on the predicate. > * The predicate on the Result ... have to define exactly what, possibly one of: ... > (c) An automation plan (with no [required] parameters) - this is extensible to other executable things, like Actions, although that wouldn't be interoperable/backwards-compatible. To make use of a Plan, you also need a collection capable of fielding create requests for that Plan. So this seems incomplete as written. Using the same resource "trick" that I mused about on Plan would allow that, even if the "shape" in this context is different. That's allowed. One way to solve the compatibility issue (which, to be precise, is an *implementation* issue not a spec issue, if the spec's Range is Any per Core's guidance) would be to make it multi-valued, and make the semantic that each of the possibly multiple values is functionally equivalent; a client should choose at most one, presumably the one that it understands best, if >1 are offered. If Automation provides one way to use that as a current basis for wide interop *and* allows others for future extension, implementation-specific extension, and/or implementation compatibility, that seems like a pretty good situation. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
