OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[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]