Re: [ws-caf] Context query

[Kevin Conner <Kevin.Conner@arjuna.com>]

Furniss, Peter wrote:
> At the standard level, defining a single characteristic of headers that
> marks them as appropriate for that sort of passing on doesn't seem right.

It doesn't and I am not asking for it.

> For those who disagree, can I suggest attempting to define, in half a
> page of specification text exactly what behaviour is expected and
> required of the passing on system.

I do not believe we can, nor should, specify the semantics of the passing on system.  They are very much dependent on the requirements of that system and, as such, are the responsibility of the appropriate Architect.

What I am arguing is that we should not prevent an Architect/Designer/Implementor from making such a choice if they feel that it is justified.  If they wish to identify each context header explicitly, then so be it.  If they wish to use a generic mechanism, then so be it.

>>It is not always a requirement to understand nor identify the 
>>type of a 
>>context in order for a processor to choose to pass it 
>>through, it may be 
>>sufficient to identify it as a context.
> 
> 
> or "it is not a requirement to understand the purpose of a header
> other than to identify it as to be considered for pass through"
> 
> i.e. the discussion is about whether "header is a context" is THE 
> flag that says "pass through to 'consequential' messsages", so 
> we should think of the pass-throughness, not the contextness.

No, I really do mean context.  The issue is about generic identification of context and not identification of 'pass through' headers.  The 'pass through' example I gave earlier, and the reasons why 'simple' changes may not be easy, are issues that I have encountered in commercial deployments.  I'm sure there are other use cases that could be satisfied by generic identification of context but I will stick with those I know :-)

My argument is that in preventing the generic identification of context we are preventing the use of context in ways that we have yet to consider.

	Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.