Nested contexts ( was RE: [ws-caf] Mt Everest and WS-CF)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

In one of my diatribes, I mentioned:

>>
>>    child-contexts - (i think we have an issue challenging these) - I
believe
>>  the only known uses are coordination/nested
transactions/subtransactions, which actually 
>> need something different (parent-contexts might be useful)

to which Mark replied:
> FYI the issue about nesting of contexts was closed at New Orleans.

Thanks the issue I believe was 54 about whether nesting was generic,
closed without minuted discussion.


However, there seem to be some aspects left over. Perhaps these were
dealt with in New Orleans, but not documented.

a) on ContextService:begin, if there is a context containing that
already contains child-contexts, is the new context a child of the
received parent, or of one of the children ? (or grand-children ?).  

b) if the answer to a) is "child of the parent", how does one create a
multi-level nest (if answer to a) is different, how does one add a
sibling to a child) ?  Supply the child-context as if it were top-level
?    Or should begin have a parameter identifying the immediate parent
in the received context.

c) can the context on a begin be by reference ? 

d) related to b): In general, can a child-context be communicated on its
own, outside of its parent ? If it is, how does one find the rest of the
family ?

The most-known use case for nested contexts is, I believe, the nesting
and interposition in transactions. Does that use really want to
propagate the entire ancestral (and colateral ?) tree ? Other
transaction protocols tend only to propagate the identifiers of the
immediate line. The present WS-Context nesting capabilities don't seem
to be well-aligned with that need.  

Peter