[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:
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]