RE: [ws-caf] the issue on Context type identification

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

Very briefly, the reason for wanting the ability to "segment the context
space" was to make the marking for recognition for processing orthogonal
to whatever the context is really about. This would seem to be directly
following the pattern of use (or capability) you are proposing for
contexts as a whole - i.e. you are asking to have the ability to
recognise a context as a context so that a system can do something with
all contexts, regardless of what they are really about. (or at least all
contexts that are only recognisable as contexts and not as their
specific form).

Your proposal says there is something special about contexts-in-general
that would make it worth identifying such for special processing by
systems that are neither the originator or the consumer of the context
as a header (though they may be consumers of the body of the message). I
can't see why the mere fact that someone derived their specification
from WS-Context (with no specification in ws-context of what processing
applies)should be the marker for treating the headers in a particular
way.   I can see (some) utility in having markers for headers,
orthogonal to their primary use (and where such primary use is opaque to
a system) which  could be lead to locally-defined, but
publically-announced processing [ of which propagation is an example ].



Peter

> -----Original Message-----
> From: Kevin Conner [mailto:Kevin.Conner@arjuna.com] 
> Sent: 23 June 2005 16:27
> To: Green, Alastair J.
> Cc: Mark Little; Newcomer, Eric; ws-caf
> Subject: Re: [ws-caf] the issue on Context type identification
> 
> 
> Green, Alastair J. wrote:
> > We do have a proposal, which is my motion from the last 
> meeting, which 
> > has been tabled. It was, to paraphrase: to have an optional 
> > WS-Context-defined context-identifying attribute whose 
> value is a URI.
> > 
> > I moved to table (U.S. English sense) on the grounds that Greg 
> > believed (and Kevin disbelieved) that this feature was possible to 
> > achieve through existing facilities (attribute extension, if I 
> > understood correctly), and that therefore my proposal was moot, 
> > unnecessary, redundant etc.
> 
> The attribute extensibility discussion related to segmenting 
> the context space and I agreed with Greg :-),  I provided the 
> WS-Security example.
> 
> In my view your proposal does not solve the issue for two reasons.
> 
> The first is that the attribute is optional and, by 
> definition, means you cannot identify all contexts.  This is 
> the functionality that was removed by the context naming 
> change and the reason for raising the issue.
> 
> The second is in relation to the URI.  This was presented as 
> a mechanism for segmenting the context space, IIRC, which I 
> believe is undesirable for the following reasons: -
>  - the proposal is not sufficient (cannot specify more than 
> one segment)
>  - it can be achieved by other mechanisms
>  - it is layering another specification on top of context
> 
> I can only think of two reasons for segmenting the context 
> space, to group unrelated contexts (e.g. for security) or to 
> group related contexts (e.g. all transaction specifications). 
>  The first is an orthogonal issue to context and should be 
> handled using attribute extensibility, as in ws-security.  
> The second can either be handled through attribute 
> extensibility, if it is deemed an extension to the 
> appropriate specifications, or included in those 
> specifications if it is deemed core functionality.
> 
> I started this with a very simple issue, the reinstatement of 
> a potentially useful facility that had been accidentally 
> removed (IMHO).  It has since beem turned into a routing 
> issue and now a context space segmentation issue, both of 
> which (again IMHO) have detracted from the original issue.
> 
> I suspect that there will still be disagreement on this issue 
> by the f2f and would rather it was deferred to a later 
> revision of the specification than hold up the f2f proceedings.
> 
> 	Kev
> 
> -- 
> Kevin Conner
> Arjuna Technologies Ltd.
>