Re: [ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace

From
Arvola Chan <>
Date
2002-02-12T22:31:12+00:00
ID
01b701c1b414$77da37e0$
Thread
Re: [ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
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 <>
To:  
  <>
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 <> 
      
To: Arvola Chan <>;  
      <> 
      
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. 
      
        
-----Original Message----- 
From: Arvola Chan [mailto:] 
        
Sent: Tuesday, February 12, 
        2002 1:21 PM 
To:  
        
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. Regards,-Arvola