[cssm] Data format version number?
Martin.Unal at esa.int
Martin.Unal at esa.int
Mon Feb 21 10:26:18 UTC 2022
Having the standard version of the format in the header will allow
handling of backward compatibility.
I don't think it is highly critical, as which version shall be used will
be part of the user-provider agreement. So the version information shall
already be known by design.
But it doesn't hurt to have it clearly stated in the header.
I am more worried by "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."
Such information is sensitive to database reset. It requires on its own a
complete definition of its usage to handle discontinuity in the "version"
e.g. How do you trigger a reset of version in case the user/provider DB go
out of sync ? How do you handle error detection in its usage.
That would require its own standard to be of use.
As the notion of entity "version" will only be used for some
user/provider, and its handling will be different for each pair. I think
it shall go out of the standard and inserted as Extended Parameter
whenever its presence is required. Doing so, it will allow to support
different "version" concept in a single implementation as the parameters
will have different names.
Ground Operation Manager
Ground Facilities Ops HSO - ONO
Robert-Bosch Strasse 5
64 293 Darmstadt
Tel +49 6151 90 2959
From: "Barkley, Erik J\(US 3970\) via SMWG" <smwg at mailman.ccsds.org>
To: "CCSDS Service Mgmt WG" <smwg at mailman.ccsds.org>
Date: 08/02/2022 21:25
Subject: [cssm] Data format version number?
Sent by: "SMWG" <smwg-bounces at mailman.ccsds.org>
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:
I'm curious if anyone in the working group has any thoughts or comments
SMWG mailing list
SMWG at mailman.ccsds.org
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG