[ebxml-msg] Issue 74: foreign namespace attributes

I agree with David's addition of the anyAttribute construct 
back to the headerExtension.grp and bodyExtension.grp attribute groups in 
"Version 2.0 rev A". The namespace however is not quite correct. It should be 
changed from

 

<anyAttribute 
namespace="http://www.w3.org/2000/10/XMLSchema-instance" 
processContents="lax"/>

 

to

 

<anyAttribute 
namespace="http://www.w3.org/2001/XMLSchema-instance" 
processContents="lax"/>

 

to correspond to the W3C Recommended verson of XML Schema. 
I think the main purpose of this wildcard attribute is to 
allow for the specification of an xsi:schemaLocation attribute for the foreign 
namespace qualified wildcard elements that occur under a given ebXML SOAP Header 
or SOAP Body extension element.

 

I am not sure about the <anyAttribute 
processContents="lax"> definition under the Reference element. It is an 
attempt to make the schema consistent with section 3.2.1 (Reference Element) 
section in the spec which states: "Any other namespace-qualified attribute MAY 
be present. A Receiving MSH MAY choose to ignore any foreign namespace 
attributes other than those defined above."

 

Such wildcard attributes without any namespace restriction has 
never been used in any previous version of the ebMS schema. I think the 
statement in section 3.2.1 allowing such wildcard attributes constitutes a 
change that may have never been agreed by the team.

 

I am attaching some communications I have had with David 
earlier.

 

-Arvola

 

From: "Arvola Chan" <>

To: "David Fischer" <>

Date: Mon, 11 Feb 2002 12:14:12 -0800

David:

 

This is directly related to issue #74 raised by Doug. Why 
don't we discuss this on the  
alias and try to get it resolved at next week's CC?

 

Regards,

-Arvola

  
-----Original Message-----
From: 
  David Fischer <>
To: 
  Arvola Chan <>
Date: 
  Monday, February 11, 2002 9:57 AM
Subject: RE: Foreign NS 
  qualified Attributes.

  
Oh, are you saying this limits the wildcard attributes to (nil, type, 
  schemaLocation, noNamespaceSchemaLocation) rather than any namespace qualified 
  attribute?  I didn't understand that.  Yes, I see why this might be 
  too limiting.  

  
 

  
This is certainly not what was meant by the bullet in 3.2.1.  
  As I remember the original intent, we wanted the 
  spec to be fully extensible on both elements and attributes.  
  

  
 

  
Regards,

  
 

  
David.

  
    
-----Original Message-----
From: Arvola Chan 
    [mailto:]
Sent: Monday, February 11, 2002 10:43 
    AM
To: David Fischer
Subject: Re: Foreign NS qualified 
    Attributes.

    
David:

    
 

    
The Manifest element was defined as follows in 
    draft-msg-header-00.xsd:

    
 

    
 <!-- MANIFEST -->
 <element 
    name="Manifest">
  <complexType>
   <sequence>
    <element 
    ref="tns:Reference" 
    maxOccurs="unbounded"/>
    <any 
    namespace="##other" processContents="lax" minOccurs="0" 
    maxOccurs="unbounded"/>
   </sequence>
   <attribute 
    ref="tns:id"/>
   <attribute 
    ref="tns:version"/>
   <anyAttribute 
    namespace="http://www.w3.org/2001/XMLSchema-instance" 
    processContents="lax"/>
  </complexType>
 </element>

    
 

    
Please notice that the namespace for the wildcard 
    attribute was restricted to "http://www.w3.org/2001/XMLSchema-instance" 
    

    
 

    
It seems that the original intent (not explicitly stated 
    in the specification) for having this attribute in the Reference element is 
    because there is a wildcard sub-element under Reference and there is a 
    potential need to specify a value for the xsi:schemaLocation attribute for 
    the corresponding namespace. The same pattern also applied to the 
    MessageHeader element originally, which had both a wildcard sub-element and 
    a wildcard attribute restricted to the "http://www.w3.org/2001/XMLSchema-instance" 
    namespace. (The current spec does not mention about any wildcard attribute 
    being allowed under MessageHeader.)

    
 

    
Doug pointed out that the xsi:schemaLocation could be set 
    at the soap:Envelope, soap:Header levels. However, I now think that there 
    may be a restriction that xsi:schemaLocation can occur only once in each of 
    soap:Envelope and soap:Header (because attributes cannot be repeating), and 
    we already have to specify xsi:schemaLocation for the soap and eb 
    namespaces.

    
 

    
