RE: [ws-caf] proposed resolution for issue 129

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