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
From: "Arvola Chan" <>
To: "David Fischer" <>
Date: Tue, 12 Feb 2002 10:04:06 -0600
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 element,
anyAttribute
cannot constrain the number of attributes that may appear in an
element.
Regards,
-Arvola
-----Original Message-----
From:
David Fischer <>
To:
Arvola Chan <>
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
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.
