Any of you who have written W3C XML Schemas will know that there are two mechanisms for sharing Schema definitions across files. <xs:include> is used like traditional programming language “include” statements, so that you can split a single large file up into separate, modular pieces. <xs:import> is used when you need to use Schema definitions from a different XML namespace, as W3C XML Schema doesn't allow a single Schema file to contain definitions for more than a single namespace.
Now, I have been involved with a number of standards groups, and I know that the what comes out of a standards effort depends on what requirements and scope have been given to the group. So while I wish that the W3C's XML Schema Working Group had been able to give us something better for Schema definition sharing than just import/include statements, I don't think the working group ever had a scope that would have allowed them, for example, to define a standard for repositories of Schema definitions, and for how to compose and generate Schemas flexibly from the definitions in one or more repositories. Instead, we have import and include, which are about the best you can do when your scope only allows you to deal with schemas, and not with higher-level concepts like repositories.
As a general rule, almost any solution will work if the problem is simple enough and straightforward enough and isn't particularly demanding in any way. Many uses of import/include statements are simple enough that these built-in mechanisms do what is needed. However, there are other situations where import/include don't work as you would hope, and I thought I would mention a couple that I have run into in practice.
For example, I already mentioned that <xs:include> is commonly used allow a large single Schema to be broken up into modular pieces. If you get the modularity right, you should just be able to include just the pieces that you need into your Schema. However, what happens if you are importing Schemas from a separate namespace using <xs:import>? I was working with some generated Schemas today (i.e. not hand-written) which had multiple <xs:import> statements for different Schema files which share the same namespace. Two Schema validators told me that some of the definitions I was importing weren't available, and I wondered if I had some kind of subtle namespace error. It turned out, and this was news to me, that using <xs:import> more than once for the same namespace is a grey area for W3C XML Schemas, and a typical behaviour for Schema validators is to process the first import for a particular namespace, but to ignore any subsequent imports for the same namespace. This means you end up with missing definitions and invalid Schemas.
So, it seems that the only safe way to import (as opposed to include) definitions from multiple Schemas in a particular namespace is to define an extra Schema for that namespace, one which does nothing but include all of the other Schemas in that namespace. You can then import that “include only” into other Schemas and work around the aforementioned “one import only” issue. However, you lose the ability have true modularity of Schema definitions in multiple namespaces if you are effectively forced to import all Schemas from a particular namespace, rather than just the ones you actually need.
I wonder how many Schema generation tools actually make provision for this issue. I don't know of any, but I guess it's yet another reason why people often give up on using multiple namespaces, and just use a single namespace wherever possible.
Another issue I've had in the past (and I don't know if things are better or worse now) is when the Schema files are distributed over a hierarchy of directories/folders, rather than all being in the same directory/folder. When you import/include a Schema, you specify a location, and “good practice” would often be to use relative paths for this, not absolute paths, so that you can move the Schemas to a new directory/folder without breaking the path relationships between the Schemas.
However, sometimes relative paths fail to work correctly when you have the Schemas spread among directories (especially is the directories are not at the same level, but some are sub-directories of others). In a file system, it's usually quite straightforward to work with relative paths. However, XML is designed to work on the Web as well, and URLs don't have to obey the same rules that file systems (usually) do about relative paths, especially because Web servers are free to do clever things like URL re-writing on the fly. For this reason, and particularly if your relative paths contain “..” (parent directory reference), you may find that your Schema validator errs on the side of caution and does not make assumptions about whether two relative paths that it has seen actually compute to produce the the same absolute path.
Why is that an issue? Sometimes many files include the same Schema (perhaps a Schema of common definitions), and so when the validator is processing includes (and includes within includes, etc.), the validator may find the same file included more than one. If the validator can't determine whether the relative paths referenced the same file, it may assume that it has loaded two different files containing the same definitions, rather than having loaded the same file twice. Since you aren't allowed to have two definitions of the same thing, you get Schema validation errors, which can be hard to get rid of, but may magically disappear if you put all of the Schemas into a single directory (with the relative paths adjusted appropriately).
It's not the Schema imports and includes are bad, they are often just fine, but they aren't the complete story, they are only a half-way step to being able to share definitions between Schemas in a completely flexible way. I can only hope the W3C (or even some other group) takes this further at some stage, e.g. by defining a Schema repository and generation specification. Yes, yes, maybe I should do something about this myself, but it may have to wait until I'm finished with some of the various standards groups I'm already working with (life is short, consultants need to do billable hours too, etc.).