perfsonar development work

[maxim <>]

Hi roman,
You example is not going to work in all cases , for example how it will 
behave if someone
will send something like:
 <nmwg:parameter name="startTime">
          <nmtm:time type="ISO">
               <nmtm:end value="2007-08-10T10:40:00Z"/>
          </nmtm:time>     
 </nmwg:parameter>
----------
or some tim ernage in startTime and some time range under endTime.
I would strongly suggest to be explicit by utilizing only single time element.
It will make the whole API much cleaner.


 --Maxim


> -----Original Message-----
> From: Roman Lapacz 
> [mailto:]
>  
> Sent: Friday, December 07, 2007 4:48 AM
> To: Jeff W. Boote
> Cc: 
> ;
>  maxim; 
> 
> Subject: Re: [pS-dev] treating the time right in the schema
> 
> Jeff W. Boote wrote:
> > My simplistic approach was going to be to support something 
> like this 
> > for current time parameters:
> >
> > <nmwg:parameter name="startTime" type="nmtime">
> >     <nmtm:time> <!-- see nmtime.rnc --> </nmtm:time> 
> </nmwg:parameter>
> Hi,
> 
> java ma service already supports something like this:
> 
>       <nmwg:parameter name="startTime">
>           <nmtm:time type="ISO" value="2007-08-10T10:40:00Z"/>
>       </nmwg:parameter>
>       <nmwg:parameter name="endTime">
>           <nmtm:time type="ISO" value="2007-08-10T11:45:00Z"/>
>       </nmwg:parameter>
> 
> 
> I agree with you that we should start using nmtm time element(s).
> 
> Roman
> 
> 
> >
> > 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
> >
> > Jason Zurawski wrote:
> >> Maxim and Jeff;
> >>
> >> For clarification, could one (or perhaps both) of you 
> propose a new 
> >> way forward.  Something small and simple is good enough to 
> kick this 
> >> discussion off.
> >>
> >> -jason
> >>
> >>>>  Hello ( mostly schema and protocol people), While 
> working on psPS 
> >>>> framework API I found that according to the current schema 
> >>>> definition its very inconvenient to send 
> select:parameter with some 
> >>>> time range select values.
> >>>> For some reasons there is a time schema but there is no 
> support for 
> >>>> time elements in
> >>>> the select parameter.   So, people basically using something like
> >>>> <parameter name="startTime">... instead of normal time 
> element. Its 
> >>>> very strange to have  several ways to treat such thing 
> as time. As 
> >>>> the simplest approach and may be the easiest step I 
> would suggest to
> >>>> allow current time   element as subelement of parameter. 
> Of course I
> >>>> can support it for my service ( pinger MA) at any time but this 
> >>>> feature will benefit every other service as well.
> >>> I am planning to support nmtime objects as sub-elements 
> of parameter 
> >>> elements for the owamp/bwctl (perfSONOBOUY) MA. (I have 
> been unhappy 
> >>> with the current treatment of time - and have been for a while. 
> >>> Search the archives for details.)
> >>>
> >>> I agree that if all services were using the nmtime 
> element, then an 
> >>> implementation that understood how to decode the nmtime element 
> >>> could be shared across multiple services.
> >>>
> >>> Of course, this would represent a major protocol change for any 
> >>> existing services and it would therefore need a fair 
> amount of time 
> >>> to make its way into already deployed services.
> >>>
> >>> Lets at least make sure that you and I are implementing 
> this using 
> >>> the same schema (syntax) - then perhaps we can convince other 
> >>> services to adopt it in the future to make coding clients and 
> >>> servers easier with regard to this often used concept.
> >>>
> >>> jeff
> >>>
> >>
> >>
> 
>