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] [Bug 129] New: SOAP mustUnderstand should not be determined by ws-context


I agree. I was only pointing out that the current schema is broken anyway
:-)

Mark.

----- Original Message -----
From: "Furniss, Peter" <Peter.Furniss@choreology.com>
To: "Mark Little" <mark.little@arjuna.com>; "Doug Bunting"
<Doug.Bunting@Sun.COM>; <ws-caf@lists.oasis-open.org>
Sent: Friday, May 28, 2004 2:08 PM
Subject: RE: [ws-caf] [Bug 129] New: SOAP mustUnderstand should not be
determined by ws-context


> ok.
>
> But:
>
> If mustUnderstand is on context, then, since context is usually a SOAP
> header element, it collides with the SOAP:mustUnderstand attribute.
> Having a ws-context defined mustUnderstand on the xsd:any - or perhaps
> on any children of a complex type there, would seem possibly, especially
> for the sort of use Doug suggested.
>
> We don't seem to have a definition of what "mustPropagate" means. I
> believe it only applies if (soap) mustUnderstand=0. If the receiver
> understands the context, they will no what they want to do with it, and
> whether it should be propagated as received or after modification. It's
> only if the receiver doesn't understand the particular context, but the
> original sender wants it to be passed on that mustPropagate comes into
> play. (this would provide a utility in ws-context - headers that can be
> propagated mindlessly - though one could argue that it should be
> promoted to soap level)
>
> And as Doug points out, we need to say, or have some way of saying where
> mustPropagate is to apply to. Synchronous responses only (rather useless
> - the carrier does that) ? WSDL-defined out's to in's, regardless of
> carrier ? Anything off the same thread (what if there are unknown
> invocations on ws that don't understand ws-context) ?
>
> Peter
>
>
> > -----Original Message-----
> > From: Mark Little [mailto:mark.little@arjuna.com]
> > Sent: 28 May 2004 13:38
> > To: Furniss, Peter; Doug Bunting; ws-caf@lists.oasis-open.org
> > Subject: Re: [ws-caf] [Bug 129] New: SOAP mustUnderstand
> > should not be determined by ws-context
> >
> >
> > Peter, the mustUnderstand/mustPropagate are in the wrong
> > place for the schema in the currently available spec. I'm
> > sure I've mentioned this before on the list (though could be
> > wrong), but it may not be an issue because it's something
> > that I think was editorial. They should be on the context itself.
> >
> > Mark.
> >
> > ----- Original Message -----
> > From: "Furniss, Peter" <Peter.Furniss@choreology.com>
> > To: "Doug Bunting" <Doug.Bunting@Sun.COM>;
> > <ws-caf@lists.oasis-open.org>
> > Sent: Friday, May 28, 2004 12:52 PM
> > Subject: RE: [ws-caf] [Bug 129] New: SOAP mustUnderstand
> > should not be determined by ws-context
> >
> >
> > > I strongly agree with your point about general extensibility - just
> > > about any "any" needs to have an indication of whether it can be
> > > safely ignored by the ignorant, or whether would corrupt
> > the sender's
> > > purposes.
> > >
> > > But you end up saying that we can have
> > soap:mustUnderstand="0" if and
> > > only if we require neither understanding or propagation
> > further in. I
> > > agree. But the implication of that is that we don't, at
> > specification
> > > level, need soap:mustUnderstand="1" everywhere.  Just the
> > sender needs
> > > to think carefully.
> > >
> > > But looking at our schema, what are the indicators doing on
> > the list
> > > of participating services - they surely belong on the any ?
> > (and, for
> > > that matter, how does the participating services list get modified)
> > >
> > > Peter
> > >
> > > > -----Original Message-----
> > > > From: Doug Bunting [mailto:Doug.Bunting@Sun.COM]
> > > > Sent: 27 May 2004 20:14
> > > > To: ws-caf@lists.oasis-open.org
> > > > Subject: Re: [ws-caf] [Bug 129] New: SOAP mustUnderstand
> > should not
> > > > be determined by ws-context
> > > >
> > > >
> > > > We may need soap:mustUnderstand="1" everywhere.  The
> > receiver must
> > > > understand WS-Context enough to know a set of "related
> > messages" (as
> > > > mentioned in my previous email[1]) must include the same
> > structure.
> > > > More generally, the receiver must implement the correct
> > > > propagation rules.  This
> > > > receiver does not need to understand the entire contents of
> > > > the context.
> > > >
> > > > We are hitting on a general point about extensibility in SOAP
> > > > messages (or, even more generally, XML instances).
> > Wherever "any"
> > > > content is allowed,
> > > > understanding may or may not be required of added content --
> > > > depending upon
> > > > the semantics of the container and whatever additional
> > > > indicators that
> > > > container provides (and how they are set in a particular
> > > > message).  The
> > > > soap:Header element has an indicator (soap:mustUnderstand)
> > > > usable in every
> > > > child element for this purpose.  For ctx:context, the SOAP
> > > > indicator must
> > > > be true[2] so that our indicators (ctx:mustUnderstand and
> > > > ctx:mustPropagate) are used correctly.  The only case in which
> > > > soap:mustUnderstand may be false occurs when ctx:context
> > contains no
> > > > ctx:activity-list or both indicators are false on the
> > > > ctx:context/ctx:activity-list element.  (No, I am not sure
> > > > the new schema
> > > > will contain the same indicators or place them in the same way.)
> > > >
> > > > thanx,
> > > > doug
> > > >
> > > > [1] http://lists.oasis-open.org/ws-caf/200405/msg00142.html
> > > >
> > > > [2] Please note my use of values from the value space[3] of XML
> > > > Schema part 2.  This may confuse an issue originally[4] about the
> > > > lexical space[5].
> > > > That original issue ("1" versus "true") should also appear in
> > > > the issues list.
> > > >
> > > > [3] http://www.w3.org/TR/xmlschema-2/#value-space and
> > > > http://www.w3.org/TR/xmlschema-2/#boolean
> > > >
> > > > [4] http://lists.oasis-open.org/ws-caf/200405/msg00086.html
> > > >
> > > > [5] http://www.w3.org/TR/xmlschema-2/#lexical-space and
> > > > http://www.w3.org/TR/xmlschema-2/#boolean-lexical-representation
> > > >
> > > > On 26-May-04 04:30, bugzilla-daemon@arjuna.com wrote:
> > > >
> > > > > http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=129
> > > > >
> > > > >            Summary: SOAP mustUnderstand should not be
> > > > determined by ws-
> > > > >                     context
> > > > >            Product: WS-Context
> > > > >            Version: 1.0
> > > > >           Platform: PC
> > > > >         OS/Version: Windows 2000
> > > > >             Status: NEW
> > > > >           Severity: normal
> > > > >           Priority: P2
> > > > >          Component: Implementation and interoperability
> > > > >         AssignedTo: ws-caf@lists.oasis-open.org
> > > > >         ReportedBy: peter.furniss@choreology.com
> > > > >          QAContact: mark.little@arjuna.com
> > > > >
> > > > >
> > > > > Draft 0.2, section 2.1 says that SOAP:mustUnderstand must
> > > > be true for
> > > > > a context
> > > > > sent with an application message.  WS-Context should not
> > > > specify this - it
> > > > > should be left to a higher level. There will certainly be
> > > > some cases where a
> > > > > context is propagated in hope, but not certainty, that it
> > > > will be recognised. A
> > > > > referencing specification could mandate a value, or leave
> > > > it to the particular
> > > > > use.
> > > > >
> > > > > It should be stated that SOAP:mustUnderstand=1 on a
> > > > ws-context means
> > > > > the
> > > > > receiver is required to understand the particular
> > > > context-type, not just that
> > > > > it is a ws-context.
> > > > >
> > > > >
> > > > >
> > > > > ------- You are receiving this mail because: -------
> > > > > You are the assignee for the bug, or are watching the assignee.
> > > >
> > > >
> > >
> >
> >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]