> the desire to know in advance (at orchestration-plan design time) that teardown is possible,
This requirement never really registered with me, let alone its primacy. Skimming the temporary deployment scenario pages, I don't see it coming through either. Did I miss something, or is there a "composed plan design time" scenario driving this? It seems reasonable enough, I see the same design vs run time issues certain places in CSI. I've seen design-time scenarios drive subtly different requirements, so is there anything (content/properties) beyond mere capability needed to hit the mark for you? > and how to perform it. Let's assume something really simple: same predicate allowed on Plan and (either Result or the object of the :produced triple); you name the predicate. On the Plan, it's a general or incomplete hint ... it needs additional context, in the form of either the Result or the primary output resource (:produced), in order to be used as intended; I think we violently agree on that much. On the Result/:produced, it's one of the following: 1: Completely specific to the request/:produced resource, as I laid out earlier. Seems to meet RQM's goal. 2: Same as on Plan, as you proposed earlier. There was an unanswered question of how to pass the context resource in, as I remember. Would have to work that out; given that we don't have namespace-qualified parameter names, I see us either 2a: defining a well-known oslc_auto: URI for this plan (with a corresponding well-known parameter name) that providers could extend with optional parameters... seems to meet RQM's goal., or 2b: saying it's implementation specific (which seems to defeat RQM's "not GreenHat-specific" interop goal). I think it's possible for GreenHat to actually implement #2 above via #1, although I grant I might be the only one so might need to make the "how" more explicit... and it definitely Would be implementation-specific, but still hidden from clients like RQM. I'm not overjoyed at the prospect of defining a well-known oslc_auto: URI for teardown plans in general, but that might change as I learn more. We'd still need choose where the link goes (Result vs :produced); I don't have any strong feelings either way on that. Plan + :produces -> resource shape(s) for design time or UI-based introspection, sure fine makes perfect sense. I can see that being useful with or without :produced, FWIW. I'm guessing that it's 0:* since any given Plan could produce different resource(s) based on its input parameters. Stephen will have to chime in for his part; Michael is out this week, that's why I'm chairing. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
