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


>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> 
=====
>I don't have any problem with the kavi vote, if read in conjunction with
>the issue it is about, and I have already voted in line with my
>technical view (to avoid any suggestion of lobbying :-), that the
>ws-context spec should not mandate a particular value for
>soap:mustUnderstand, and should leave it available to ref. spec (and
>individual instance of use actually, but that wouldn't affect the ws-ctx
>
>text)
>
>I was challenging your suggested addition that ws-ctx should declare its
>own default, since I don't think it can have any effect. It would just
>be wasted words in the spec (which might trouble the reader).

Actually if we decide that the default should be "false", then it's a separate 
discussion as to whether we decide to mention this in the specification. For 
example, you could imagine saying nothing at all. That would be consistent 
with the vote.

Mark.

>
>Peter
>
>> -----Original Message-----
>> From: Mark Little [mailto:Mark.Little@arjuna.com]
>> Sent: 27 June 2004 19:12
>> To: Furniss, Peter; Mark Little; ws-caf
>> 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]