[ebxml-msg] Issue 74: foreign namespace attributes

ebxml-msg message

Subject: [ebxml-msg] Issue 74: foreign namespace attributes

From: Arvola Chan <arvola@tibco.com>

To: ebxml-msg@lists.oasis-open.org

Date: Tue, 12 Feb 2002 17:25:50 -0800

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

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" <arvola@tibco.com>
To: "David Fischer" <david@drummondgroup.com>
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 ebxml-msg@lists.oasis-open.org alias and try to get it resolved at next week's CC?

Regards,

-Arvola

-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>
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:arvola@tibco.com]
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:


<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 <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>
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:arvola@tibco.com]
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:arvola@tibco.com]
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 <david@drummondgroup.com>
To: Arvola Chan <arvola@tibco.com>
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.