On Mon, 2 Jul 2007, Rob Seaman wrote:
> issue is that date and time must form an atomic whole. Perhaps the best way
> to eliminate this issue is to avoid "time" fields entirely in favor of "date"
> analogs as with FITS DATE-OBS.
For most time values we use absolute time values formatted as ISO 8601 (like DATE-OBS), however for precision time values within an observation, it is preferable to use a zero point - offset scheme, e.g., MJD for the zero point, and offset in seconds or days for the individual time values. This is especially important if there are many time values, as in a large time series. It is up to the data provider to specify the units used and ensure that the metadata is correct.
>>>> Since the data model is defined independently of the serialization, there
>>>> is no need to pick a single serialization.
>
> Which I understand to imply that VOEvent - an XML publication standard -
> might settle on a distinct time series representation from other VO
> applications relying on CSV, FITS, native VOTables, or "graphical rendition"
> (e.g., IRAF GKI metacode, I suppose).
You could do that and still use the data model. However it would require custom software to read and write the time series object; to use a standard tool that doesn't support VOEvent would require some custom software to extract the data into a standard format. But this would be better than inventing a new data model that does the same thing as what we already have.
The alternative would be to treat the time series as an object, and somehow attach or embed it in the VOEvent, e.g., as a VOTable. This would allow standard software to be used once the object is extracted from the VOEvent "container". Either approach could work.
Note, there is also a direct XML serialization of the data model which is already defined. If you have to use native XML you might want to look at that. Most applications though prefer to work with VOTable or FITS so that generic tools can be used.