- From: Glen Daniels <gdaniels@macromedia.com>
- Date: Wed, 15 Aug 2001 14:40:06 -0400
- To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi folks - to discharge my action item from a couple of weeks ago, I took a look at Noah's proposal for a mustHappen extension [1]. As a reminder, this action item was to analyze this mechanism to determine if it was suitable for providing the kind of semantics that developers seem to want regarding the ability to generate faults if a mustUnderstand header targeted for some other node reaches the ultimate destination. I agree with Noah's intuition that if we're thinking about this behavior, it's wise to consider the more general case of a "partial order" of headers which must be processed correctly and in order by all the nodes in a message path. The suggested mechanism seems to me, though a first cut, a very reasonable way to move toward this goal. A couple of small "tweaks" I would offer, in light of more recent discussions and the processing model changes we came up with in Dinard: 1) There should be a header in the examples which indicates that the "mustHappen" feature is switched on. This header should be "mustUnderstand='true'", targeted at the "next" actor, and automatically resent to each node in the message path. This header ensures that the processing model changes implied by the mustHappen extension will be honored. 2) Rather than including "blank" copies of the successfully processed headers in the messages which continue on after hops A and B, I think it would be better to amend the "dependsOn" list by removing the successfully processed headers from the beginning. This seems cleaner to me, and avoids the somewhat confusing semantic of header entries persisting in the message without their full syntax or meaning. That said, I believe this sort of extension will arise naturally as a result of the later efforts of this group or other groups in the soap community, and that we do not need to tackle such a beast to acheive our goals with respect to the core specification. I do think the example given (with the caveats above) indicates that our processing model is strong enough to enable specification of this functionality as an extension, which is a good thing. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001May/att-0310/02-MustUnd erstand.html Glen Daniels Macromedia http://www.macromedia.com/ Building cool stuff for web developers
Received on Wednesday, 15 August 2001 14:41:04 UTC