[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: votes (was RE: [ws-caf] proposal towards a resolution for issue 132)
the non-technical thread. I don't see the difference either - a Kavi vote is a way of pushing the technical discussion, and reaching a conclusion. One's perception of the technical (and other) wisdom of the alternatives will decide how one will vote, I hope. Sometimes it works that a kavi vote is just a ratification of a rough consensus, or clarification of the weight of settled opinions - in other cases, as here, it can flush out counter arguments. Fortunately, Kavi allows one to change one's vote until the close, so technical persuasion is possible. (On a technical issue like this, if the discussion flushes out substantial disagreement, I'd be inclined to cancel the ballot until the situation is clearer - it is pointless for a group to lock itself into a choice made while opinions were in flux. ) Or, Eric, was your concern only about the mere words "please vote X on issue N" ? That can be a simple summary of the conclusions of a tangled case, especially if the proposal is itself complex. (though I'd have thought this one was fairly straightforward - "type" is currently optionaland the proposal is to make it mandatory, not to remove it (to be really precise, to change MinOccurs="0" to MinOccurs="1") Peter > -----Original Message----- > From: Green, Alastair J. > Sent: 25 June 2004 18:00 > 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]