[cssm] Data format version number?

[Barkley, Erik J (US 3970)]

CSSM Colleagues,

Our discussion at our latest telecon about versioning the XML Schema in GitHub, etc. got me thinking as to whether or not we need to include a version number in the Xml instances with regard to the data format/data entity itself.  Current in the CDE book we have this description for the version parameter of the SrvMgtHeader class:

The version of the information entity. This increments every time an information entity of the same concrete type, status, and time range is generated (i.e., has the same startTime and endTime). NOTE - The version may increment by 1 every time but is not constrained to do so. The only constraint is that each version number is greater than the previous.

So this allows tracking various instances of data entities, but does not identify that the particular data entity is version 1 or 2, etc of the data format.  Given that this will have to validate against a versioned XML Schema, it could be argued that format version identifier is not needed.  But then given that XML is about extensibility it seems feasible that an older instance document could validate against a later schema and so perhaps the data format version identifier may be of some use. Granted, the XML instance documents are likely to be rather ephemeral as they are exchanges about requests for service and/or information/plans being returned at a particular moment. As mostly an aside, if we were ever to have a JSON version of our XML instances perhaps the data format version identifier might become more important?

I notice that the NAVWG is putting a message Id and version number in as attributes of the root element - for example, for the OEM (Orbit Ephemeris Message) the root element is declared like this:

<oem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://sanaregistry.org/r/ndmxml_unqualified/ndmxml-2.0.0-master-2.0.xsd"
id="CCSDS_OEM_VERS" version="2.0">

I'm curious if anyone in the working group has any thoughts or comments about this.

Best regards,
-Erik


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220208/4a22e521/attachment.htm>