|
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
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.
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>
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
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.
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 -----
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.
David:
The removal of the two "anyAttribute" lines from
the schema was recommended by Doug. Please see
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
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.
|