specify that datetime string serialization to conform to ISO 8601

[pahjbo]

update the base IVOA model documentation to make this clear - separate distinction with times in CoordsDM

preferably UTC - but as long as the string conforms to ISO 8601 then this does not matter.

[pdowler]

Should the model actually specify serialization? Are there other cases where it does?

[pahjbo]

In general the standard does make a distinction between "logical" and "physical" representations of a model instance and clearly for the logical representation there is no serialisation - however for the physical representation then there is and Appendix B does discuss this somewhat. I have been trying to promote the idea in the vodmltools that there is a "standard" serialisation of model instances (in a direct object tree representation as opposed to other serialisations like MIVOT) in various formats for direct interoperability - and in particular this makes it easy to have a JSON representation that can be used for APIs for instance.

Perhaps these "standard" serialisations as I am calling them could be in a separate document

[Zarquan]

I have been trying to promote the idea in the vodmltools that there is a "standard" serialisation of model instances ...

I have been trying to promote the idea of separating the details of data model from the serialisation.

I want to avoid making the same mistake we made in the early development of linking our standards too strongly to XML (understandable at the time, but a mistake nevertheless) by simply replacing XML with JSON.

Separate documents sounds good.

We should also make it clear that rules like ISO 8601 only apply to specific text based serializations.

Part of the results from the P3T work proposed separate documents defining the rules for each serialization format.

• IVOA JSON Serialization profile
  Datetime serliaised as ISO 8601 strings

• IVOA Avro Serialization profile
  Datetime serliaised as long (microseconds from the unix epoch)

[pahjbo]

The original point that I was trying to make, but not clearly, is that the current text says

Represents a point in time. Will generally need time frame and units in
the serialization.

This implies the full concept of a point of time that requires the complexity of the model in COORDS to actually achieve - I think that the most common use of this primitive is indeed to actually specify a point in time in the UTC timescale in a topocentric frame - i.e. just everyday "civil" time. - so I am proposing changing the definition to reflect that more restrictive use.