I tried removing the ds, xlink, and soap namespace
declarations. XML Authority reports lots of errors on the resulting schema, one
of which is:
Imported schema must have a target namespace in order to
'import'. Namespace information will be lost.
Therefore, I don't think it is OK to remove these
I didn't realize that the schema in http://schemas.xmlsoap.org/soap/envelope namespace
is for SOAP 1.2. In that case, it would be inappropriate for us to use the
schema directly available from that location. Still, I think section 2.3.2 is
technically incorrect, because it currently states:
The SOAP namespace:
resolves to a schema conforming to an early Working Draft
version of the W3C XML Schema specification, specifically identified by the
I agree we need all of the current import statements and namespace
declarations. Namespaces must be declared where they are used (in both
instance and schema documents). Schema documents need the import as well
for reasons documented in the excerpt below.
About the only thing that might be removable is the ds, xlink and soap
namespace declarations in our schema document. (I haven't tried this
removal with existing XML parsers but it might work since those namespaces are
referenced only within attribute content.) It wouldn't be a worthwhile
change at this stage because the declarations in question certainly do no harm
and have no effect on users of the schema.
On your original question: The new schema you mention is for SOAP 1.2 which
remains under development. While SOAP 1.1 is only a Note, it is at least
more stable than a draft Recommendation. Further, switching from SOAP
1.1 to 1.2 would be a rather large change to our document.
Arvola Chan wrote:
David: I don't think the import constructs in msg-header-2_0 are redundant.
Here is an excerpt from http://www.w3.org/TR/xmlschema-0/#import:The report schema, report.xsd,
makes use of the simple type xipo:SKU that is defined in another
schema, and in another target namespace. Recall that we used include so
that the schema in ipo.xsd could make
use of definitions and declarations from address.xsd.
We cannot use include
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. Hence, the include
element does not identify a namespace (although it does require a schemaLocation).
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
SKU 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 import
element to identify SKU's target namespace, http://www.example.com/IPO, and
we associate the namespace with the prefix 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 declarations.
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
I agree that we should keep our version of envelope.xsd on
our web site to allow existing implementations to continue to refer to
From: David Fischer <firstname.lastname@example.org>
To: Arvola Chan <email@example.com>; firstname.lastname@example.org
Date: Tuesday, February 12, 2002
RE: [ebxml-msg] Issue 73: http://schemas.xmlsoap.org/soap/envelopenamespace
Arvola,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
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, i.e., http://www.w3.org/2001/XMLSchema
(instead of http://www.w3.org/1999/XMLSchema
previously). Therefore, there is no longer a need for us to provide our
own version of envelope.xsd. I suggest the
ebMS spec be updated accordingly, in section 2.3.2, the introduction in
Appendix A, the schema posted at http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd,
as well as in all of the examples. Regards,-Arvola