John, All, Apologies, I won't be able to make the call today, I've been in other meetings all day and will still be in them for the call. I've chatted with Martin who will be able to represent my views for the purposes of the discussion,
Stephen Rowles From: John Arwe <[email protected]> To: [email protected], Date: 22/08/2013 13:48 Subject: Re: [Oslc-Automation] Temporary deployment solutions - tear-down plans - locating the plans in automated script construction Sent by: "Oslc-Automation" <[email protected]> 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 _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
