Duane:
The reason why the ebxml-msg TC has to define its own namespace is because
the ebXML message header elements are defined as extensions to the SOAP
Header and SOAP body elements. SOAP requires extension elements to be
namespace qualified.
The schemaLocation attributes in the schema and in instance documents only
serve as hints. Schema processors are not required to use these hints. The
application that invokes a schema processor can direct the latter not to
dereference the value specified for the schemaLocation attribute and instead
use some cached version of the schema.
The following is an excerpt from http://www.w3.org/TR/xmlschema-0/
"
5.6 schemaLocation
XML Schema uses the schemaLocation and xsi:schemaLocation attributes in
three circumstances.
1. In an instance document, the attribute xsi:schemaLocation provides hints
from the author to a processor regarding the location of schema documents.
The author warrants that these schema documents are relevant to checking the
validity of the document content, on a namespace by namespace basis. For
example, we can indicate the location of the Report schema to a processor of
the Quarterly Report:
Using schemaLocation in the Quarterly Report, 4Q99html.xml
<purchaseReport
xmlns="http://www.example.com/Report"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.example.com/Report
http://www.example.com/Report.xsd"
period="P3M" periodEnding="1999-12-31">
<!-- etc. -->
</purchaseReport>
The schemaLocation attribute contains pairs of values: The first member of
each pair is the namespace for which the second member is the hint
describing where to find to an appropriate schema document. The presence of
these hints does not require the processor to obtain or use the cited schema
documents, and the processor is free to use other schemas obtained by any
suitable means, or to use no schema at all.
A schema is not required to have a namespace (see Section 3.4) and so there
is a noNamespaceSchemaLocation attribute which is used to provide hints for
the locations of schema documents that do not have target namespaces.
2. In a schema, the include element has a required schemaLocation attribute,
and it contains a URI reference which must identify a schema document. The
effect is to compose a final effective schema by merging the declarations
and definitions of the including and the included schemas. For example, in
Section 4, the type definitions of Address, USAddress, UKAddress, USState
(along with their attribute and local element declarations) from address.xsd
were added to the element declarations of purchaseOrder and comment, and the
type definitions of PurchaseOrderType, Items and SKU (along with their
attribute and local element declarations) from ipo.xsd to create a single
schema.
3. Also in a schema, the import element has optional namespace and
schemaLocation attributes. If present, the schemaLocation attribute is
understood in a way which parallels the interpretation of xsi:schemaLocation
in (1). Specifically, it provides a hint from the author to a processor
regarding the location of a schema document that the author warrants
supplies the required components for the namespace identified by the
namespace attribute. To import components that are not in any target
namespace, the import element is used without a namespace attribute (and
with or without a schemaLocation attribute). References to components
imported in this manner are unqualified.
Note that the schemaLocation is only a hint and some processors and
applications will have reasons to not use it. For example, an HTML editor
may have a built-in HTML schema.
"
-Arvola