[cssm] Data format version number?

[Martin.Unal at esa.int]

Hello

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" 
handling. 
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.

Regards
________________________________________
Martin UNAL
Ground Operation Manager
Ground Facilities Ops HSO - ONO
H-376
ESOC
Robert-Bosch Strasse 5
64 293 Darmstadt
Germany
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>



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
 
 _______________________________________________
SMWG mailing list
SMWG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg



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...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20220221/92bd6ea5/attachment.htm>