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] proposed resolution for issue 129


Peter, if you're having difficulty interpreting the current Kavi vote then 
maybe I can help: I think given your description you should vote to accept 
using soap:mustUnderstand and take a default of false, since that is in line 
with the soap default.

All the best,

Mark.

>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> 
=====
>1. I don't think we can define a default for soap:mustUnderstand with
>ws-context - at least, not usefully.
>
>2. If the receiving implmentation doesn't recognise the ws-context
>namespace, then it won't know of any
>any ws-context-defined default for soap:mustUnderstand, so will use the
>soap-defined default. (and ignore the header)
>
>3. If the receiving implementation does recognise the ws-context
>namespace then it "understands" and
>the mustUnderstand setting is irrelevant.
>
>4. There is the possibility of an implementation recognising the
>ws-context namespace but not the
>context type. This could be affected by a ws-context-defined default for
>soap:mustUnderstand.
>Since a receiver as in 2 would ignore a context with no explicit
>soap:mustUnderstand, it is
>hard to see what point there would be in making this semi-understander
>throw a fault.
>
>5. The original text (the target of this issue) was about ws-context
>mandating an explicit
>override of the default (i.e. soap:mustUnderstand was required to be
>present, and be ="true").
>A referencing specification could legitimately mandate that (though the
>arguments about
>the wisdom of such a requirement apply). But ws-context should not, and
>leave it to the
>particular use to decide what setting to use, with the soap-defined
>default applying if
>the field is omitted.
>
>6. My conclusion in 4 may be contrary to what I sent earlier about
>keeping the ws-context:mustUnderstand.
>It would only be useful to keep that if there is a crossover - soap and
>wsctx values different. It
>seems pointless to have soap=false, wsctx=true, as said in 4. If there
>is significant behaviour defined in the
>base ws-context, it is just possible to justify soap=true, wsctx=false -
>it would mean the base
>behaviour is required, but the extension behaviour is not. Since the
>base behaviour is under
>discussion on other issues, I think the resolution of this (the survival
>of wsctx:mustUnderstand)
>should be deferred.  [and we need an issue on it, but that can wait till
>this one is settled]
>
>Peter
>
>
>
>
>
>> -----Original Message-----
>> From: Mark Little [mailto:Mark.Little@arjuna.com]
>> Sent: 27 June 2004 01:52
>> To: Furniss, Peter; Mark Little; ws-caf
>> Subject: RE: [ws-caf] proposed resolution for issue 129
>>
>>
>> It does define a default, which is false, but there is no
>> requirement for us
>> to adopt that default. Hence the option to the TC.
>>
>> Mark.
>>
>> >===== Original Message From "Furniss, Peter"
>> ><Peter.Furniss@choreology.com>
>> =====
>> >This is the soap:mustUnderstand, yes (the context
>> mustUnderstand is the
>> >subject of 134, and may or may not survive).
>> >
>> >Doesn't soap define a default (false, i think). Do we need
>> to define a
>> >further one ?
>> >
>> >Peter
>> >
>> >-----Original Message-----
>> >From: Mark Little [mailto:mark.little@arjuna.com]
>> >Sent: 24 June 2004 12:25
>> >To: ws-caf
>> >Subject: [ws-caf] proposed resolution for issue 129
>> >
>> >
>> >http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=129
>> >
>> >I'd like to propose that we change the text to agree with
>> this, i.e.,
>> >that mustUnderstand should be defined by referencing specifications.
>> >The only caveat would be: should there be a default and if so, what
>> >value to use? I think for interoperability purposes there
>> should be a
>> >default and it should be false.
>> >
>> >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]