XML-NDM Schema Issues (From Service Management Perspective) 18 September 2012

2 Agenda  Background  Issue 1: “qualified” vs. “unqualified” elementFormDefault  Issue 2: multiple versions within the same namespace  Follow up

3 Background  The Space Communication Cross Support Service Management (SCCS- SM) Recommended Standard (CCSDS ) imports the XML-NDM schemas for OPMs and OEMs in various Trajectory Prediction messages  The current version of the SCCS-SM schemas imports the Red-1 XML-NDM schemas, because that’s what was available in 2009 when SCCS-SM Blue-1 was published  The Service Management Working Group (SMWG) wants to update the SCCS-SM schemas to import the OPM and OEM schemas corresponding to the XML-NDM Blue Book  However, when the SMWG attempted to put in the latest XML-NDM schemas, we found that a change had been made that seriously complicates the ability to easily import the XML-NDM schemas  This issue applies not only to the SCCS-SM, but to any other organization or standard that needs to incorporate XML-NDM schemas  Also, the XML-NDM schemas violate XML namespace rules in a way that makes them unusable in a multi-version environment

Issue 1: “qualified” vs. “unqualified” elementFormDefault (1 of 2)  The XML-NDM schemas posted on SANA have elementFormDefault = “unqualified”  In order for another set of schemas (such as that for SCCS-SM) to be able to import unqualified schemas, that importing set of schemas must be declared “qualified” to avoid namespace clashes  This causes all tags that are native to that importing set of schemas to have namespace prefixes attached in the instance documents  This was a change from the XML-NDM Red Book schemas, which were declared “qualified” and therefore had their tags prefixed with namespace  NavWG motivation for change  Uniformity in appearance of NDM content in all XML instance documents  Appearance close to that in the KVN ODM messages  Concern for “misleading namespaces”  Using the XML-NDM schemas in their current (unqualified) form would require detailed rework of importing schema sets for every XML-NDM update 4

5 Issue 1: “qualified” vs. “unqualified” elementFormDefault (2 of 2)  Best practice for XML schema design  “Make two identical copies of all your schemas, where the copies differ only in the value of elementFormDefault (in one copy set elementFormDefault=“qualified”, in the other copy set elementFormDefault=“unqualified”)”  SMWG requests that NavWG make available both qualified and unqualified sets of the XML-NDM schemas via SANA  Standards/applications that import XML-NDM schemas would need to declare which set of schemas to be used  In order to mitigate concern for misleading namespaces and increase uniformity of appearance across XML documents, each qualified set would be accompanied by a recommended namespace prefix (e.g., “ndm”) when published to SANA  “unqualified” set can be used in applications or standards where maximum similarity to KVN version is most important

Issue 2: multiple versions within the same namespace (1 of 2)  All XML-NDM schemas are under the same namespace  “urn:ccsds:recommendation:navigation:schema:ndmxml”  Within various schema files, multiple types use the same name  “oemType” in both ndmxml-1.0-oem-1.0.xsd and ndmxml-1.0-oem-2.0.xsd files  “opmType” in both the ndmxml-1.0-opm-1.0.xsd and ndmxml-1.0-opm-2.0.xsd files  Version attributes in each type indicates version (“1.0” and “2.0”) but attributes cannot be used to differentiate among type names within the same address space  XML-NDM schema files on SANA include “master” files that include only those files for a specific version number  Use of these master files hides the existence of other types with the same name within the same namespace, but they still exist  No problem if only one (version) set is used in any given application

7 Issue 2: multiple versions within the same namespace (2 of 2)  Current XML-NDM approach does not work in applications where multiple versions must exist concurrently  E.g., an implementation of an institutional system that simultaneously exchanges data with users of different versions SCCS-SM is such a case  Two possible solutions identified  Create a unique namespace for each new version This approach was adopted in the Red Book version of the XML-NAV schemas  Keep one XML-NDM schema namespace, but differentiate the type names E.g., “oemV1Type”, “oemV2Type”  Separate namespaces is conceptually cleaner: every new issue of the standard gets its own namespace  Single namespace may make it easier to generate code from the schema files.  (What are the implications of each approach for the content and structure of the XML-NDM Blue Book?)

Recommended Approach to Resolution  First priority: resolve qualified/unqualified issue  No changes to XML-NDM Blue Book needed if current “unqualified” set is simply replaced by “qualified” set in SANA  Minor (almost editorial) changes to Blue Book might be needed if both “unqualified” and “qualified” sets are posted on SANA  If both qualified and unqualified versions of the schema files are produced, how will they be differentiated in SANA?  Longer term: resolve multiple versions within the same namespace issue  Identify approach: separate namespaces per version vs. include version identification in type names There should probably be some CCSDS-wide approach  Identify and make changes to XML-NDM Blue Book to reflect resolution  Update schemas and repost to SANA Does one simply replace material on SANA, or is there some type of SANA “versioning”? 8