[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] question about QoS
David, This won't work. If you don't use DuplicateElimination, and the CPA says to always eliminate duplicates, then the message will always be in error! There can be a conflict with the CPA on the parameters that can be perMessage, and we agreed that an error is sent in case of conflict. That is the way it works at present. The value of this error is that it would catch accidental misconfiguration of the MSH (such as, operator error in changing the wrong property sheet value and so on.) You may say that it is "redundant" to have something in the message when there is a CPA that governs it. If that really bothered you, then I think you would consider getting rid of the parameter in the message all together. But, I think the consensus was that some parameters were to be governed by the message. While I think there are good reasons to question making some of these parameters flexible, in the interest of getting the 1.1 version stable, let us just accept what has been decided. Then, to avoid all the talk about "override," (and the subsequent jettison of the point of having an agreement governing a business process collaboration) we decided to split the difference and have a way to have the CPA reflect either fixed or flexible values. Why do we have to revisit this decision endlessly? Dale Moberg -----Original Message----- From: David Fischer [mailto:david@drummondgroup.com] Sent: Sunday, December 09, 2001 9:38 AM To: Arvola Chan; Dale Moberg; Christopher Ferris; Cliff Collins Cc: ebxml-msg Subject: RE: [ebxml-msg] question about QoS Actually, I would prefer that <eb:DuplicateElimination/> only appear in one case, that is if the CPA says perMessage and the Sender wants this to be true. Otherwise, we have a potential conflict. I think this is what Arvola described as Chris' understanding. David. -----Original Message----- From: Arvola Chan [mailto:arvola@tibco.com] Sent: Friday, December 07, 2001 10:49 AM To: Dale Moberg; Christopher Ferris; Cliff Collins Cc: ebxml-msg Subject: Re: [ebxml-msg] question about QoS I get the impression that Dale's interpretation is slightly different from Chris'. If the duplicateElimination attribute is set to "always" in the CPA, and no DuplicateElimination element is present in the message header, Dale's interpretation would return an "inconsistent" error whereas Chris' interpretation would say that the receiver should eliminate duplicates as indicated in the CPA. My assumption has been that those message characteristics that can be made to have "per message" semantics always have to be explicitly stated in the message header (and they have to be consistent with the CPA) before they take effect. Therefore, I vote for Dale's interpretation. -Arvola -----Original Message----- From: Dale Moberg <dmoberg@cyclonecommerce.com> To: Christopher Ferris <chris.ferris@sun.com>; Cliff Collins <collinsc@sybase.com> Cc: ebxml-msg <ebxml-msg@lists.oasis-open.org> Date: Friday, December 07, 2001 8:05 AM Subject: RE: [ebxml-msg] question about QoS I assume this means, more long windedly, that: (If a CPA is being used,) If the value of the CPA's attribute for "duplicateElimination" is either "always" or "never," any value included in the header shall conform to this agreement or else an ebMS error shall be sent. If the QOS is omitted, the semantics of omission shall conform with the CPA agreement. (I assume an omission conforms with the "never" value.) Dale Moberg -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@sun.com] Sent: Friday, December 07, 2001 5:45 AM To: Cliff Collins Cc: ebxml-msg Subject: Re: [ebxml-msg] question about QoS Cliff, No, it would default to whatever value was reflected in the CPA. Having this in the message is only necessary when the CPA says "perMessage". Cheers, Chris Cliff Collins wrote: > So the email going around about Qos being required in the message is > wrong? It can be absent which would default DuplicateElimination to false? > > > > Thanks. > > -----Original Message----- > From: Doug Bunting [mailto:dougb62@yahoo.com] > Sent: Thursday, December 06, 2001 3:41 PM > To: ebxml-msg > Subject: Re: [ebxml-msg] question about QoS > > Cliff, > > > > In the current schema, we have a three-state value called > QualityOfService@duplicateElimination > <mailto:QualityOfService@duplicateElimination>. The attribute is > required within the element these days. So, the three states are 1) > QualityOfService absent in the MessageHeader 2) > duplicateElimination='false' and 3) duplicateElimination='true'. It > used to be worse -- duplicateElimination was optional, adding > another state without defined meaning. > > > > I don't really like three-state "Boolean" values but think we've > improved this enough for now. At least, the default value for the > attribute (used when the containing element isn't in an instance) is > well-defined and consistent in the specification. > > > > On your second point, you're fighting a battle that's already been > lost. A similar suggestion came up and was rejected earlier. > > > > thanx, > > doug > > > > ----- Original Message ----- > From: Cliff Collins <mailto:collinsc@sybase.com> > > To: ebxml-msg <mailto:ebxml-msg@lists.oasis-open.org> > > Sent: Thursday, 06 December 2001 15:27 > > Subject: [ebxml-msg] question about QoS > > > I have 2 questions/comments about the recent talk regarding > QualifyOfService and DuplicationElimination. > > > > 1. It was said that QoS with DuplicationElimination must be present > in every message. Does this include MSH types messages where > DuplicationElimination would never be true? i.e. > ping/ping/StatusRequest/StatusResponse/Acknowledgements must also > include QoS with DuplicationElimination =false. > > > > 2. Since QualifyOfService only contains one attribute > (DuplicationElimination) why not rename the "QualifyOfService" > element to "DuplicationElimination"? This would also mean that > question #1 above wouldn't make sense. This element would only > appear when "DuplicationElimination" is true. This would be more in > line with other elements like "AckRequested" and "SyncReply". IMO > leaving QualifyOfService the way it is seems inconsistent with the > rest of the spec. > > > > > > Cliff Collins > > mailto:collinsc@sybase.com > > URL: http://www.skyweyr.com/cliff > > (510)922-5204 > > > ---------------------------------------------------------------- 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