[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
My understanding of the ballot is not that the type field is to be removed or not, but that the type field is to be changed from optional to mandatory. This means the type field remains in the spec independent of the results of the ballot. I think the type field is under-specified in version 0.3. For this reason I think it is difficult to say whether it should be mandatory or not. There is no indication about how values should be chosen for the type of a newly created context. Is it the namespace of a referencing spec? Is it one of a set of global values? Is it the URL of my favorite web site? Is it some industry segment agreed upon value? Is it the namespace of some context protocol? The description of type also has no indication of how unique it is, whether I can compare 2 types to determine something (???!), how this comparison should be performed. Can I use type as a dispatching mechanism for the handling of contexts with different meaning? Why should a context receiver care what the value of type is? Bryan -----Original Message----- From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] Sent: Friday, June 25, 2004 10:00 AM To: Newcomer, Eric; Greg Pavlik Cc: Mark Little; ws-caf Subject: RE: [ws-caf] proposal towards a resolution for issue 132 Eric, I can't see the distinction between saying "I disagree, for the following reasons, with the proposed resolution on 132" (when a vote has just been been called), and saying "I believe you should vote no in the current vote to the proposed resolution on 132 for the following reasons". The vote-in-progress forced me to get on with replying to early posts. There is no point to these debates unless they lead to resolutions by vote, and we shouldn't be ashamed to have views or lobby for them, however expressed. Consensus is all very well, but democracy cuts the knot. I believe it's important that the specs are as minimal and as correct as reasonably possible. Alastair -----Original Message----- From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] Sent: 25 June 2004 17:51 To: Green, Alastair J.; Greg Pavlik Cc: Mark Little; ws-caf Subject: RE: [ws-caf] proposal towards a resolution for issue 132 Alastair, As a postscript, what caused me to reply was your lobbying for a vote against. I thought therefore it would be necessary to lobby for a vote in favor. However, taking a step back, I think the right thing to do is simply request that we both (and everyone else in the TC for that matter) refrain from lobbying for votes in favor or against, and simply state our arguments. In other words, if you or I want to say we plan to for or vote against and why, that's great. But let's try to avoid using this email list to try to lobby others to vote one way or another. All right? Thanks again, Eric -----Original Message----- From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] Sent: Friday, June 25, 2004 12:38 PM To: Newcomer, Eric; Greg Pavlik Cc: Mark Little; ws-caf Subject: RE: [ws-caf] proposal towards a resolution for issue 132 Eric, Not a matter of opinion, exactly. I think that the proposal is based on a stylistic preference or assumption, and exceeds the minimal (which is generally a Bad Thing for standards). What I meant to convey is that Peter and Greg wish to enforce an approach which is more than is required. To be clear, I am in favour of allowing a type to be specified; I am not denying its usefulness-- but I do not believe it is universally necessary. If the proposal is to leave the spec as it is, why has it been put forward, and why are we voting on it? Alastair -----Original Message----- From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] Sent: 25 June 2004 17:31 To: Green, Alastair J.; Greg Pavlik Cc: Mark Little; ws-caf Subject: RE: [ws-caf] proposal towards a resolution for issue 132 Alistair, I'd take the opposite view here and recommend a vote in favor, since the presence of the type field is viewed as helpful. It does not appear to be a flaw in the spec but rather a matter of opinion we're debating (and even between yourself and Peter Furniss I might add), and as such I think the normal course is to allow the current spec to stand. Thanks, Eric -----Original Message----- From: Green, Alastair J. [mailto:Alastair.Green@choreology.com] Sent: Friday, June 25, 2004 12:18 PM To: Greg Pavlik Cc: Mark Little; ws-caf Subject: RE: [ws-caf] proposal towards a resolution for issue 132 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]