W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

Re: Action Item : brief mustHappen analysis

From: christopher ferris <chris.ferris@east.sun.com>
Date: Wed, 15 Aug 2001 16:27:59 -0400
Message-ID: <3B7ADB4F.ECF5DE@east.Sun.COM>
To: Glen Daniels <gdaniels@macromedia.com>
CC: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>

Please see below.



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


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC