perfsonar development work

["Jeff W. Boote" <>]

maxim wrote:
> sorry, missed this one... 
>  
> > My simplistic approach was going to be to support something 
> > like this for current time parameters:
> >
> > <nmwg:parameter name="startTime" type="nmtime">
>  
> hmm, there is no type attribute in the nmbase schema.
> there is value attribute but then you cant include anyElement inside.

type is currently used for all current 'time' based parameter elements in 
existing services.

> > 	<nmtm:time> <!-- see nmtime.rnc --> </nmtm:time> 
> > </nmwg:parameter>
>
> time element is very expressive and it has already type,  start/end, and timestamp 
> capability so basically you need only one time parameter anywhere:

Of course, I guess I did not explain myself well enough. Look below at HERE - I 
already said that for 'new' time based parameters it did not make sense to use 
'type' in the parameter. That is specifically because the nmtime element already 
describes itself very expressively. Using 'type' in the parameter is about 
maintaining backwards compatibility for existing parameters that do NOT 
currently use nmtime.

>   <nmwg:parameter name="time"> 
>   	<nmtm:time type="unix">
>         <nmtm:start value="1983838444"/>
>          <nmtm:end inclusive="yes" value="1983838444"/>
>      </nmtm:time> 
>   </nmwg:parameter>
> ------

HERE:
> > For new parameters of type 'time' the 'type' attribute would 
> > not be needed because the child element type could be 
> > directly put in the rnc file along with the parameter name 
> > enumerations.
> >
> > I realize this does not add a bunch of functionality over 
> > type = "unix" for something as simple as selection. It does 
> > however localize the time handling, and this simple case 
> > could be handled using the same syntax rules/code as the more 
> > complex ones.
> >
> > jeff
>
>  yes, thats why I was so pursvaisive...I'd like to have one place in API
> which knows how to handle time.  
>
> --Maxim