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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

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


Subject: Re: [ws-tx] Issue 108 - Other Editorial Issues Surrounding AI#0057 Reviewfor RFC 2119 (I#097), Submission 2


> mm2: Andrew, the original comment regarding Section 2 was more focused
> on the point at which it is addressed in the specification. As you
> acknowledged, normative language occurs later in the specification in
> Sections 4.1 (with the referenced change) and 4.2. Yet, in Section 2
> we've not defined what application messages are involved in a
> transaction. Perhaps we should consider:
> 
>     Proposed change: The Atomic Transaction coordination context MUST
>     flow on all application messages involved with the transaction.
>     Change proposed in Line 145: Change "must" to "MUST".
> 
>     Revision: The Atomic Transaction coordination context flows on all
>     application messages involved with the transaction as specified in
>     Section 4.
>     This supports the detailed requirements found in Section 4.1 and
>     4.2, and as proposed in I#105. It also alleviates redundancy of
>     specified requirements.

This revision would leave us with section 4 - AT Policy Assertion - as 
being the only place in the specification where we make a normative 
statement about how a transaction is flowed in an application message 
which, in my opinion, is less clear than it could be. This is what issue 
106 intends to address; note that the proposal is no longer to change must 
to MUST - it's been superceded by the proposal describe in i106. 

The rationale behind i106 is that the details of how a transaction is 
flowed in an application message is of interest to all implemeters of the 
specification, not just those that intend to make use of and consume the 
policy assertion. Therefore I believe that it should be described in a 
generally applicable section of the specification, e.g. section 2.

Regards,
Andy


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