[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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:arvola@tibco.com] > Sent: Tuesday, February 12, 2002 7:26 PM > To: ebxml-msg@lists.oasis-open.org > 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" <arvola@tibco.com> > Date: > > Tue, 12 Feb 2002 10:04:06 -0600 > To: > > "David Fischer" <david@drummondgroup.com> > > > 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 <david@drummondgroup.com > <mailto:david@drummondgroup.com>> > To: Arvola Chan <arvola@tibco.com <mailto:arvola@tibco.com>> > 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:arvola@tibco.com] > 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 ebxml-msg@lists.oasis-open.org > <mailto: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 > <mailto:david@drummondgroup.com>> > To: Arvola Chan <arvola@tibco.com <mailto: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: > > > > <!-- 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 <david@drummondgroup.com > <mailto:david@drummondgroup.com>> > To: Arvola Chan <arvola@tibco.com > <mailto: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 > <mailto:david@drummondgroup.com> > > To: Arvola Chan <mailto:arvola@tibco.com> > > 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 > <mailto:david@drummondgroup.com>> > To: Arvola Chan <arvola@tibco.com > <mailto: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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC