Action Item : brief mustHappen analysis

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