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

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

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

In your opinion, yes.  Personally I would rather not second guess how people 
would use context.

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

Earlier in the discussion you didn't believe there was a use case, now you 
believe it is the only one.  Why should there not be another one that we have 
yet to identify?

As for every other case being logically excluded, how is this so?  You assume 
that context is opaque when it isn't, there are items in the base context that 
someone could use should they choose. What they would use them for is another 
question but that's the whole point, just because we don't know their reasons 
doesn't mean that they do not exist nor that we should exclude them.

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

Forwarding/routing is still not the problem :-)

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

I'm not aware of a standard way of concatenating URIs into a vector, does this 
mean we have to invent something?  What is the mechanism in the 'vector case'?
 Perhaps you can educate me?

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

There is no such thing as mandatory but there is compliance.  There is no 
reason anyone should, in fact, choose to use context but we certainly hope 
they will.

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

Attribute extensibility doesn't help me, it helps your segmentation example 
:-).

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

We seem to be arguing from different perspectives, you from specifics, me from 
generics.  It seems obvious that an agreement on this issue will not be 
reached in the short term, hence my suggestion to defer.

    Kev

Kevin Conner
Arjuna Technologies Ltd.