[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
> >>>
> >>
> >
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]