perfsonar development work

["Jeff W. Boote" <>]

Jason Zurawski wrote:
> > 4. There would be no way for a client to specify what timeType they 
> > want. We should create a time element API for creating time elements 
> > represented with different types.
>
> So the issue still remains of what to do for 'display' of values (not 
> necessarily the same as the time that will be used in the select 
> statement).  I still believe that this is best in a separate parameter 
> block, and as Roman pointed out this couldn't be in the same md block 
> currently.  I would propose some sort of additional filter chaining as 
> well (although I still think we need to abuse the notion of timeType a 
> little further, since this is more of a presentation element than a time 
> value):

So, perhaps I was not clear enough. What I intended to indicate in my #4 is that 
I don't think 'display' information should be in the message at all. It is easy 
enough for the client to do this time format conversion. And, if it important to 
have formats that only present time in a specific format - then we create a 
complete new eventType namespace for this more strict representation. Then you 
can request the new eventType namespace from a transformation service that 
understands where it can get the 'native' format from.

jeff