[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
On looking at the text, I believe Bryan is right, and that the type field is under-specified at the moment. I'd never noticed, partly because I was looking for a field with the semantic outlined below, and inflated the text that is actually there with what I thought it meant. On this occasion, I think, from exchanges over the months, my understanding was close to that intended by the authors - but it doesn't actually say so, and Bryan's questions are are not resolved in the text. This can be taken as an object lesson in what an open specification must say - you dare not assume others will understand what you meant if you don't say it explicitly (which is why "thunk factor" comparisons are specious) So, my understanding of the type (defined as "indicating the type of the protocol") is that identifies a particular context-using protocol. A type URI is assigned by a referencing specification to identify itself and the procedures, data elements and services it specifies. It could be identical to the namespace of the xml of that referencing spec, or could be different. (I see no distinction between a "referencing specification" and a "context [-using] protocol", other than that one defines the other - in fact, in this case "context[-using] protocol" is better, as it avoids ambiguity for the case where one document specifies more than one protocol (set of rules) and thus more than one type URI. As an identifying URI, the constraints on the URI are only that the assignor can be sure no-one else will assign it, and that it won't be re-used for something else of the same kind. Thus you can make it the URL of your favourite web site, but used as a context type, provided you can be sure no-one else will. (you can bend the re-use rule if the extent of its use is tightly known). The URI can be from any uri scheme (http:, urn:, etc). It is just an unambiguous name. As URIs they are the same if they match lexically (I think there is an ietf (?, w3c ?) spec defining exact rules for this, to canonicalise escapes, though normally case sensitive string match will work) On this interpretation, yes you could use type as a despatching mechanism. The context receiver needs to know the type because without it, there is no well-defined behaviour the receiver can be expected or required to follow, other than any behaviour specified in the base context, or implied by the application the context is being sent with. The behaviour specified in the base context is under consideration in other issues, and could well turn out to be none. Implying the context protocol from the application protocol is what Alastair is suggesting. I believe the type is initially set in the begin message (though the xml for begin seems to call it a protocol-uri - the names shoulod be aligned). It is thus chosen by the initiating requestor from the set of context protocol names known. Peter > -----Original Message----- > From: Murray, Bryan P. [mailto:bryan.murray@hp.com] > Sent: 25 June 2004 19:30 > To: Green, Alastair J.; Newcomer, Eric; Greg Pavlik > Cc: Mark Little; ws-caf > 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]