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

["Green, Alastair J." <Alastair.Green@choreology.com>]

Well in my view you have not made a case for unsegmented context
awareness. It's trivial to the point of uselessness.

There is only one use case offered: forwarding. You haven't answered the
point that any other use case is logically excluded (because it involves
processing the content in some way). 

And if forwarding/routing is the problem then you do need to segment the
context space orthogonal to the referencing specs. 

As a URI can contain anything, it can handle the vector case.

There is no such thing as "mandatory" in this situation. You can write a
rule that says "it MUST carry a context". And if it doesn't? If they
want it, they use it. If they don't care, they don't. You do need to
provide the facility, and then they need to agree to use it. Receiver
can enforce, if you like.

Can you explain your points on attribute extensibility, please? What
exactly do you want to do to get the functionality you are looking for?
How will attribute extensibility contribute to this, and/or the
functional requirements of my proposal? Your assistance in my education
on these points would genuinely be very helpful.

I am not withdrawing my motion ... yet :-). I am looking for a solution
that pleases all of the people, whatever the scope of their enthusiasm
for processing contexts qua context.

Alastair

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