perfsonar development work

[Fausto Vetter <>]

Hi,

If jason meant this kind of merging that Roman pointed, I think it is 
not robust, once you might have in 2 types of parameters a same named 
parameter and you actually never knows what is from one parameters type 
and what is from the other one. I liked roman's idea of being able to 
use n parameters in message with different namespaces.

Fausto

Roman Lapacz wrote:

> Jason Zurawski wrote:
>
> > Roman;
> >
> > > I've got one more observation related with parameters in our schema. 
> > > Now only one parameters element is allowed to be in the metadata. 
> > > What do you think to allow existence of more than one. This would be 
> > > useful to keep in the same metadata (or other element, for example 
> > > the key) parameters representing more then one namespace.
> > >
> > > Example for the key:
> > <snip>
> >
> > I believe this has been brought up before in previous conversations, 
> > I don't see a problem with allowing multiple parameters blocks, as 
> > long as they have a different namespace designation (in your example 
> > nmwg/select/transform is ok).  But this is not even a hard 
> > requirement, we could just 'merge' blocks with a similar namespace 
> > (although it will be important to document the behavior).
>
>
> What do you mean "'merge' blocks with a similar namespace"? If you put 
> parameter elements (for example, those related with nmwg, select and 
> trans) in one block then you lose the information to what parameters 
> group/namespace they belong. Example:
>
> <nmwg:key>
>     <nmwg:parameters id="params1">
>         <nmwg:parameter 
> name="file">/home/romradz/test.rrd</nmwg:parameter>
>         <nmwg:parameter name="dataSource">pkts</nmwg:parameter>
>         <nmwg:parameter name="valueUnits">Bps</nmwg:parameter>
>         <nmwg:parameter name="startTime">1121472000</nmwg:parameter>
>         <nmwg:parameter name="endTime">1121904000</nmwg:parameter>
>         <nmwg:parameter 
> name="consolidationFunction">AVERAGE</nmwg:parameter>
>         <nmwg:parameter name="resolution">60</nmwg:parameter>
>         <nmwg:parameter name="ConvertTo">unix</nmwg:parameter>
>         <nmwg:parameter name="ConvertFrom">iso</nmwg:parameter>
>     </nmwg:parameters>
> </nmwg:key>
>
>
> Could you show an example of merging you mentioned?
>
>
> > > It's possible to overcome this problem without using above solution 
> > > if I had enhanced parameter elements. I put example below but I 
> > > think it's just a trick and the above is more suitable.
> > <snip>
> >
> > This way does not seem as natural to me, and it forces a specific 
> > parameter element when we have tried to keep this very general.  It 
> > may also complicate searching via the standard search mechanisms:
>
>
> I agree with you. This was my opinion as well but it's always better 
> two see and compare more possible solutions and pick out the best one :)
>
>
> (I'm not pushing but I will be waiting for the implementation :)
>
>
> Roman
>
> > /nmwg:key/select:parameters/nmwg:parameter[@name="startTime"]
> > vs
> > /nmwg:key/nmwg:parameters/nmwg:parameter[@name="http://ggf.org/ns/nmwg/ops/select/2.0/"]/collection:item[@name="startTime"] 
> >
> >
> > This is not the most compelling of reasons, but the mapping is not as 
> > direct as in the former scheme.
> >
> > -jason