[Smwg] RE: RIDs for the SchemaMaster

[John Pietras]

Hello, Colin. I've looked through the two RIDs that you forwarded, and here are my responses.



The first of the two RIDs (CSSM-056) recommends that "schedulePackageID" be changed to "schedulePackageId". I agree with the reviewer that this follows the camelCase convention that we have used elsewhere in the document.



The second RID (CSSM-058) recommends that a version "specification" be added to the schema, " such that any validating parser can check if the version of the XML instance is compliant with the version of the schema". The WG accepted the recommendation and I concur.  Here are my thoughts and plans for how to do so. I welcome any comments.



There are two levels at which the version of the schema can be validated. At the top level, namespaces are used to demarcate the version at the level of the Issue of the Recommended Standard, with each Issue getting its own namespace. An instance document generated from schema registered under one namespace cannot be validated under a different namespace. E.g., if Mission X generates a Simple Schedules using a (future) Issue-2 schema and attempts to submit it to a PCSSS that still only support the Issue-1 version, it will of course fail validation. Different namespaces are required because multiple versions of the schema must be supported concurrently (at least for some period) owing to legacy support considerations and differing rates of standards adoption and maintenance.



The second level of versioning occurs where the schema maintenance produces intermediate corrected versions for the same Issue of the Recommended Standard, e.g., because the original version of the schema inadvertently omitted a required enumeration value. This does not result in a new namespace but a replacement of the schemas within the existing namespace*. Technically, only one set of schemas is valid for each namespace at any given time, but schema maintenance for the various implementation of those schemas will almost certainly take place at different rates. At some point it is likely that some creator/consumer pair will be using different iterations of the "Issue X" schema (and therefore using the same Issue-X namespace), with both sides believing their version to be current and correct. To flag this level of versioning I will add a schemaVersion attribute to the SimpleSchedule type. The schemaVersion attribute will be of type xsd:string with the syntax 'X.Y.Z', where "X" is the Blue Book Issue number, "Y" represents a Technical Corrigendum number (if any - it is zero otherwise), and "Z" represents the iteration of the current schema. Technically, the "X" component is unnecessary since that information is captured in the namespace itself, but I think it is nice to have the complete provenance of the version in one place. The "Y" component is there to record the fact that the schema reflects changes (if any) caused by a Technical Corrigendum, since a TC does not change the Issue number itself. For purposes of versioning uniqueness and validity are concerned, I propose that only the version of the schema that includes all approved TCs is valid - i.e., there is still only one formally valid schema for each issue.



  [NOTE - The extended (post-Blue-publication) NASA/JAXA interoperability tests unveiled some typos in element names that were subsequently corrected in the Blue-1 schema and therefore resulted in a new version number. We subsequently agreed that schemas that otherwise accurately represent the data structures of the Recommended Standard should not be changed just to correct typos, because the resulting effort to update otherwise-good schemas in operational systems would generally outweigh the benefit of correcting a few tags in the instance documents. New intermediate versions should be created only when the existing schema is found to incorrectly or incompletely represent the functionality of the Recommended Standard.]



Best regards,

John



-----Original Message-----
From: Colin.Haddow at esa.int [mailto:Colin.Haddow at esa.int]
Sent: Monday, November 17, 2014 12:53 PM
To: John Pietras
Subject: RIDs for the SchemaMaster





Hi John,

                 hope you had a good trip home. As you may remember there were a couple of RIDs on the Simple Schedule book flagged for the attention of the SchemaMaster. I've attached these below for your comments.



Cheers for now,



Colin



(See attached file: RIDs for SchemaMaster.docx)



---------------------------------------------------------------------------------------------------------



Dr. Colin R. Haddow,

HSO-GI, European Space Agency,

European Space Operations Centre,

Robert-Bosch-Str 5,

64293 Darmstadt,

Germany.



Phone; +49 6151 90 2896

Fax;      +49 6151 90 3010

E-Mail;  colin.haddow at esa.int<mailto:colin.haddow at esa.int>

---------------------------------------------------------------------------------------------------------



This message and any attachments are intended for the use of the addressee or addressees only.

The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted.

If you received this message in error, please notify the sender and delete it from your system.

Emails can be altered and their integrity cannot be guaranteed by the sender.



Please consider the environment before printing this email.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20141118/aebdc9b1/attachment.html>