Supporting Namespaces in Meta-Models That Have No Direct Namespace Support
Original Publication Date: 2004-Jan-21
Included in the Prior Art Database: 2004-Jan-21
Disclosed is a methodology for mapping XML Schema Models with target namespace information into meta-models that have no direct namespace support.
Supporting Namespaces in Meta -Models That Have No Direct Namespace Support
In large enterprises there is a need for intercommunication between a variety of platforms, operating systems, and applications. The information that needs to be exchanged can be described in two dimensions: a) The structure of the information, typically described using languages such as XML Schema, C and COBOL, and b) The physical representation (how the data is transferred between applications) of the information, typically described using binary or tagged strings. The Message Broker tool of the Websphere Business Integration family of products uses a single meta-model that can be used to capture both the logical and physical meta-models for a specific message. The logical meta-model defines the logical structure of the message while the physical meta-model defines the various alternative wire formats of the message.
A broker runtime is used to process the information that is exchanged between the different applications. The meta-model can be deployed into a variety of runtimes that may or may not provide support for namespaces. If the user needs to deploy to a runtime that has no namespace support then the logical meta-model cannot contain any namespace information. This document describes a technique for converting a schema having target namespace information into a schema with no target namespace and carrying the namespace information as the physical rendering of the logical model elements.
The key idea behind our invention is to exploit the flexible nature of the message meta-model and to treat namespace specific information as the physical properties of the logical model instead of the logical information. As illustrated in Figure 1, we separate the namespace information from the logical model information and store this under the physical and logical meta-models respectively.
When a runtime that is namespace aware creates and sends an XML instance document to a runtime that is NOT namespace aware, the latter treats the namespace prefix associated with the element as the inherent part of the element name received on the wire. It validates the instance document using wire format information from physical model and determines the logical name of the elements. Since the conversion of schema with target namespace to schema with no target namespace (described further in the document), had set the physical rendering of the element name to namespace prefix followed by ":" and actual name of the element as defined in the schema, the net outcome is that the message tree built in memory has the same structural contents whether it was parsed by a namespace or non-namespace aware parser and can be manipulated in an identical manner. This allows applications running in namespace or non-namespace aware runtime to exchange and validate instance documents.
physical model (xml wire format)
schema with namespaces