perfsonar development work

[Roman Lapacz <>]

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