[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 From: 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:
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: 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. 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]