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>