I don't think the import constructs in msg-header-2_0 are
redundant. Here is an excerpt from
The report schema,
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
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. Hence,
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
use it in the report schema, we identify the namespace in which
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 the
xipo using a standard namespace declaration. The simple type
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.
I was updating as specified below and I think I see another problem.
Why do we declare the SOAP: namespace at the top of the ...2_0.xsd AND
import the schema AND declare the SOAP:namespace on all of our
examples? It seems like the import is redundant? Either that or we
do not need to namespace qualify the SOAP elements. I would prefer the
remove the import.
Also, even though we may not need the ...envelope.xsd any more, we
should NOT delete it since some implementations are already pointing to
The statement starting on line 618 (section 2.3.2
xsi:schemaLocation attribute) in the revised spec from David yesterday is no
long true. I followed the above URL and found that the SOAP envelope
namespace has been updated to use the W3C Recommended version of XML Schema,
(instead of http://www.w3.org/1999/XMLSchema previously).
Therefore, there is no longer a need for us to provide our own version of