S
Steve George
Hi, I have a scenario where I have a master schema that defines a
number of complex and simple types. I then have a number of other
schemas (with different namespaces) where I would like to reuse some
of these master complex and simple types. This I believe will assist
me in transforming between the master schema and the other smaller
schemas that contain a subset of the elements in the master schema.
I understand that I can import an xsd file that contains all of the
complex and simple types I want to reuse, and refer to them via their
namespace alias. As it happens though, because there are lots of these
complex and simple types in the master schema, I have split them
across multiple files merely to organise them. All files have the same
namespace though since the types contained within them are all part of
the master schema.
If I then try to define one of my other schemas with a different
namespace, I'm having difficulty importing multiple xsd files where
they all have the same name space. For instance, I've tried this:
<xsd:import schemaLocation="master_types1.xsd"
namespace="http://www.myschema.com/"/>
<xsd:import schemaLocation="master_types2.xsd"
namespace="http://www.myschema.com"/>
<xsd:import schemaLocation="master_types3.xsd"
namespace="http://www.myschema.com"/>
and coupled it with a single alias in the xsd:schema tag like this:
xmlns:master="http://www.myschema.com"
When my editor tries to validate the types of elements in my second
schema, for any element whose type exists in the master_types2.xsd or
master_types3.xsd it reports that it cannot resolve the type. Its like
the editor will only recognise one import statement for a given
namespace. It then seems to ignore any other import statements that
define the same namespace.
I guess I could resolve this by defining a 'common_types.xsd' that
simply 'includes' all of the files that contain my complex and simple
types, and then import only the common_types.xsd file, but this feels
like a workaround rather than being the correct way to structure my
xsd files.
Any advice much appreciated. Thanks.
Steve.
number of complex and simple types. I then have a number of other
schemas (with different namespaces) where I would like to reuse some
of these master complex and simple types. This I believe will assist
me in transforming between the master schema and the other smaller
schemas that contain a subset of the elements in the master schema.
I understand that I can import an xsd file that contains all of the
complex and simple types I want to reuse, and refer to them via their
namespace alias. As it happens though, because there are lots of these
complex and simple types in the master schema, I have split them
across multiple files merely to organise them. All files have the same
namespace though since the types contained within them are all part of
the master schema.
If I then try to define one of my other schemas with a different
namespace, I'm having difficulty importing multiple xsd files where
they all have the same name space. For instance, I've tried this:
<xsd:import schemaLocation="master_types1.xsd"
namespace="http://www.myschema.com/"/>
<xsd:import schemaLocation="master_types2.xsd"
namespace="http://www.myschema.com"/>
<xsd:import schemaLocation="master_types3.xsd"
namespace="http://www.myschema.com"/>
and coupled it with a single alias in the xsd:schema tag like this:
xmlns:master="http://www.myschema.com"
When my editor tries to validate the types of elements in my second
schema, for any element whose type exists in the master_types2.xsd or
master_types3.xsd it reports that it cannot resolve the type. Its like
the editor will only recognise one import statement for a given
namespace. It then seems to ignore any other import statements that
define the same namespace.
I guess I could resolve this by defining a 'common_types.xsd' that
simply 'includes' all of the files that contain my complex and simple
types, and then import only the common_types.xsd file, but this feels
like a workaround rather than being the correct way to structure my
xsd files.
Any advice much appreciated. Thanks.
Steve.