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>