|
Oops, that's a separate issue and I'd agree it's real. Could you
send the appropriate XML fragment along to the list?
thanx,
doug
Arvola Chan wrote:
Doug: 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 namespace declarations. 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:http://schemas.xmlsoap.org/soap/envelope/resolves
to a schema conforming to an early Working Draft version of the W3C XML
Schema specification, specifically identified by the following URI:http://www.w3.org/1999/XMLSchema" Thanks,-Arvola
-----Original
Message-----
From: Doug Bunting <dougb62@yahoo.com>
To: ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>
Date: Tuesday, February 12,
2002 2:04 PM
Subject: Re: [ebxml-msg] Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
Arvola,
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.
thanx,
doug
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
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.
Regards,
-Arvola
-----Original
Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>;
ebxml-msg@lists.oasis-open.org
<ebxml-msg@lists.oasis-open.org>
Date: Tuesday, February 12,
2002 11:59 AM
Subject: 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 it.Regards,David.
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, 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
|