Query support is not an issue for the implementation that spawned this thread. It is a different one than the synchronous case we've been discussing recently; most if not all of its requests will use the "asynch interaction style" that Automation is really geared toward. Nothing wrong with the predicate being 0:1, so the implementation can calculate it on behalf of clients or not (clients calculate it via query) based on its primary use cases. Note also that if the proposed "interaction style" changes are adopted into the spec then query over Results will indeed be required (MUST) as soon as the implementation either (a) implements a single asynch request or (b) wants to allow "non-synchronous-capable" clients ... i.e. the majority of them.
Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Charles Rankin/Austin/IBM@IBMUS To: [email protected] Date: 05/07/2012 10:47 PM Subject: Re: [Oslc-Automation] Potential new requirement Sent by: [email protected] [email protected] wrote on 05/07/2012 04:00:46 PM: > One of our potential implementations wants to be able to easily > retrieve only the most recently updated Automation Result for a > given Plan. As they noted when they crafted their extension, any > Plan may have many Results (in-flight and/or completed). They are > only interested in the most recently updated one. A few thoughts: 1) I've found it more common to want to know the most recently created result, not the most recently modified one. And, for the tools I'm most familiar with, this tends to be the default sort order for results (most recently created first). 2) This seems like it is readily derived using OSLC query against the current resource definitions. Granted this requires that the implementation support query. 3) I suspect for most existing tools, this requires additional computation (for all naked GETs). I wonder if this is used frequently enough to warrant that additional computation? Or, in the reverse, I wonder if naked GETs will be used enough to worry about the overhead. Of course, if we don't provide it directly, and it is common, then you end up needing query, which we aren't requiring. Charles Rankin _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
