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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

<wsctx:context soap:mustUnderstand="false" expires="2004-06-24-16:00utc"> <wsctx:context-identifier>http://s.furniss.co.uk/54.355/gph716.1</wsctx:context-identifier></wsctx:context>
 
----------------------------
 
A vice and virtue of headers is that they can be added to an application message without necessarily being required by the understood application /business protocol. An untyped ws-context would only *necessarily* mean what is defined for it in the ws-context spec - since that itself is under discussion in other issues, some of this argument gets a little abstract but assuming no requirements from mustPropagate, participating-services and no child-contexts then I think the ws-context spec just says it means the message is part of the activity identified by the context-identifier. But, on its own, there is no understanding of what else might be in the same activity and what use the receiver should make of the knowledge.
 
Alastair is suggesting 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. It would certainly make it very difficult to implement ws-context, or the particular use of ws-context as an infrastructure service. It would be to treat the context header as just a syntactical quirk for transmitting part of the application semantics. And, since activities can overlap, if there is another context on the message, either all must be typed (so a sole context did have a type, just it wasn't on the wire), or the application protocol has got to define the meaning of the sole typeless context.
 
Peter
 
-----Original Message----- 
From: Green, Alastair J. 
Sent: Thu 24/06/2004 13:39 
To: Mark Little; ws-caf 
Cc: 
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-----
	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