Ok. I've added a use case about this sort of creation scenario to the OASIS OSLC Core TC Delegated UI Use Cases [1], where we may find a scenario where we want this sort of predicate, or a different direction may be taken. So I'm happy to wait to see what comes from Core (so, yes, keep it simple now and add something in later if/when it's needed - although that gives us the same problem of not knowing what 2.1 providers mean as we have with 2.0 providers for identifying immediate or deferred execution, but I guess that's the RDF way - open world assumption etc).
Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint chair E-mail: [email protected] Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU "Oslc-Automation" <[email protected]> wrote on 13/03/2014 12:59:09: > From: John Arwe <[email protected]> > To: [email protected], > Date: 13/03/2014 12:59 > Subject: [Oslc-Automation] 2.1 open comment: short lived creation > dialog results > Sent by: "Oslc-Automation" <[email protected]> > > In [1] we have this as an open note: > Martin: Should we also have an oslc:usage value for dialogs where > the created resources are “especially likely to be short-lived”? All > deferred execution dialogs right now should have it, but it provides > flexibility going forwards. Although I’m not sure what consumers > would do with it right now… > The "short lived" comment it refers to is at the end of that > section; final paragraph, and note nested under it. > I think my take here is: in order to make such a usage value useful > to clients, we'd have to be concrete about "especially likely" and > "short-lived". I don't think it's feasible to be concrete enough to > be obviously useful in the absence of scenarios that clearly call > for it. So, KISS and do nothing now; we can always add something in > the future once the needful scenario(s) emerge. > I don't know how to deal with "likely"; if a dialog creates some > mixture of long and short-lived resources, and their lifetime is > influenced/determined by creation parameters, "likely" is entirely > dependent upon client usage so I can't see how to generalize it. > "Short lived" really is a nice way of saying that the provider > garbage collects (or is allowed to) on a short interval, to prevent > lots of cruft accumulating. We could have the provider expose its > garbage collection interval, but that's no guarantee (in either > direction); if the provider determines that it's running low on some > resource, I don't think we can prevent it from reclaiming it by > garbage collecting "early", nor can we force it to collect "on > time". I.e. it's a hint to the client. Conceptually I don't object > to that, but we have no scenarios even asking for it so I'm inclined > to wait until we do. > [1] http://open-services.net/wiki/automation/OSLC-Automation- > Specification-Version-2.1/#Deferred-Execution-Creation-Dialog > 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
