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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: RE: Issue 115 mU RM attribute - proposal 2


After the discussion we had on this issue on yesterday’s call [1] I propose we close this with no action.

 

I don’t believe we need granularity of control over extensibility points as the SOAP processing model suffices.

 

1 Apr. 20 TC call minutes: http://lists.oasis-open.org/archives/ws-rx/200604/msg00064.html

 

Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog: http://spaces.msn.com/mrgoodner/


From: David Orchard [mailto:dorchard@bea.com]
Sent: Tuesday, April 18, 2006 4:37 PM
To: Marc Goodner; Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: Issue 115 mU RM attribute questions

 

Your question/assertion/point/statement about relating soap envelopes to mustUnderstand doesn't make sense to me.  Could you rephrase somehow?  Perhaps you are suggesting that soap:mustUnderstand could be used within the SOAP body or on descendents of SOAP headers?  I don't recall the discussion on XMLP about this.  I didn't see any issue raised on XMLP that suggested it.  I know that have been many various side discussions about that or an xml:mustUnderstand attribute over many years.  My favourite in Sean's proposal last year for xml:mU http://lists.xml.org/archives/xml-dev/200504/msg00000.html

 

Extensibility in RM is different than other WS protocols because RM has different use cases than other protocols.  Of course, it's hard to compare use cases because there seems to be reticence in writing down use cases so we could compare them.   You are asserting there is a commonality to extensibility and versioning across the WS protocol specs, but I can't find any spec or document that details this.  I'd call that commonality an architecture, but we don't seem to have one of those WS commonality or architecture docs. 

 

We do have a Web architecture doc with information on extensibility and versioning http://www.w3.org/TR/webarch/#ext-version .  An extract is

"Good practice: Unknown extensions

A specification SHOULD specify agent behavior in the face of unrecognized extensions.

Two strategies have emerged as being particularly useful:

  1. "Must ignore": The agent ignores any content it does not recognize.
  2. "Must understand": The agent treats unrecognized markup as an error condition.

A powerful design approach is for the language to allow either form of extension, but to distinguish explicitly between them in the syntax."

WS-RX is doing all of what Web Arch suggests for the ext/vers Good practices, and then we are proposing the "powerful design approach" to distinguish between them in syntax. 

 

I guess we can look at other WS- specs and see what's been done.  WS-Security does not need a "mustUnderstand" because it specified that all extensions must be understood, so an mU isn't need.  There was a proposal for a wsse:mU FWIW.  Does that mean that WS-Security has "changed the common semantics of extensibility points"?   I think they've taken a look at their use cases and made a decision.  My reading of WS-SecureConversation is they are taking the same approach.  Security is often considered "special" when doing things like versioning and extensibility. 

 

Moving along, We believe WS-Addressing EPRs should have a wsa:mU, and we were one of the minority opinion dissenters on that.  We seriously pondered voting no on WS-A on that issue, but decided that a potential multi-month slip in WS-A would be detrimental to WS-RX, etc.  Maybe we should have voted otherwise in the hope that we would have "common semantics".   WS-A also has many headers, but they decided that the headers were "shallow" enough that an extension author could simply create a new header and mark it as mU.  The point that WS-A defines many headers for each message is crucial.

 

There is a key difference between WS-A and WS-RX in that WS-A defines many headers for each message, so adding one more header with an s:mU isn't terribly onerous.  However, WS-RX defines only one header for within a typical message.  Using s:mU and adding another header to do a mU extension seems more onerous in this case.  Going from one header to 2 headers adds a lot of complexity.  This is an obvious possibility and one that I'm sure will be proposed. 

 

WSDL has wsdl:required attributes to specify required behaviour, though that's not a WS Protocol spec it is certainly a "common semantic" in Web services.

 

As WS-RX is the only spec in w3c or oasis standards process that defines a single SOAP header block with must Ignore as default (WS-A defines many headers and WS-S is MU as default), it's apparent there is no "common" right thing to do. 

 

I do agree that adding a wsrx:mU changes the semantics of extensibility points and would have implementation impacts.  That's generally the point of making proposals, to change semantics and implementations.

 

Cheers,

Dave

 


From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Tuesday, April 18, 2006 2:59 PM
To: Gilbert Pilz; David Orchard; ws-rx@lists.oasis-open.org
Subject: Issue 115 mU RM attribute questions

 

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i115

 

OK, so why is extensibility in RM so different from any other WS protocol that we need to add an attribute that essentially re-invents the SOAP semantics within the SOAP envelope? Was an attribute like this ever suggested within the SOAP itself? I assume we’ll have to revisit that entire discussion if it was.

 

I’m very concerned that this changes the common semantics of extensibility points if this is adopted. This seems like it would have major implementation impacts.

 

Marc Goodner

Technical Diplomat

Microsoft Corporation

Tel: (425) 703-1903

Blog: http://spaces.msn.com/mrgoodner/

 



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