Therefore, I think the correct fix may be to both update 
    the spec and the schema to indicate that wherever we have a wildcard 
    sub-element, there should also be an accompanying wildcard attribute with 
    namespace restricted to "http://www.w3.org/2001/XMLSchema-instance". 
    The sole purpose of the wildcard attribute is to specify a schema location 
    for the corresponding wildcard element. In practice, I think the recipient 
    of an ebXML message that contain foreign namespaces should attempt to 
    resolve those namespaces even if no schema location hints are provided in 
    the message itself. Therefore, it is not clear to me if the schema hints are 
    absolutely necessary.

    
 

    
Regards,

    
-Arvola

    
      
-----Original Message-----
From: 
      David Fischer <>
To: 
      Arvola Chan <>
Date: 
      Monday, February 11, 2002 6:50 AM
Subject: RE: Foreign NS 
      qualified Attributes.

      
Arvola,

      
 

      
We made what might be a significant change to 
      some implementations, without consulting the group.  We're not 
      supposed to make technical changes without approval.  From the 
      beginning, we said this spec was supposed to be extensible, which is why 
      this was in the spec.  We allow ##wildcards are every element, why 
      not attributes?

      
 

      
The only place I find where this is a 
      *problem* in the spec is the last bullet in section 3.2.1 which says 
      "Any other namespace-qualified attribute MAY be 
      present".  Doug and Chris' have requested for a 
      namespace attribute on Schema -- we could add anyAttribute there as 
      well.

      
 

      
If we make changes to the spec before 
      submitting to OASIS, we should add anyAttribute to the headerExtension.grp 
      and bodyExtension.grp so this will align with v1.0.  We should also 
      add anyAttribute to Reference and, if the group approves, to 
      the Schema element.

      
 

      
Regards,

      
 

      
David.

      
        
-----Original Message-----
From: Arvola Chan 
        [mailto:]
Sent: Sunday, February 10, 2002 5:01 
        PM
To: David Fischer
Subject: Re: Foreign NS 
        qualified Attributes.

        
David:

        
 

        
I did a search in the Draft Version 2.0 
        Message Service Specification but could not find any mention of wildcard 
        attributes being allowed in the MessageHeader and the Manifest sections. 
        In other words, I don't see any significant discrepancy between the 
        specification in the schema. I did notice there is one occurrence of 
        xsi:schemaLocation in one of the examples related to the 
        eb:MessageHeader element on line 1924 which would not pass schema 
        validation. In that particular example, the same xsi:schemaLocation 
        attribute is also indicated on the SOAP:Header element so it is really 
        unnecessary to have the same attribute set on the 
        child eb:MessageHeader element. 

        
 

        
If you have determined that there is a real 
        need for the wildcard attributes under MessageHeader and Manifest, then 
        I think an issue should be added to the issue list and discussed during 
        the issue resolution process.

        
 

        
Regards,

        
-Arvola

        
          
----- Original Message ----- 

          
From: 
          David Fischer 

          
To: Arvola Chan 
          

          
Sent: Friday, February 08, 2002 
          10:04 PM

          
Subject: RE: Foreign NS qualified 
          Attributes.

          

          
We shouldn't have made this kind of a 
          change without group approval.  I'm not sure what to do about it 
          now.

          
 

          
David.

          
            
-----Original Message-----
From: Arvola Chan 
            [mailto:]
Sent: Friday, February 08, 2002 
            5:01 PM
To: David Fischer
Subject: Re: Foreign 
            NS qualified Attributes.

            
David:

            
 

            
The removal of the two "anyAttribute" lines from 
            the schema was recommended by Doug. Please see

            
 

            
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00324.html

            
 

            
This change was incorporated into 
            draft-msg-header-05.xsd.

            
 

            
Here are the relevant excerpts from Doug's 
            message:

            
 

            

            
Including wildcard attributes 
            in the Schema Instance namespace on the Manifest 
            and MessageHeader would seem to support adding the 
            xsi:schemaLocation attribute to those elements.  However, we've 
            defined 9 SOAP extensions and the other 7 don't allow these 
            attributes.  The simplest thing would be to recommend use of 
            xsi:schemaLocation only on the parent soap:Envelope, soap:Header and 
            soap:Body elements.  Next in complication would be allowing 
            xsi:schemaLocation only for all our extension elements and 
            documenting that option in the specification.  I'd prefer to 
            limit future extensibility to the wildcard elements we've 
            already documented and should add to a few more elements. 
            
            
            
64 d [Remove the two 
            anyAttribute cases.] 

            
 

            
-Arvola

            
              
-----Original 
              Message-----
From: David Fischer <>
To: 
              Arvola Chan <>
Date: 
              Friday, February 08, 2002 12:04 PM
Subject: Foreign 
              NS qualified Attributes.

              
I notice that all the anyAttribute lines have been removed 
              from the schema?  When and why did that happen?  The 
              spec still allows this on the Manifest element.  We used to 
              allow it on every element?

              
 

              
What happened?  Do you remember?

              
 

              
Regards,

              
 

              
David.