XML-NDM Schema Issues(From Service Management Perspective)

18 September 2012

www.ccsds.org 2

Agenda

Background

Issue 1: “qualified” vs. “unqualified” elementFormDefault

Issue 2: multiple versions within the same namespace

Follow up

www.ccsds.org 3

Background

The Space Communication Cross Support Service Management (SCCS-SM) Recommended Standard (CCSDS 910.11) 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

www.ccsds.org

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

www.ccsds.org 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

www.ccsds.org

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

www.ccsds.org 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?)

www.ccsds.org

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