Hi Francois -
> Notice that in the VOTABLE we considered the example as a SED with
> two segments (one for each color). Although they are not listed in
> the Spectrum Reference document we added the head element SED in
> the utypes and replace Spectrum by TimeSeries everywhere. these new
> utypes can be easily inferred from the xml schema in the general SED
> case when segments are different from the single spectrum case.
For a time series with multiple flux values per time coordinate, why not represent this as a single segment? Normally this would be a single observation, and all the other metadata is the same. I should think that multiple segments would be used for observations at different times, much as for a multi-segment spectrum, the different segments might represent different regions of spectral coordinate (e.g., as for an Echelle).
If we take a time series with multiple flux values per time sample, and serialize it in TSV, one would expect to see something like
TimeValue Flux1 FluxErr1 Flux2 FluxErr2
167.1178 5.105 0.162 5.617 0.080
181.0784 5.392 0.135 5.609 0.079
which would be the direct analogue of a VOTable representation which has mutliple flux values per time sample, and would be what we get if we write out this same time series in CSV/TSV instead of VOTable.
In this case the VOTable would contain multiple GROUPs with UTYPE spec:SED.TimeSeries.Data.FluxAxis, however I don't see any problem with this. For UTYPE the important thing is that the UTYPE uniquely identify the field of a data model; this does not mean that we cannot have multiple instances of a data model in a single namespace, such as a VOTable.