The report schema,
makes use of the simple type
xipo:SKU that is defined in another
schema, and in another target namespace. Recall that we used
that the schema in
ipo.xsd could make
use of definitions and declarations from
We cannot use
here because it can only pull in definitions and declarations from a schema
whose target namespace is the same as the including schema's target namespace.
element does not identify a namespace (although it does require a
The import mechanism that we describe in this section is an important
mechanism that enables schema components from different target namespaces to
be used together, and hence enables the schema validation of instance content
defined across multiple namespaces.
To import the type
and use it in the report schema, we identify the namespace in which
SKU is defined, and associate that namespace with a prefix for
use in the report schema. Concretely, we use the
element to identify
SKU's target namespace,
http://www.example.com/IPO, and we associate the namespace with
xipo using a standard namespace declaration. The
SKU, defined in the namespace
http://www.example.com/IPO, may then be referenced as
xipo:SKU in any of the report schema's definitions and
Currently, the default namespace is
xmlns="http://www.w3.org/2001/XMLSchema". If we make soap the default
namespace, then we will have to start qualifying types from the above
namespace explicitly, e.g., xsd:nonNegativeInteger, instead of
nonNegativeInteger. I don't see why we should make such change now.
I agree that we should keep our version of envelope.xsd on our web site to
allow existing implementations to continue to refer to it.