OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] Issue 73:http://schemas.xmlsoap.org/soap/envelopenamespace

I don't think the import constructs in msg-header-2_0 are redundant. Here is an excerpt from

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.



-----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

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.
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Tuesday, February 12, 2002 1:21 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Issue 73: http://schemas.xmlsoap.org/soap/envelope namespace

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC