A Best Practice for mixed namespace schema

I am working on a long post on use of the MISMO Extension model.  The reason organizations want to use the extension model it to incorporate proprietary information with the MISMO information.  To do that takes  a best practice on Namespace use.

A Namespace is a unique string prefix to every named object in a schema. The string is made unique by incorporating the domain name of the the organization that created the vocabulary.

In the MISMO schema you will see that the namespace string is " http://www.mismo.org/residential/2009/schemas".  This namespace is in the form of a URL. Typically there is no page at this location.  In a namespace the string is used as a URI.

The root schema will use the MISMO namespace twice:

• xmlns="http://www.mismo.org/residential/2009/schemas"  -- Marks everything inside the schema as belonging to the MISMO namespace
•   targetNamespace="http://www.mismo.org/residential/2009/schemas" -- A way for the schema to signal to outside schema or systems what namespace this schema is defining.

 MISMO uses a small root schema file to get things started. In the root schema you will find entries like <xsd:include schemaLocation="MISMODataTypesB288.xsd"/> .This identifies the MISMO pieces needed to define the entire model.

There is also the need to tell the schema where to find the files for other namespaces, as in  <xsd:import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlink.xsd"/>




These xsd:import and xsd:include point to other schema files.  Those files may in turn have xsd:import and xsd:include pointing to still other files.


There is an inconsistent implementation of how different platforms treat the xsd:import found in child schema files. Some implementation the namespace resolver gets lost.  The cause for the difference is in a vague description in the W3C XML Schema specifications. Different organizations interpreted it differently. 


Therefore, the  best practice is to also place the xsd:import in root schema file as well as in the places where it is actually used.  This technique gives the namespace file resolver a heads up about what is coming. When it gets to the xsd:import in the child file it notices that it already has that definition set and moves on.