perfsonar development work

[Jason Zurawski <>]

Roman;


> > 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. 


Yes, every key corresponds to only one metadata, but that same metadata 
may be used for many keys. 


> 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?


I agree that it can (and may want to) use a key, but other methods to 
build the chain should be possible as well.  The chaining itself should 
be independent from what is contained inside.


-jason