- From: <Noah_Mendelsohn@lotus.com>
- Date: Tue, 5 Jun 2001 02:32:57 -0400
- To: "duglin" <duglin@yahoo.com>
- Cc: xml-dist-app@w3.org
Duglin writes (my apologies if that's not your name...that was my best guess from your note): >> >> Noah, >> You mentioned that because of the "cache manager" scenario the >> current targeted-MU semantics of SOAP makes sense and should stay >> (paraphrasing a bit). And I agree that it is a valid scenario >> and needs to be supported, however the case of a targeted-MU that >> never hits its actor causing a fault once the message hits the >> ultimate destination is a valid scenario as well. Yes, it is reasonable to assume that there will be situations in which users wish to catch procesing that is missed because a SOAP message didn't go to the intended processing point, but SOAP does not currently attempt to solve that problem. >> To me it's a question of what should the default behavior of >> SOAP be. Both can be supported, either by the core spec or with >> an extension. So it seems like it should be a question of which >> one should be 'default' and which one would require an extension. With respect, in the short run I think it's a question of what the spec. says. It says, "don't do anything at the endpoint if mustUnderstand headers for other actors happen to show up. " You are making the case that it should have been written differently, but if we want interop, we need to do what the spec says. Indeed, the protocol workgroup is considering mechanisms that would address your concerns, one of which was suggested in my earlier note http://lists.w3.org/Archives/Public/xml-dist-app/2001May/0310.html. Many of us feel that it would be desireable to provide such function as an extension, in the interests of keeping the core protocol small and compatible with SOAP v1.1 to the extent possible. Whether such compatibility is achievable is being investigated. Also, it's my personal belief that doing "mustHappen" (as I call it) checking at the endpoint is in general too late. If headers are directed to actors A, B, C, D, E, and A is missed, it can be way to late to notice it at endpoint E. B may do something inappropriate that can't be rolled back. For that reason, I think an effective mechanism will require checking at each point along the way. >> And of course you know what I think. 8-) >> Let me explain why...given that core SOAP does not allow the >> client to route a message he is basically at the mercy of the >> SOAP nodes in the message path to route the message >> appropriately. Now, combine this with: >> Elements tagged with the SOAP mustUnderstand attribute >> with a value of "1" MUST be presumed to somehow >> modify the semantics of their parent or peer elements. >> Tagging elements in this manner assures that this change >> in semantics will not be silently (and, presumably, >> erroneously) ignored by those who may not fully >> understand it. from the SOAP spec. To me this is an >> admission that MU's are pretty darn important and ignoring them >> is a serious violation - yes I know the above talks about what do >> to (or to not do) within a single SOAP node once the MU reaches >> its actor - this does not apply to the entire message or entire >> message path as a whole. As I said above, just because it's tempting to read "mustUnderstand" as "important and mustHappen", doesn't mean that's what the spec says. Maybe it should, but it currently doesn't. We are looking for the best way to address the need for processing that "mustHappen", which seems related to "must happen in the right order", which gets you into questions of message routing or at least expressing the dependency graph. >> However, when I combine the fact that MU's are important with >> the fact that the client has no way of routing messages (in the >> core spec) I'm left with the question of what would the client >> like to see happen if a targeted MU never reaches its actor? And >> I just can't help but think that a vast majority of the cases the >> client will want to know that his MU header was ignored. >> So, let me repeat it - I do see your use-case of the "cache >> manager" being possible, but it just don't see it as all that >> common. I just can not believe that very many clients will want >> to send out a message with MU semantics that may or may not be >> processed, and be very happy about it. The entire notion that >> the client would be happy if the actor was never hit at all, but >> unhappy if the MU semantics were not understood on the off chance >> that the actor was hit, just seems strange to me. >> It seems to make much more sense to me that SOAP should take a >> much more conservative approach and error on the safer side by >> saying "unprocessed targeted MU's reaching the ultimate >> destination should result in a fault". And of course, support >> the current behavior through an extension. It's all just a >> question of what's the default going to be and I'd choose the far >> more likely desired behavior. -Dug To net out my response: I think we need to analyse this requirement in the context of larger issues of message routing. It's not just "mustHappen", it's "mustHappen in the right order". I personally think that MU is definitely useful as it stands in the cases of (a) it' use on headers sent to the endpoint, which includes but is not limited to the <body> (b) headers sent to "next" and (c) other situations in which one is confident of routing and actor naming. All of these are situations in which MU errors will be reliably detected, and so MU can be used for at least extensions of this sort. So, we've got something that has utility as it stands. Changing its interpretation would be a retroactive change to the specification and thus break compatibility. It is indeed important to provide mechanisms, as you suggest, to ensure that essential processing happens in the right order. The workgroup is carefully considering the requirements and possibilities and would welcome input on the most appropriate solutions (please do try to read the email threads before commenting, as there has been a considerable amount discussed already, with quite a range of positions represented.) By the way, there is a workgroup meeting coming up and I wouldn't be surprised that some progress will be made on these issues soon. Thank you. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Tuesday, 5 June 2001 02:39:16 UTC