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

["Duane Nickull" <dnickull@adobe.com>]

Richard:

The concept (as I "must understand" it) is that when the initial XML
parse of the SOAP instance occurs, for every element flagged as mU, the
receiving SOAP application must have some form of handler written and
registered to take care of it.  Note that this is only an illustrative
example since there are many methods an implementer can employ to take
care of the element.  The element values are irrelevant since they are
dealt with by the handler and other than rudimentary parsing checks
(such a data type validation), the parser does not really care.  Parsing
= reading only.  If they are out of bounds, the handler will throw a
towel in the air.

Parsing = reading but does not imply agreement with the content.  When
you read this email, you can understand it and note that the English is
grammatically correct, but you do not have to agree with the authors
POV.

Duane

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Adobe Developer Program - http://developer.adobe.com/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----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