Re: Action Item : brief mustHappen analysis

Glen,

Some comments inline.

Cheers,

Chris

Glen Daniels wrote:
> 
> 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.

Hmmm... this seems suspect. It introduces a potential that the rewritten
dependsOn might inadvertently omit dependencies that haven't been processed.
It also omits any notion of an audit trail which might be important.
It also depends upon processing a header that wasn't targetted at the
current node, which while certainly not precluded, complicates the processing
unnecessarily IMO.

> 
> 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 15:57:49 UTC