[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] proposal towards a resolution for issue 132
|
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----- 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. ---- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]