I don't understand why anyAttribute under Reference has namespace="##any"
and anyAttribute under other ebXML SOAP Header and Body extensions have
namespace="http://www.w3.org/2001/XMLSchema-instance".
Why don't we use namespace="##other" everywhere, just like in
http://schemas.xmlsoap.org/soap/envelope/
-Arvola
-----Original Message-----
From: Christopher Ferris <>
To: David Fischer <>
Cc: Arvola Chan <>;
<>
Date: Wednesday, February 13, 2002 1:05 PM
Subject: Re: [ebxml-msg] Issue 74: foreign namespace attributes
>+1
>
>David Fischer wrote:
>
>> Arvola,
>>
>>
>>
>> Allowing foreign attributes is not a change. The statement/bullet "Any
>> other namespace-qualified attribute MAY be present" is in v1.0 under the
>> Reference element, section 8.11.3. The v1.0 schema does not support
>> this although in v1.0, the schema is non-normative (as it should be in
>> v2.0 -- I have never seen a specification where code examples took
>> precedence over the words???). In v1.0, the schema is an example.
>>
>>
>>
>> You solution of:
>>
>>
>>
>> <anyAttribute namespace="##any" processContents="lax"/>
>>
>>
>>
>> is probably correct.
>>
>>
>>
>> Regards,
>>
>>
>>
>> David.
>>
>> -----Original Message-----
>> From: Arvola Chan [mailto:]
>> Sent: Tuesday, February 12, 2002 7:26 PM
>> To:
>> Subject: [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
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>>
>> Re: Foreign NS qualified Attributes.
>> From:
>>
>> "Arvola Chan" <>
>> Date:
>>
>> Tue, 12 Feb 2002 10:04:06 -0600
>> To:
>>
>> "David Fischer" <>
>>
>>
>> David:
>>
>>
>>
>> Sorry for the delayed response. I was away from the office yesterday
>> afternoon.
>>
>>
>>
>> Instead of what we used to have in draft-msg-header-00.xsd:
>>
>>
>>
>> <anyAttribute namespace="http://www.w3.org/2001/XMLSchema-instance"
>> processContents="lax"/>
>>
>>
>>
>> we can use something like
>>
>>
>>
>> <anyAttribute namespace="##any" processContents="lax"/>
>>
>>
>>
>> Please note the following from http://www.w3.org/TR/xmlschema-0:
>>
>>
>>
>> In contrast to an any <http://www.w3.org/TR/xmlschema-0/#element-any>
>> element, anyAttribute
>> <http://www.w3.org/TR/xmlschema-0/#element-anyAttribute> cannot
>> constrain the number of attributes that may appear in an element.
>>
>>
>>
>> Regards,
>>
>> -Arvola
>>
>> -----Original Message-----
>> From: David Fischer <
>> <mailto:>>
>> To: Arvola Chan < <mailto:>>
>> Date: Monday, February 11, 2002 2:35 PM
>> Subject: RE: Foreign NS qualified Attributes.
>>
>> How do we add anyAttribute to the Reference element as specified in
>> 3.2.1?
>>
>>
>>
>> David.
>>
>> -----Original Message-----
>> From: Arvola Chan [mailto:]
>> Sent: Monday, February 11, 2002 2:14 PM
>> To: David Fischer
>> Subject: Re: Foreign NS qualified Attributes.
>>
>> David:
>>
>>
>>
>> This is directly related to issue #74 raised by Doug. Why don't
>> we discuss this on the
>> <mailto:> alias and try to get it
>> resolved at next week's CC?
>>
>>
>>
>> Regards,
>>
>> -Arvola
>>
>> -----Original Message-----
>> From: David Fischer <
>> <mailto:>>
>> To: Arvola Chan < <mailto:>>
>> 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 <
>> <mailto:>>
>> To: Arvola Chan <
>> <mailto:>>
>> 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
>> <mailto:>
>>
>> To: Arvola Chan <mailto:>
>>
>> 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
>> <
>> <mailto:>>
>> To: Arvola Chan <
>> <mailto:>>
>> 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.
>>
>
>
