perfsonar development work

[Roman Lapacz <>]

Jason Zurawski wrote:
> Thats not entirely true, a cooked key gives you access to the combined 
> effects of the end of a chain of metadata.  The important thing to 
> remember here is that a chain is constructed with an *explicit* 
> ordering to get some specific data (i.e. first grab the entire data 
> set, then run a filter chain on time, then perhaps do a CDF):
>
>
> <nmwg:metadata id="1">
>  <nmwg:key>
>    <nmwg:parameters />
>  </nmwg:key>
> </nmwg:metadata>
>
> <nmwg:metadata id="2">
>  <select:subject metadataIdRef="1"/>
>  <nmwg:eventType />
>  <select:parameters />
> </nmwg:metadata>
>
> <nmwg:metadata id="3">
>  <cdf:subject metadataIdRef="2"/>
>  <nmwg:eventType />
>  <cdf:parameters />
> </nmwg:metadata>
>
> <nmwg:data id="d1" metadataIdRef="3" />


Yesterday I promised to go back to the chain solution for a key :) The 
above example is fine and clear for me but one thing I have to clarify 
from my point of view. A key generated by a service can have only one 
metadata (at least for above example) which represent the location of 
data. The type of such metadata is static (of course there is a 
possibility that data can be moved to another location, for example rrd 
file). But select parameters in metadata id=2 are not static. startTime  
and endTime may be (and usually they are) different for each request 
from client application. That is why only client app should build a 
chain using a key (see metadata id=1) fetched from a service.

Jason, do you agree?

Roman