RE: Action Item : brief mustHappen analysis

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

It would be a bug, if the dependsOn used to also include B... we can't
prevent bugs in general.

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

Gotcha.  Yes, you're right - see my last note to Rich.  I'd just rather see
the blocks somehow encapsulated instead of at the top level.  But then
again, we're not actually designing this, are we? :)

--G