[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rel YY
Tom Rutt wrote:
Sunil Kunisetty wrote:I never bought into this argument. We have to look/read all RM Headers>Tom Rutt wrote:
>
>
>
>>Sunil Kunisetty wrote:
>>
>>
>>
>>> Jacques,
>>>
>>> Oracle will be supporting this proposal. However, I prefer that
>>>SequenceNumber
>>> be Optional rather than mandatory as you indicated in (P2). I
>>>understand that it will
>>> be difficult for schema validation, but I believe it will be much
>>>simpler and efficient
>>> for implementations.
>>>
>>> So essentially we should categorize all RM into 3 different
>>>categories based on
>>> the elements used in RM Headers:
>>>
>>> 1) Grouped and Ordered Messages: Group Id + Seq No. +
>>>Message Order
>>>
>>>Same Group Id, Different Seq No.
>>>
>>> 2) Grouped and Un-Ordered Messages: Group Id + Seq No.
>>>
>>>Same Group Id, Different Seq No.
>>>
>>> 3) Discrete & Independent RM Messages: Group Id
>>>
>>> We could then use the SequenceNumber sub-element has the toggle
>>>switch to
>>> distinguish Grouped Un-ordered with Discrete & Independent messages.
>>>
>>>
>>>
>>We could then use the presence of the SequenceNumber's status attribute
>>(an enum with first, more, and last) as the trigger for ordered delivery
>>of the sequenced group.
>>
>>
>
> You mean instead of the proposed MessageOrder element in Request ( I guess
> that's what you meant below by saying rm-orderRequested).
>
> I prefer MessageOrder (or what ever is the name) sub-element as the
> triggering mechanism rather than the value of some attribute or sub-element
> to distinguish the category.
>
> Infact, that's the reason I preferred SequenceNumber as optional and non
> existence of SequenceNumber to distinguish as an independent message
> rather than having it and value be 0.
>
>
>
It simplifies processing if all things having to do with the use of
sequence number occur
together in the message. That way you do not have to look at another
header to determine
if the ordered delivery is requred.
My main concern of categorizing based on the element or attribute
value is that 1) it can easily be mis-represented and
more error prone
(what if SeqNo value is zero and status attribute exists)
2) we have to
send extra elements/attributes for some un-necessary cases (such
as
Seq No with value '0' for discrete & independent RM msg.
case).
Btw, MessageOrder was put back by Jacques revised proposal. I
was just saying I'm okay with it. Anyway, this is not a big issue
compared to having Seq No. for un-ordered cases which most
people (now) seem to be agreeing. Other ones are minor and
we can decide based on majority's opinion. I can go either way
with a preference to be based on existence of elements rather
than their values.
The point is our existing syntax covers the semantics well. Why add
another element
to another header (messageOrder element). We already moved the status
attrbute to sequenceNumber, why move it back?Tom Rutt
>
>
>>Thus the sequence Number would be optional with an optional status
>>attribute.
>>
>>This does not change our existing syntax, only the semantics.
>>
>>
>
> Yes, it will change the syntax, but it won't be that complex. Infact, we used
> to have it (MessageOrder) before.
>
>
>
>>This way we would not need a separate rm-orderRequested header subelement.
>>
>>Tom Rutt
>>
>>
>>
>>>An
>>> implementation could then use 3 different Hash Tables to store the
>>>IDs, thus
>>> making DE much more efficient.
>>>
>>>
>>>
>>----------------------------------------------------
>>Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com
>>Tel: +1 732 801 5744 Fax: +1 732 774 5133
>>
>>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.
>>
>>
>
>
>--
----------------------------------------------------
Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]