80 likes | 208 Views
XML-NDM Schema Issues (From Service Management Perspective). 18 September 2012. Agenda. Background Issue 1: “qualified” vs. “unqualified” elementFormDefault Issue 2: multiple versions within the same namespace Follow up. Background.
E N D
XML-NDM Schema Issues(From Service Management Perspective) 18 September 2012
Agenda • Background • Issue 1: “qualified” vs. “unqualified” elementFormDefault • Issue 2: multiple versions within the same namespace • Follow up
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
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
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
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”?