Re: [ws-caf] RE: close issue 134?

["Mark Little" <mark.little@arjuna.com>]

Alastair, I think addressing the current set of open issues directly may
resolve some of your points. One way of tackling all of this would be to
open up the floor to general debate and discussion. However, I don't think
that will be ultimately useful. I'd propose keeping to the existing f2f
schedule and address all open issues first and foremost and then, time
allowing, revisit anything that you (or anyone) thinks is still outstanding.

As for the status/completion status, I think the general concensus at
yesterday's meeting was that a string should be sufficient for now. If it
turns out not to be, then we can always change it in a later version.

Mark.

----- Original Message -----
From: "Green, Alastair J." <Alastair.Green@choreology.com>
To: "Mark Little" <mark.little@arjuna.com>; "Doug Bunting"
<Doug.Bunting@Sun.COM>
Cc: "Furniss, Peter" <Peter.Furniss@choreology.com>; "ws-caf"
<ws-caf@lists.oasis-open.org>
Sent: Tuesday, July 13, 2004 2:10 PM
Subject: RE: [ws-caf] RE: close issue 134?


> I presume we can discuss this issue today at the F2F. It is consonant
> with a number of Peter's outstanding issues. In a previous post I raised
> the point that the issue of children contexts either makes a
> must-understand per context necessary, or may obviate it (depending on
> where children contexts end up: in or out).
>
> In general, I am concerned about the approach that says: "we can foresee
> that some referencing (extending) specifications may need something like
> this element (although we cannot be sure how they will use it, or what
> its content will be, or whether all contexts will need it), so therefore
> we should include it in the base context."
>
> I incline to the view that the base context should only contain those
> elements which must be used by all contexts, and whose meaning is not
> dependent on a subsequent extension or referencing specification.
>
> This also has implications for the meaning of the complete message.
>
> Another way of putting this would be: the WS-Context spec should be
> independently useful, and not be laden down with lots of optional fields
> that might only come into play with *some* referencing specs. Otherwise
> we run the risk of trying to half-define a subset of the universe of
> future referencing specs.
>
> This discussion might also be aided by the examination of WS-CF and
> WS-TXM specs as examples of referencing specs. They tend to "do their
> own thing", and I think this reflects the reality that their
> requirements are specific.
>
> Another case that bears on this is the status type and completion status
> type. What if the element used for completion status in a referencing
> spec is a complex type? Is it right to restrict the base type to a
> string? And is it clean to end up with the moral equivalent of
> java.lang.Object, where we have
>
>     <wrapper>
>         <type/>
>         <contents/>
>     </wrapper>
>
> in various places?
>
> Wouldn't it be better to allow the referencing spec to define its own
> signals and their fields in its own, natural way?
>
> Another related example on the signals front: in BTP there is a control
> protocol, which allows differential coordination. If a client issues a
> PREPARE_INFERIORS or a CANCEL_INFERIORS then the signal PREPARE or
> CANCEL is transmitted on to a defined sub-set of participants. The same
> applies to the completion signal CONFIRM_TRANSACTION, which can cause
> CONFIRM to go to some inferiors, and CANCEL to others.
>
> Alastair
>
> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com]
> Sent: 13 July 2004 09:44
> To: Doug Bunting
> Cc: Furniss, Peter; ws-caf
> Subject: Re: [ws-caf] RE: close issue 134?
>
> > I am not sure what you mean in your last sentence since it seems to be
> > missing a verb.  However, I believe you have a reasonable summary in
> your
> > middle paragraph.  My summary might have been a tad more general
> (avoiding
> > specific solutions):
>
> Put it down to typing dyslexia.
>
> Mark.
>
> >
> > "Should the WS-Contest specification (or schema) provide an in-line
> > mechanism for identifying which added content must be understood?"
> >
> > Generalizing the question allows for either a global attribute for use
> on
> > any extended content or a local attribute on the container itself
> (which
> > might repeat).  And, yes Peter, we have a question for the "by
> reference"
> > case since it is unclear (a priori) who all might see a particular
> context
> > structure and therefore what each "viewer" must understand.
> >
> > thanx,
> > doug
> >
> > On 12-Jul-04 08:27, Mark Little wrote:
> > > Doug, in fact I think that's where the idea of the context
> mustUnderstand
> > > originally came from. So let's see if I can summarise this as an
> issue
> (and
> > > feel free to correct/augment):
> > >
> > > should the extensibility element have mustUnderstand associated with
> it?
> > >
> > > Or are you mustUnderstand for more elements in the context
> structure?
> > >
> > > Mark.
> > >
> > > ----- Original Message -----
> > > From: "Doug Bunting" <Doug.Bunting@Sun.COM>
> > > To: "Furniss, Peter" <Peter.Furniss@choreology.com>
> > > Cc: "Mark Little" <mark.little@arjuna.com>; "ws-caf"
> > > <ws-caf@lists.oasis-open.org>
> > > Sent: Monday, July 12, 2004 4:24 PM
> > > Subject: Re: [ws-caf] RE: close issue 134?
> > >
> > >
> > >
> > >>Peter and Mark,
> > >>
> > >>Issue 129 did not "remove mustUnderstand entirely" but instead
> dropped a
> > >>WS-Context specific description of this SOAP attribute.  We deferred
> any
> > >>specific semantics or requirements for this attribute to the
> referencing
> > >>specification, if that proves necessary.
> > >>
> > >>For issue 134, I believe we still need a ctx:mustUnderstand
> attribute
> > >>because soap:mustUnderstand does not address understanding of
> information
> > >>extending the base WS-Context structure.  We have an extensibility
> point
> > >>that may contain information that both sides must understand but may
> also
> > >>contain information of interest primarily to one side only.  While I
> can
> > >>imagine that many referencing specifications would clarify where
> > >>information might be added that is of interest only to one side
> (say,
> > >>internal references you need when processing the set of related
> messages
> > >>defined for a context type), I do not think it appropriate to
> require
> full
> > >>a priori knowledge of this important facet.  As a general practise,
> > >>extensibility points should support in-band identification of the
> content
> > >>that must be understood.
> > >>
> > >>thanx,
> > >>doug
> > >>
> > >>On 06-Jul-04 05:59, Furniss, Peter wrote:
> > >>
> > >>>Mark,
> > >>>
> > >>>Just to be clear, there are (or were) two mustUnderstand attributes
> > >>>referred to in 0.3-and-earlier  - one defined in SOAP, which the
> WS-CTX
> > >>>spec said had to be ="true", and one defined in ws-context schema
> as an
> > >>>attribute of participating-services-list, alongside the
> mustPropagate
> > >>>attribute.
> > >>>
> > >>>129 concerned only the SOAP one.
> > >>>134 concerned mostly the ws-context:mustUnderstand, and a passing
> > >>>mention of mustPropagate. The latter was removed by 131.
> > >>>
> > >>>I am pleased at this resolution.
> > >>>
> > >>>Peter
> > >>>
> > >>>    -----Original Message-----
> > >>>    *From:* Mark Little [mailto:mark.little@arjuna.com]
> > >>>    *Sent:* 06 July 2004 13:45
> > >>>    *To:* Furniss, Peter; ws-caf
> > >>>    *Subject:* Re: [ws-caf] RE: close issue 134?
> > >>>
> > >>>    Yes, 129 removes mustUnderstand entirely and 134 does likewise
> with
> > >>>    mustPropagate.
> > >>>
> > >>>    I'll mark the issue as closed and refer to those other issues.
> > >>>
> > >>>    Thanks,
> > >>>
> > >>>    Mark.
> > >>>
> > >>>        ----- Original Message -----
> > >>>        *From:* Furniss, Peter
> <mailto:Peter.Furniss@choreology.com>
> > >>>        *To:* Mark Little <mailto:mark.little@arjuna.com> ; ws-caf
> > >>>        <mailto:ws-caf@lists.oasis-open.org>
> > >>>        *Sent:* Tuesday, July 06, 2004 1:40 PM
> > >>>        *Subject:* [ws-caf] RE: close issue 134?
> > >>>
> > >>>        Yes, if I understand the intent correctly
> > >>>
> > >>>        129 concerned the SOAP:mustUnderstand attribute in
> > >>>        ws-context:context elements in SOAP Headers. The resolution
> of
> > >>>        129, as I understand it, will be to remove any specific
> > >>>        statement about the SOAP:mustUnderstand (it may note that
> the
> > >>>        attribute is available and can have either value, as is
> normally
> > >>>        the case for SOAP Header elements.
> > >>>
> > >>>        134 concerned the wsctx:mustUnderstand attribute which was
> > >>>        (incorrectly) defined as an attribute of
> > >>>        participating-services-list. I assume the intent is to
> remove
> it
> > >>>        completely. If that is the intent, I concur.
> > >>>
> > >>>        Peter
> > >>>
> > >>>            -----Original Message-----
> > >>>            *From:* Mark Little [mailto:mark.little@arjuna.com]
> > >>>            *Sent:* 06 July 2004 12:24
> > >>>            *To:* Furniss, Peter; ws-caf
> > >>>            *Subject:* close issue 134?
> > >>>
> > >>>            Peter, I believe that this issue
> > >>>
> > >
> > > (http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=134)
> > >
> > >>>            is no longer required because of the resolution to
> issues
> > >>>            129 and 131. Since you raised it I wanted to check
> before
> > >>>            doing anything (or proposing to do anything).
> > >>>
> > >>>            Mark.
> > >>>
> > >>
> > >
> >
>
>