The things every IT Professional should know about XML Schema design Part 2

Last time I wrote about the namespace design and its versioning issues. Today I will write about the difference between the <xsd:import> and the <xsd:include> statement.


Import versus include

There is a major difference between the include and the import statement originating from the design of the XML schema.

The <xsd:import> statement was introduced to use components from a schema file with its own namespace in the current schema. Using the <xsd:import> statement in coorporation with xmlns:abc= attribute in the xsd:schema statement referencing the schema the components of the imported schema can be used by using the namespace token.

The <xsd:include> statement was introduced to combine multiple files which all have the same namespace. Its original design was to combine the files of one namespace which spanned multiple physical files. Splitting the namespace into multiple physical files can have advantages like performance advanages or clustering functional elements together in a file for better understanding.
One of the characteristics of the include sttement is that it hides the namespace. The components of the included schema can be used as if they are part of the targetNamespace. This can introduce problems when elements have the same name. And when using include the context of the original namespace is lost. So when having a namespace design which has a functional meaning this is an absolute no-go area.
 
Summarized
The Pros of import
- Explicit usage of components of other namesapces, which enables impact analysis for changes.
- Clear usage of components even when using the same name twice.
- Requires strict design of the schema

The Pros of include
- Enables splitting of files

The cons of import
- None

The cons of include
- Namespace is lost
- The includes are incorporated in a client side component into one phisical file. This deminishes the pro of the include in the usage scenari of XML schema in services.

Combining include and import
There are scenarios when a combination of the import and include statement are applicable. It is recommended when having large XML schema files to split them. This can be done by either splitting the files and only using thos files with the include statement or by reconsidering the namespace design. When the latter choice is chosen the need for include is absolutely zero.

The things every IT Professional should know about XML Schema design Part 1

In my every day work I see a lot of XML stuff going by. Usually the quality or schema design of the validating XML Schema is not good enough to be constructive and reusable. The thing I started to wonder about was why?


There are some basic rules a good XML Schema complies to. It all starts with thinking and documenting the general schema design pattern (the five are Russian Doll, Venetian Blind, Salami Slice, Garden of Eden and Bologna). It is a simple choice to make, and there is lots of information available on the net with the pros and cons for each choice. My personal favorite is the Garden of Eden and I recommend this for everyone considering building a corporate, domain or canonical datamodel based on XML technologies.


The second thing to really think about is namespace design. Good namespace design is practical and will work for you in understanding the domain you are talking about. Some guidelines I use when making my namespace design:
1) Make it urn based, not protocol based;

• Not OK: http://www.free-your-energy.nl/
• OK: urn:nl:free-your-energy:schema:data

Rationale: Protocol based suggest that the XML Schema can be found at that address, while this is usually not the case. URN based namespaces are more expressive.
2) Use the major version in your namespace, so no dates but major versions;

• Not OK: urn:nl:free-your-energy:schema:data
• Not OK: urn:nl:free-your-energy:schema:data:20090918
• OK: urn:nl:free-your-energy:schema:data:1

Rationale: Major version in namespace will guarantee compliancy througout this major version. Anything that doesn't use a version will result in problems when making a new version or release. Dates don't tell anything.
The upcoming weeks I will elaborate in detail on XML Schema design with more tips.