Next in thread → Next in month →

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

From
David Fischer <>
Date
2002-02-12T23:42:47+00:00
ID
Thread
RE: [ebxml-msg] Issue 73:http://schemas.xmlsoap.org/soap/envelopenamespace
OK, thanks for checking.

 

David.

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Tuesday, February 12, 2002 3:36 
  PM
To: David Fischer; 
  
Subject: Re: [ebxml-msg] Issue 73: 
  http://schemas.xmlsoap.org/soap/envelopenamespace

  
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
Next in thread → Next in month →