[Oslc-Automation] Potential new requirement

[Charles Rankin]

I'm intrigued by the suggestion of using zero-or-one as an "opt-in".  My 
interpretation of this as a consumer would have been, if such a property 
is available within the underlying implementation, the service provider 
will give it to me.  Thus, if it isn't present, no such property exists in 
the underlying implementation.  However an "opt-in" interpretation says 
that it may very well exist, but the service provider is simply choosing 
not to give it to me.  Is there any guidance (in Core) around this?  Does 
this behavior have to be deterministic in any way, or can the provider 
"randomly" choose when it wants to provide the property?

Is this type of opt-in behavior valid for zero-or-many properties?  For 
example, can an Automation provider arbitrarily choose not to include the 
oslc_auto:input Parameters for an AutomationResult resource definition 
even when it is otherwise capable of doing so?

Charles Rankin




From:
Michael F Fiedler/Durham/IBM at IBMUS
To:
oslc-automation at open-services.net
Date:
05/08/2012 06:40 AM
Subject:
Re: [Oslc-Automation] Potential new requirement



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
_______________________________________________
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/20120509/4a0a50e3/attachment-0003.html>