RE: [ws-rx] RE: Issue 115 - mU attribute

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

Let me answer with a completely contrived example.

If I extend the CreateSequence message with
<dmn:MessageNumbersAreInDecreasingOrder> boolean element and flag it
wsrm:mU then the following scenarios should apply:

1.) If the RMD does not implement the logic that recognizes the
<dmn:MessageNumbersAreInDecreasingOrder> extension element, it should
return a wsrm:MustUnderStandFault.

2.) If the RMD implements the logic that recognizes the
<tns:MessageNumbersAreInDecreasingOrder> element but chooses *not* to
process message numbers in decreasing order it should return a Create
Sequence Refused fault. This is part of the definition of the
"decreasing message numbers extension". Alternately whoever defined this
extension *could* have specified that, if the RMD didn't agree to
processing message numbers in decreasing order, it should create a
"normal" Sequence and extend the resulting CreateSequenceResponse
message with the <dmn:OhNoImNot> element. The rules around what MUST,
SHOULD, MAY, etc. happen between entities that all implement the
extension are defined by the extension itself.

I don't really see an inherent compulsory aspect to this attribute. The
semantics of the extension it is used to flag may or may not have
compulsory components to them, but that seems, to me, a different
manner. The wsrm:mU attribute is just saying "if you don't know 'what I
mean'/'how to interpret' this extension return a wsrm:MU fault".

- gp

> -----Original Message-----
> From: Richard Salz [mailto:rsalz@us.ibm.com] 
> Sent: Thursday, May 25, 2006 8:00 PM
> To: Gilbert Pilz
> Cc: wsrx
> Subject: Re: [ws-rx] RE: Issue 115 - mU attribute
> 
> I think wsrm:mustUnderstand is too confusing.
> 
> Let's suppose I define a new header
>         <tns:AllNumbersAreInOctal/>
> 
> If I add soap:mU attribute, as I understand the SOAP 
> processing model, it's still possible for the application to 
> see "10" and not know it should be 8 -- soap mU just say the 
> soap layer has to recognize it, and imposes no requirement on 
> the application layer.
> 
> Now, if instead I add wsrm:mU, then the RM code must know 
> that 10 really means 8, and if it doesn't agree to do that, 
> the recipient has to fault.
> 
> Do I have that right?  If so, this is perhaps subtly, but 
> nonetheless fundamentally different.  You are really 
> proposing wsrm:DoOrDie, right?
> 
> Hope this clarifies the discussion.  As for myself, looking 
> at it that way, I'd say that if you want to change the 
> semantics of WSRM then you should be in an alternate 
> universe, er namespace, and that DoOrDie seems too "icky"
> 
>         /r$
> 
> --
> SOA Appliances
> Application Integration Middleware
> 
>