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

[Mark Little <Mark.Little@arjuna.com>]

Peter, protocol-uri should definitely be type as that was an issue we agreed 
(and closed) at New Orleans. Simeon, can you check the discrepancy?

Mark.

>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> 
=====
>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
>> >
>> >
>> >
>>
>>