[Oslc-Automation] Potential new requirement

[Michael F Fiedler]

The potential issue with a an approach base on query is the ability to
easily identify the real "most recent" result.  OSLC query has
oslc.orderBy, but that is only useful today in the context of page
ordering.   Core 3.0 is discussing other potential approaches towards true
query result ordering.

But I do agree with Charles's concern on a penalty on the GET of a test
plan - how much work will different service provider implementations have
to do to resolve that most recent result?   As mentioned elsewhere in the
discussion, making the relationship zero-or-one allows for opt-in.

Tee-ing this one up for this week's meeting.

Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170

oslc-automation-bounces at open-services.net wrote on 05/07/2012 10:47:02 PM:

> Charles Rankin/Austin/IBM at IBMUS
> Sent by: oslc-automation-bounces at open-services.net
>
> 05/07/2012 10:47 PM
>
> To
>
> oslc-automation at open-services.net,
>
> cc
>
> Subject
>
> Re: [Oslc-Automation] Potential new requirement
>
> oslc-automation-bounces at open-services.net 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
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120508/f5827154/attachment-0003.html>