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.
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
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 Little,
Chief
Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com