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:]
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.
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
To: ebxml-msg
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:
URL: http://www.skyweyr.com/cliff
(510)922-5204
