Title: RE: [wsrm] Rel 82
John: inline.
-----Original Message-----
From: John Fuller [mailto:]
Sent: Tuesday, October 14, 2003 4:25 PM
To: ''
Subject: [wsrm] Rel 82
82
The original document was difficult to work from as far as how to deal
with conceivably different
values for the optional group removeAfter attribute for messages in the
same group.
For example, most recent message's value could take precedence, or the
maximum or minimum value
could win.
<JD> There is a more general issue that you raise here: when the semantics
of some value (header element or attribute) is about the entire group,
not just about the individual message that carries it, we only
need -in theory- to pick these values from the first message of a group.
So a bold way to address the possible "contradiction" issue across messages
of the same group is to pick the values of the first message(s) of the group,
and ignore what the other messages say about it.
We have the case also with "MessageOrder" element: if it is in the 1st
message of a group, I'd say the entire group is ordered... regardless
of whether it is or not in following messages.
Any "dynamic" readjustment or exception within a group, would be
confusing and make implemenations more complex.
Rel 57 clarified that the most recent timeout takes
precedence, though I don't believe
it's in the original specification.
<JD> I think the spec did not restrict what kind of ExpiryTime
each messages of a same (ordered) group, should have/not, so we
are allowed to consider any possible sequence of ExpiryTime values.
(note this is a message-level value , not group-level, so several
messages could not conflict with each other here).
We take the "earliest" of all ExpiryTime, which may come frm any message
in the broken sequence...
Maximum idle time also seems legitimate, but it would be helpful to
clarify which parameters
take precedence over which when in conflict, and explicitly that the
last group values
overwrite previous assumptions, and if null values indicate default to
service-level parameters
or default to previous parameters in the group if any?
<JD>, yes, we need to state some general rule for group-level values.
I'd propose that unless we accept the trouble of allowing group-level
parameters to change mid-way or have exceptions
(e.g. removeAfter be re-adjusted during a group),
the initial value is the good one.
I think it would be good to have service-level default
parameters/policies for cases where
the header doesn't contain the parameters.
<JD> Agree some "configuration" values/parameters should have a standalone
existence, as it would be contrived to put them in headers just to be able to
talk about them... Such parameters don't have to be described as RMP parameters
(implementation level), but rather as part of the RM agreement between two parties.
Even so, I believe we can keep referring to them in an "abstract" way
(no need to come-up with an XML schema)
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
