perfsonar development work

["Jeff W. Boote" <>]

maxim wrote:
>   
> > type is currently used for all current 'time' based parameter 
> > elements in existing services.
>  what are the  'time' based parameters ? I know only one parameter and as far 
> as
> there is only definition for this parameter in schema then there is no "type" 
> attribute.
>  
>
> Just checked the most recent one under: trunk/geant2_java-rrd-ma/doc/schema/
>
> Its still:
> ---------------------
> Parameter =
>         element nmwg:parameter {
>         attribute name { xsd:string } &
>                 (
>                         attribute value { xsd:string } |
>                         xsd:string
>                 )
>         }
> -----------------------------------

Ah - right you are. My mistake. I thought we were using the same construct in 
parameters that is used in datum. (Yes, this is a good example for why we should 
be handling time uniformly.)

After looking closer, it looks like the current state of the services is 
(Roman/Jason - please correct me if I'm wrong):

Time related parameters such as "startTime", "endTime" are assumed to be unix 
strings. (Roman apparently supports nmtime child objects as well, but it is not 
in the interface doc. ;) )

My suggestion going forward is this:

1) keep 'startTime' and 'endTime' parameters for at least the next major release 
- perhaps even the one after that. These parameters can be specified with 
String's that will be interpreted as 'unix' timestamps (as they are now). Or, 
they can be an nmtime element - but only the TimeStamp variety. (no start/end 
child elements allowed - these would be a semantic error)

2) add a 'timeRange' parameter (I don't care the name) which is specified using 
a general nmtime element child, which must specify a range using the start/end 
or start/duration syntax.

3) eventually deprecate 'startTime' and 'endTime' as direct parameters.

jeff