1 / 8

XML-NDM Schema Issues (From Service Management Perspective)

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.

ivy-richard
Download Presentation

XML-NDM Schema Issues (From Service Management Perspective)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 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

  4. 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

  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

  6. 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?)

  8. 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”?

More Related