RE: Action Item : brief mustHappen analysis

Hi Chris:

(comments below)

> > 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.

How so?  I mean, we haven't fully fleshed this out, but it seems to me that
the dependsOn list that Noah suggested is in exact order - A followed by B
followed by C - so once something has been processed, I don't see why it's
unsafe to take it off the front of the list.  If you're talking about a case
where a header depends on both "A" and "B" and doesn't care about the order
in which those headers are processed, that's a different issue, and might
involve some more syntax inside the dependsOn value to allow for arbitrary
boolean combinations.  In this case, you could still replace "(A and B) or
C" with "B or C" after successfully processing A, no?

> It also omits any notion of an audit trail which might be important.

And also provided, perhaps, by another header/extension, since audit trails
and processing dependencies are in some cases orthogonal concepts.

The real problem I have with including the "blank" headers is that it's
confusing.  Since they are at the top level and have QNames that match
extensions which are normally processed, it's weird that they're really just
"data".  Another solution to this would be to introduce one more layer,
i.e.:

<Header>
  <someNS:ProcessedHeaders SOAP-ENV:mustUnderstand="true"
xmlns:someNS="extensionNS">
    <entryA/>
    <entryB/>
  </someNS:ProcessedHeaders>
</Header>

> 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.

This I don't understand at all - could you explain a bit more what you mean
here?

Thanks for the comments,
--Glen

Received on Wednesday, 15 August 2001 16:17:52 UTC