[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd)
I agree with Arvola's reading here, but I don't think the text is badly ambiguous. Whether you have "perMessage or "always" for DuplicateElimination, the sending MSH needs to include the DuplicateElimination element, and that is what the text says. The additional words do help to clarify the situation, though, and I think they would be helpful to implementers. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Monday, January 14, 2002 12:52 PM To: Doug Bunting; ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd) Doug: I don't quite agree with your statement: >At the moment, a Receiving MSH has the >option (a poor word meaning interoperability problem) of checking the CPA or >always not doing duplicate elimination when DuplicateElimination is not >present. A Sending MSH has the option of including or leaving out the >DuplicateElimination element when the CPA says "always". Our document >should specify one approach and avoid the two MSH having to come to yet >another agreement. At least, I don't think that is our intent. My assumption has been that the receiving MSH must always check that the incoming message is consistent with the CPA (or configuration parameters). If the CPA indicates "never", the DuplicateElimination element must not be present. If the CPA indicates "always", the DuplicateElimination element must be present. This behavior is consistent with our treatment of the AckRequested element. Perhaps Section 7.4.1 is a little bit ambiguous: "The DuplicateElimination element MUST be used by the From Party MSH to indicate whether the Receiving MSH MUST eliminate duplicates (see section 7.6 for Reliable Messaging behaviors). If the value of duplicateElimination in the CPA is never, DuplicateElimination MUST NOT be present." My interpretation of the the first "MUST" in the above statement is that the sender must include a DuplicateElimination element if its desires the elimination of duplicates. It will be helpful if we also explicitly state that this is permissible only if the duplicateElimination attribute in the CPA is either "always" or "perMessage". Conversely, it would be inconsistent for the sending MSH to include a DuplicateElimination element if the duplicateElimination attribute in the CPA is "never". Regards, -Arvola -----Original Message----- From: Doug Bunting <dougb62@yahoo.com> To: ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org> Date: Monday, January 14, 2002 11:09 AM Subject: Re: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd) Arvola, You've described the distinction between the CPA and the message format quite well. Unfortunately, the document remains unclear in a closely related area: It doesn't tell anyone what should be in a message if the CPA says duplicateElimination="always". Ignoring the confusion between describing the semantics of a core module in the Additional Features part of the document, section 7.4.1 doesn't include Dan's good words about how the CPA and message instance should be compared. Of course, these words should be changed to reflect our later decision avoiding "idempotent" in the document. Dan's message may be found at http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00195.html With this addition, we'd describe how both duplicateElimination="never" (already in the document) and duplicateElimination="always" drive the Sending MSH. Both would result in direct control of the DuplicateEliminiation element in the message and result in Inconsistent errors when that control is ignored. At the moment, a Receiving MSH has the option (a poor word meaning interoperability problem) of checking the CPA or always not doing duplicate elimination when DuplicateElimination is not present. A Sending MSH has the option of including or leaving out the DuplicateElimination element when the CPA says "always". Our document should specify one approach and avoid the two MSH having to come to yet another agreement. thanx, doug ----- Original Message ----- From: "Arvola Chan" <arvola@tibco.com> To: "Ahmed Zahid" <zahid.ahmed@commerceone.com>; "David Fischer" <david@drummondgroup.com> Cc: <ebxml-msg@lists.oasis-open.org> Sent: Friday, 11 January 2002 19:27 Subject: Re: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd) In the CPA, there is a duplicateElimination attribute that can take on the values "never", "always", or "perMessage". If it is "never", that means the two parties have agreed that duplication elimination should never be done. In that case, the ebXML message MUST not include a DuplicateElimination element. If it is "always", that means the two parties have agreed that duplication should always be done. In that case, the ebXML message MUST always carry a DuplicateElimination element. If it is "perMessage", then the application may determine on a per message (actually per conversation) basis whether duplicate elimination should be carried out. The presence of the DuplicateElimination element indicates that duplicate elimination is desired. There is no need for any additional attribute within that element. Regards, -Arvola ----- Original Message ----- From: "Ahmed, Zahid" <zahid.ahmed@commerceone.com> To: "'Arvola Chan'" <arvola@tibco.com>; "David Fischer" <david@drummondgroup.com> Cc: <ebxml-msg@lists.oasis-open.org> Sent: Friday, January 11, 2002 7:12 PM Subject: RE: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd) > Another question: > > In the msg-header-2_0.xsd schema, DuplicateElimination > is defined as: > > <element name="DuplicateElimination"> > </element> > > > However, there is no duplicateElimination attribute > defined for it to take the values: "perMessage" or > "always". > > Amy I missing something? > > E.g., is this really an omisison in the latest > schema. if yes, I suggest following modification of > the msg-header-2_0.xsd schema: > > <element name="DuplicateElimination"> > <simpleType> > <restriction base="string"> > <enumeration value="perMessage"/> > <enumeration value="always"/> > </restriction> > </simpleType> > </element> > > > > thanks, > Zahid > > Zahid Ahmed > Commerce Security Architect > Commerce One, Inc. > 408/517-3903 > > -----Original Message----- > From: Arvola Chan [mailto:arvola@tibco.com] > Sent: Monday, January 07, 2002 8:11 AM > To: David Fischer; ian.c.jones@bt.com > Cc: ebxml-msg@lists.oasis-open.org > Subject: [ebxml-msg] Fw: Please post (msg-header-2_0.xsd) > > > David and Ian: > > Should I ask Jeff to create a > > http://www.oasis-open.org/committees/ebxml-msg/doc > > directory as the home directory for the spec document? I can ask him for > the passwords for the schema and doc directories so that we can maintain > the files in these directories directly. > > Regards, > -Arvola > > -----Original Message----- > From: Jeffrey Lomas <jeff.lomas@oasis-open.org> > To: Arvola Chan <arvola@tibco.com> > Date: Monday, January 07, 2002 6:46 AM > Subject: Re: Please post (msg-header-2_0.xsd) > > > >Arvola, > >I posted the document you requested. While on the server I noticed that > the > >ebxml-msg TC is set up to maintain its committee pages itself. This means > >that whoever has the user name and password to the ebxml-msg ftp directory > >can post documents to the schema directory. Let me know if I can ever be > of > >assistance. > > > >Regards, > >Jeffrey Lomas > >OASIS > > > >Arvola Chan wrote: > > > >> Jeffrey: > >> > >> Please post the attached file to > >> > >> http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd > >> > >> Thanks, > >> -Arvola > >> > ----------------------------------------------------------------------- > - > >> Name: msg-header-2_0.xsd > >> msg-header-2_0.xsd Type: unspecified type > (application/octet-stream) > >> Encoding: quoted-printable > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC