OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: table of content reshuffle


Title: table of content reshuffle

Here is a proposal for purely editorial but sweeping changes - mostly a "Table of Content" remodeling,
consolidating observations from Iwasa and I in some previous exchange with Iwasa, in case you missed these:

1. Section 2 "Messaging Model" is covering much more than just
the messaging model. Reduce it so it only contains current 2.1. and 2.2.
- Also split 2.1 in two: "Assumptions" (new 2.1 with first paragraphs)
and "Message Reply Patterns" (new 2.2)
- rename "Groups of Messages  and Message Identity" into:
"Message Identification and Grouping" (new 2.3), to emphasize message identity.

So Section 2 would become:

- Section 2 "Messaging Model"
- 2.1 "Assumptions"
- 2.2 "Message Reply Patterns"
- 2.3 "Message Identification and Grouping"


2. Introduce New Section 3: "Reliability Features" covering former 2.3 to 2.6:
This section introduces the reliability features, their logic, yet not at the
level of detail of message headers, which are only introduced in next
section "Message Format" (formerly Section 3).
- Message Persistnce (2.7) is removed.
- section 3.3 on Ordering will consolidate previous 2.5 and 2.6 (seq numbers)
- formerly section 2.8 (Group Termination) is moved down after "Message Format"
section, because it relies on header data that is only introduced in Message Format.

So Section 3 would become:

- Section 3 "Reliability Features"
- 3.1 "Guaranteed Delivery"
- 3.2 "Duplicate Elimination"
- 3.3 "Message Ordering"


3. "Message Format" (formerly sec 3) section becomes Section 4.
- We could move the "Fault Processing" section (formerly sec 4)
under "Message Format", as it really describes fault codes, a part of message format.
In fact, Fault Processing has a single subsection "Fault Codes for ...", so
just make this subsection a sub of "Message Format". So former Section 4 disappears.

So new Section 4 becomes:

- Section 4 "Message Format"
(same sub-sections as before, introduce header structure and semantics, and
how RM agreement items map to header elements/attributes)
- 4.6 "Fault Codes for Reliable Messaging Failures"


4. Introduce a new section, which we could name "Operational Aspects and Semantics",
with former 2.9 (WSDL ops) 2.10 (Poll Reply patterns) 2.11 (attachments).
- We could move in it the current "Group Termination and State Removal", renamed
"Message Group Life Cycle".
- These sections rely on header data introduced in Message Format.
- These sections are really about detailed operational semantics,
closer to  deployment concerns.

So Section 5 becomes:

- Section 5 "Operational Aspects and Semantics"
- 5.1 "Message Group Life Cycle"
- 5.1.1 "Group Termination Rules"
- 5.2 "WSDL Operation Type"
- 5.3 "Poll Reply Pattern Semantics and Usage"
- 5.4 "Attachments"

---------------- proposed overall structure:

Section 1 "Introduction"
...
Section 2 "Messaging Model"
- 2.1 "Assumptions"
- 2.2 "Message Reply Patterns"
- 2.3 "Message Identification and Grouping"
Section 3 "Reliability Features"
- 3.1 "Guaranteed Delivery"
- 3.2 "Duplicate Elimination"
- 3.3 "Message Ordering"
Section 4 "Message Format"
 ...
- 4.6 "Fault Codes for Reliable Messaging Failures"
Section 5 "Operational Aspects and Semantics"
- 5.1 "Message Group Life Cycle"
- 5.1.1 "Group Termination Rules"
- 5.2 "WSDL Operation Type"
- 5.3 "Poll Reply Pattern Semantics and Usage"
- 5.4 "Attachments"
Section 6 "HTTP Binding"
...




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]