+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.
>
