P1.1 Introduction
MISMO has defined an XML profile within the context of Real Estate Financial Transactions. XML Namespaces are an integral aspect of the profile. The purpose of XML Namespaces is to eliminate naming conflicts by defining the scope within which the names of data items apply. Namespaces therefore allow the use of multiple vocabularies in a single XML document. MISMO‘s strategy for data point and structure re-use makes Namespace handling critical.
This MEG provides requirements and recommendations for Namespace usage within MISMO messages. It recommends techniques for minimizing the interoperability problems that can result from the use of XML namespaces in XML applications. It is concerned with the XML that flows between services. It is not concerned with what goes on behind service boundaries, and places no restrictions on what XML features or technologies are used within the confines of a service.
P1.2 Audience
This MEG was written for the following groups:
- MISMO Workgroup members developing MISMO messages.
- Designers and users of systems that create and consume the XML instance documents used in Real Estate Finance transactions.
- Technical or business professionals wishing to evaluate MISMO specifications.
P1.3 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119
.
- MUST - This word, with the term “REQUIRED”, indicates an absolute requirement of the specification.
- MUST NOT - This phrase indicates an absolute prohibition of the specification.
- SHOULD - This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
- SHOULD NOT - This phrase, or the phrase “NOT RECOMMENDED” means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
- MAY - This word, or the adjective “OPTIONAL”, indicates that the specification allows the designer to choose whether or not to comply.
P1.4 Assumptions
This document reflects the MISMO architecture development and interoperability principles at the time of writing. It is a living document that is updated as required to reflect the evolving nature of XML technologies and requirements identified by the MISMO constituency.
P1.5 Rationale
The rationale for creation of a separate MEG with XML Namespace-related guidelines is based on the importance of Namespaces, and alignment with the scope of the W3C XML Namespace specification separate to the core W3C XML specification. Additionally, the W3C Technical Architecture Group (TAG) has defined a best practice that every organization with published namespaces should publish its policy about changes in the names defined within a Namespace. This MEG constitutes that policy.
Background
XML Namespaces were introduced to the XML family of standards in 1999. In theory, namespaces do not affect the fundamentals of XML parsing; however, in practice they do. Even low-level Application Programming Interfaces (APIs) such as SAX and DOM have split into those that are “Namespace aware” and those that are not.
The Namespaces recommendation is a very short document, but it has generated a considerable amount of discussion–not so much for what it says, but for what it does not say. There are a number of possible interpretations of what Namespaces are and these interpretations can lead to both semantic and lexical interoperability problems.
At the semantic level, there is much room for confusion about what a Namespace actually means. The specification is clearly defines Namespace as a named collection of names without any semantics. However, this does not deter users of Namespaces from imbuing them with more meaning than is strictly warranted.
Namespaces are also a potential source of interoperability problems at the lexical level, since a number of legal uses of namespaces can create problems for lexical processing. For example, some Namespace usage patterns complicate hashing XML document fragments (as required by digital signature applications). This use case in particular has necessitated the addition of an extra canonicalization algorithm, the W3C Exclusive XML Canonicalization.
Note that in general, it is NOT safe to perform lexical processing based on element type name matching on a document containing Namespaces. That is, you must use a Namespace-aware XML parser to expand the Namespace machinery. Although the MISMO Schema use Namespace prefixes consistently, it is NOT safe to assume that all instance files will use the same prefix.
Content
C1. Content
C1.1 Guidelines
| Ref |
Guideline |
| 3.1 |
Namespaces MUST comply with W3C recommendations
The W3C XML Namespace recommendations are described in http://www.w3.org/TR/1999/REC-xml-names-19990114/ |
| 3.2 |
Each MISMO schema MUST have a target Namespace that is defined as the MISMO Namespace. |
| 3.3 |
Namespaces MUST comply with MISMO Naming Standards
The Namespace MUST take the form of http://mismo.org/«sector»/YYYY/schemas where:
«sector» is either “residential” or “commercial”, and YYYY is the year the Residential Governance Committee approved the architecture.
For example, given the Credit Reporting v3.0 message approved at the January 2009 Trimester meeting, the Namespace would take this form: http://mismo.org/residential/2009/schemas
See MEG0006 for a description of how MISMO versions within a Namespace.
All transactions are published under the Namespace that is consistent with the architecture (i.e., 3.x) of their design.
For MISMO V2.x, the namespace is: http://www.mismo.org/residential/2001/schemas.
For Version 3.x, the namespace is: http://www.mismo.org/residential/2009/schemas. |
| 3.3.1 |
Namespaces MUST change with major Architectural changes and not with simple semantic changes.
Namespace-aware software appends a Namespace to the name of every node in the XML object model. Changes to a Namespace WILL be used to signal large architectural changes. Releases within a Reference Architecture will be noted by a change in the MISMO Version Identifier.
MISMO Reference Model and MISMO Message Identifiers for this Architecture are of the form 3.CG.CS.B and 3.A.CG.CS respectively. Changes in semantics (definitions or structure) WILL be signaled by a change in MIMSO Reference Model and MISMO Message Identifiers. |
| 3.4 |
The Namespace prefix for MISMO Schemas MUST be “mismo:”. |
| 3.5 |
The W3C XML Schema Namespace prefix used for published MISMO Schemas SHOULD be “xsd:” |
| 3.6 |
The W3C-defined namespace MUST be used for the “xml:” namespace.
The namespace www.w3.org/XML/1998/namespace is bound by definition to the prefix “xml:” by the W3C. Unlike all other XML namespaces, both the name and prefix are specified and reserved. |
| 3.7 |
MISMO Schemas MUST NOT use namespace defaulting.
A “targetNamespace” MUST be used so that the definitions and declarations are qualified. This is to prevent the “chameleon effect”, which is when a schema without a target namespace is included in a schema with a targetNamespace, and the target-namespace-less schema assumes the target namespaces of the including schema.
The target namespace MUST be the same as the schema namespace. For example, the root element of all Version 3.x messages published in a non-null namespace would look like:
<xsd:schema targetNamespace=“http://mismo.org/residential/2009/schemas”
xmlns=“http://mismo.org/residential/2009/schemas” elementFormDefault=“qualified”
attributeFormDefault=“qualified” xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
xmlns:mismo=“http://mismo.org/residential/2009/schemas”
xmlns:dsig=“http://www.w3.org/2000/09/xmldsig#”> |
| 3.8 |
Namespaces MUST NOT use relative URIs.
The use of relative URIs in namespace declarations has been deprecated by the W3C. |
| 3.9 |
Namespaces MUST NOT use xml:base.
The XML Base specification defines an attribute “xml:base” in the XML namespace that is intended to affect the “base” to be used for relative URI processing described in RFC 2396. Since relative URIs have been deprecated by the W3C, use of xml:base is similarly prohibited. |
| 3.10 |
MISMO Schemas MUST NOT contain superfluous re-declarations of namespace or “xml:” attributes.
The appearance of duplicate attribute names on an element is forbidden by XML 1.0. As the MISMO XML Profile allows only the definition of namespaces on the one element, (i.e., the root node) duplicate namespaces are not allowed. |
The following information is a summary of the two issues MISMO considered when making the decision(s) regarding namespaces. It is included to provide historical background and support for the content of this MEG.
C1.2 Interoperability Examples
Example 1: Migration of XSLT to process upwardly compatible XML Documents.
If two upwardly compatible versions are in the same namespace then a single XSLT transform can process all the instance documents in the family, assuming there is no desire to use any added data.
If each release is in its own namespace then a new XSLT transform is needed for each version.
This issue is not particular to XSLT. Namespace aware libraries in both Java and .NET would require different code for different namespaces.
Example 2: Two different schemas in the same name space need an external method of resolving which schema to use.
An instance document can declare the location of its schema with or without a name space. The document producer can provide an appropriate URI for the schema depending upon which version was used to produce the XML document. In general it is recommended to use a locally controlled method to map namespace to appropriate schema/DTD. Methods like OASIS Catalog provide that for example.
If the instance XML document or the header information of the transport mechanism has a URI to identify the schema then the OASIS catalog, or other mechanism, can be used to resolve the URI to a local copy.
If there is only a namespace reference and a MISMO Version Identifier then some custom technique will be needed on the receiving system. It would take these two facts to resolve a locally controlled URI for the appropriate schema.
Both the Java and .NET environments provide assistance in resolving URI values.
C1.3 Resolving the conflict between example 1 and 2.
Example 1 points toward one namespace per upwardly compatible series of standards releases. Example 2 points towards a name space per release. The group of MISMO participants that reviewed these issues concluded that they would rather solve the URI resolution issue than the multiple objects problem.
Metadata
| Element |
Description |
| Title |
MEG0003 Namespaces |
| Identifier |
MEG0003 |
| Category |
Baseline Meg0003 XML Namespaces Profile |
| Publisher |
MISMO |
| Copyright |
©2008 MISMO. All Rights Reserved. |
M1.1 Release History
| Date |
Release |
Comments |
| 07/20/2006 |
0.01 |
Initial Version |
| 07/27/2006 |
0.02 |
Revision to incorporate change to simultaneous republication of all transactions. |
| 09/13/2006 |
0.03 |
Modifications to accommodate discussions at the third trimester 2006 at Ft Collins CO, Hosted by Kroll Factual Data. Added sections 3.11, 3.12 and 3.13 |
| 09/30/2006 |
0.04 |
Formatting and add reference to TAG finding on name space versioning. |
| 10/05/2006 |
0.05 (R1) |
Update version, add known issues and corrections |
| 10/12/2006 |
0.06 |
Updated section 3.5 to address known issue 3.a. Also added text near the end of section 2 to clarify instance file impact of namespace prefixes. |
| 11/02/2006 |
1.0 |
Approved - Ready for Publish |
| 12/17/2008 |
1.1 |
Global changes to MEG format. Changed “Disclaimer” tab title to “Terms” and updated content. |
| 1/5/2009 |
1.2 |
Updated content to be inline with current D3 decisions. |
| 1/6/2009 |
1.3 |
Typographical and formatting changes. Also updated namespace strings and identifier information. |
| 1/11/2009 |
.14 |
Made changes based on 1/8 D3 call. NOTE: also reverted version number to reflect correct status under new review/approval path. |
| 1/12/2009 |
1.0 |
Governance approval |
M1.2 Known Issues or Omissions
| Name |
Organization |
Contact Details |
| MISMO Staff |
MISMO |
info@mismo.org |
M1.4 References
Comments
None.
Terms
T1. Terms and Conditions
T1.1 Disclaimer
MISMO accepts no liability for the accuracy, adequacy, or completeness of the information contained in this MISMO Engineering Guideline (MEG).
T1.2 Reproduction
Material in this MEG may be reproduced free of charge without obtaining explicit permission from MISMO, provided that the source is acknowledged, the document title given, and the material used in context.
T1.3 Copyright
©2008 MISMO. All material in this MEG is the property of MISMO. All Rights Reserved