Tool for merging .xsd's

[Jan Eliasen]

Hi

Does anyone know of a tool that will tahe four xsd's, where the first one
imports the other three and merge them into one .xsd?

Thanks.

 

[FC]

Hi

Does anyone know of a tool that will tahe four xsd's, where the first one
imports the other three and merge them into one .xsd?

Thanks.

I suppose you mean "includes" rather than "imports".
You can do it with a XSL transformation, first you need to expand the source
document recursively, then you need to consolidate it by removing any
duplicate type definitions and replacing named external types with anonymous
types, otherwise the document will not validate. You should try to follow
the same rules that the parser is using for setting priority among multiple
versions of the same type definition, otherwise your final schema will not
work in the same way as the original one.
I made something of the kind some time ago because I needed to streamline
the schema definition in a single file.

Bye,
Flavio

 

[Jan Eliasen]

I suppose you mean "includes" rather than "imports".

Well, no. I have an .xsd that imports three others. Is it impossible to
make one .xsd from that?

 

[FC]

Well, no. I have an .xsd that imports three others. Is it impossible to
make one .xsd from that?

Well, I guess this is not trivial because you probably have a different
target namespace for each imported schema and a schema definition can
contain just one target namespace.
The advantage of xsd:import lies indeed in the possibility of importing a
type definition from a different target namespace, something that is
impossible to do with xsd:include.

Let's make an example to clarify the matter:

Suppose you are creating an english vocabulary. "English" is the "target
namespace".
As you can quickly find out yourself, it's much easier to handle the task by
subdiving the big book into smaller chunks, probably naming them after
alphabet's letters. So you create 26 smaller documents whose target
namespace is still "english". Then you create a main document with "english"
target namespace, made up of 26 <xsd:include> statements referencing each
"letter" section. If you were to collapse this document into a single one,
it'd be sufficient to retrieve each external document and put one after
another.

Now suppose that in your english vocabulary there is the word "spaghetti",
that comes from a different target namespace, namely "italian". For your own
mental safety you obvsiously don't want to include the whole italian
vocabulary just for referencing one word. Instead you "xsd:import" the
italian namespace and then you reference the word spaghetti in the english
vocabulary, leaving the reader (the parser) with the task of validating the
word against its definition in the italian vocabulary, if he wants to, just
to be sure that the spelling is correct and you are not writing "spagetti"
or "spagheti".
So, how can you streamline this document without importing the whole italian
vocabulary?
The answer is: open the italian vocabulary, extract the definition and
translate it into english (that is change its target namespace).
But a schema definition may have dependencies, i.e. local subtypes, which
make the process more complex, as it happens with foreign words that cannot
be explained exactly without referencing other foreign words.
For instance "spaghetti" as per Webster's dictionary is "PASTA made in thin
solid strings".
Which means that the translation of "spaghetti" is meaningless unless you
also translate "pasta".
As far as each translated word is a new entry, the process works smoothly,
but what if you come across a foreign word that spells the same as an
english word but has got a different meaning?
Unlike vocabularies, schema types have got one and only one definition, so
it becomes impossible to import the new type, unless you rename the type and
update all its occurrences.
Pesky job, isn't it?

I hope is now clear why xsd:import is much more difficult to deal with than
xsd:include.

Bye,
Flavio