perfsonar development work

[maxim <>]

> 
> And if in the future we come up with another select parameter 
> that is also time related? Perhaps one that is used to select 
> only sub-sessions of a specific duration within the given 
> time range? Or perhaps one to select only data of a specific 
> precision?
> 
 extend the schema but leave time parameter the same. Or come up with
new filter so service will understnad what that specific time means.

> I'm not saying these particular examples are likely - only 
> that it is pretty easy to think of cases where you would want 
> more than one parameter in a parameters list that should be 
> of type nmtime.
> 
> I simply prefer to have more meaningful parameter names. I 
> fully agree that we should handle the same conceptual things 
> in a common fashion. I do not agree that we should create 
> generic instance names for them.
> 
> jeff
> 

but right now it serves as range and timestamp and thats fine because all 
examples
you mentioned can be easily constructed out of this base time object. By 
extending
current schema. If you want to call it timeRange instead of time thats fine 
with me.
 Cheers, 
         Maxim.