Re: Action Item : brief mustHappen analysis

Glen,

Please see below.

Cheers,

Chris

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

What I suggested was that a careless handler could inadvertently
modify the dependsOn in a manner that actually changed what was
expected.

e.g.

Let's say that A does its thing and writes out a dependsOn in the
C header an empty list! That would be a bad thing.

I was also suggesting that it complicated the processing model
unnecessarily because the handler for A needs to modify the header
targetted at C. This means that it needs to scan all of the headers
looking for a dependsOn that includes the IDREF of the ID of the 
just processed header block.

What Noah had proposed seems cleaner and simpler to implement.

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

Possibly, yes.

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

pls see above. hopefully that will help.

> 
> Thanks for the comments,
> --Glen

Received on Wednesday, 15 August 2001 16:28:01 UTC