RE: [ws-caf] proposal towards a resolution for issue 132

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

I care less about this subject than the volume of what follows will
indicate, but it's Friday afternoon and for once I'm whiling away the
time. And I do want to keep the content of WS-Context to an absolute
minimum.
 
My view is that the proposal should be rejected: vote No to mandatory
type specification on the Kavi vote that closes on 4 July.

I think that you and Peter are expressing a preference, not an
unambiguous need. The facility you desire (disambiguate classes of
context) is a product of concurrent use of > 1 context. This is not true
of all uses. 

It is not a good idea to place the type in the extension or derivation,
because it subverts the useful typed behaviour of the factory.

If the type should be in the base, but is not always needed, then it
should be optional. 

* * *

We cannot know or assume the field of use of this specification. The
consuming application may be closed and homogeneous; it may be heavily
interpenetrated with other applications and out-of-band protocols. If
the former, it can make do with base contexts; if the latter it and its
interlocutors can type away to their heart's content (will have to).

You cannot prevent the application "[attaching] a semantic to the base
context without identifiying the application of the semantic". A simple
application, which only wants one kind of context, doesn't need to
differentiate. 

What is a mandatory element? How can it be policed? If the only consumer
is the referencing application/specification/protocol then how can you
know (or care) that it is what you consider to be a valid type
specification? Can I make the element empty? If "nothing" is not a valid
type spec, what about a single character, like a full stop? The context
service accepts and matches the contents against some internal table of
known types: it should not care about the value of the known types. So
why shouldn't it have a null value factory? 

I think Peter is wrong to decry the notion that "the meaning is applied
to the untyped context by reference back from the application protocol
to which the header has been added. That seems to be contrary to the
additive approach of soap headers." 

Let's say I only have one context type. My infrastructure is, for
example, a proxy-stub pair, which add and strip contexts. The
infrastructure may process the untyped context, and the application is
(directly) none the wiser. 

Use of an untyped (type value is null, more correctly) context is not
therefore equivalent to "application consumes context". True, the
context may be a piece of information that the application never sees or
knows (e.g. security context whose interpretation may prevent delivery
to the application).

Contrariwise, the context may in fact be, in whole or in part, a piece
of application information, that *does* need to be communicated to the
application. Example: a transaction context that emerges on thread-local
storage. A correlation id that is used to identify a reply. Etc.

The issue of type is orthogonal to the issue of who consumes. We don't
(can't) have to make a rigid distinction between "the application" and
"the infrastructure". From the standpoint of WS-Context they can always
be interchangeable or the same thing.   

(By the way, I think that the "additive" model of SOAP headers is in
fact an abuse of XML. XML has the virtue that any element's type can be
identified by its namespace-qualified name. We don't need to put
elements in wrappers or buckets in order to figure out if they are our
business.)

Alastair


-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
Sent: 24 June 2004 16:58
To: Green, Alastair J.
Cc: Mark Little; ws-caf
Subject: Re: [ws-caf] proposal towards a resolution for issue 132



Green, Alastair J. wrote:

>I disagree with Peter (!) The meaning of a context may be
circumstantial
>or implicit.
> 
>If all I want out of the base context is a guid, then that is
>reasonable. Any other information that allows me to understand the
>nature of the referencing specification can be supplied in the base
>context, but it could also be incorporated in the extension, or it may
>not be necessary at all in a particular application, which "knows" that
>a WS-Context is just being used as a handy guid, or (if extended) is of
>a singular type. 
>  
>

I think it would be a profound error to allow for services to attach a 
semantic to the base context without identifiying the application of the

semantic; we would introduce a scenario that allows for ambiguity of 
meaning in the expressed expectations of service consumer (or it's 
hosting infrastructure).

> 
>If I have only one type of context in my application, why should I be
>forced to identify that type, when the knowledge of type can only be
>used to differentiate contexts?
> 
>
>Further: the "meaning" of a context may be given by some more complex
>deduced type resulting from particular combination of values within the
>extended context. I do not think we can mandate a single view or
>expression of type.
> 
>I do not object to a type field, which I think makes it easy to do a
>popular thing (get the context service to yield up contexts of
different
>types), but I don't think it should be mandatory. One could also "type"
>(specialize) the yielded context after the context service manufactures
>it, or not type it at all. All are valid approaches.
> 
>This does illustrate (in my view) the exiguous nature of the value of
>the base context. That should not be concealed by artificially padding
>the base context with more content that it must hold on grounds of
>universal need. 
> 
>Alastair
> 
>-----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com] 
>Sent: 24 June 2004 12:34
>To: ws-caf
>Subject: [ws-caf] proposal towards a resolution for issue 132
> 
>http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=132
> 
>There was some discussion on this topic in the mailing list and I agree
>with Peter (!) The context id is not in and of itself sufficient
>information to determine the meaning of a context.
> 
>Mark.
> 
>----
>Mark Little,
>Chief Architect, Transactions,
>Arjuna Technologies Ltd.
> 
>www.arjuna.com
>
>  
>