[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Issue 74: foreign namespace attributes
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 <chris.ferris@sun.com> To: David Fischer <david@drummondgroup.com> Cc: Arvola Chan <arvola@tibco.com>; ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> 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: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