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: RE: [ws-caf] proposal towards a resolution for issue 132


>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

"Peter and Greg"? It was "Peter and Mark" in your original email. Glad to see 
you acknowledge that there are more than the two of us (Peter and myself) 
arguing for this proposal (not forgetting Eric of course).

>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?

I can't speak for Eric (and apologies if he's already answered, but I haven't 
gone through all my email yet), but when writing the original specification 
there was the explicit assumption that the context id was the minimum 
information needed to provide a basic context that could unambiguously be used 
for correlation. However, speaking as one of the original authors, there was 
the implicit assumption that there could be only one use for such a "type" of 
context. Fairly obviously (and with blinding hindsight) that's wrong and we 
(I?) were tying an implicit "type" field into that assumption.

IMO what this vote is doing is keeping the spec. as it was originally intended 
and fixing the implicit by converting it to explicit.

Mark.

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