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

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

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.