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