RE: Issue 140 bogus?

Hi Jacek,

Following todays telcon I thought that I would reformulate the proposal I
had for closing Issue 140 into a single informative sentence, avoiding MAY
(and may), targetted for inclusion in Part 1 Section 4.2.2 either
immediately before or after the current last paragraph of that section:

"A SOAP Node determines whether it plays a particular actor role with
respect to a particular message being processed based on an number of
factors including, but not restricted to (and in no particular order): local
configuration information; the receiving transport endpoint address; the
message content; other implemenation dependent factors."

I continue to have a preference that the spec. say something informative
like this, however I could live with a resolution that required information
the determination of aactor role be presented in the primer.

Best regards

Stuart

> -----Original Message-----
> From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
> Sent: 03 October 2001 18:15
> To: 'Jacek Kopecky'
> Cc: David Fallside; xml-dist-app@w3.org
> Subject: RE: Issue 140 bogus?
> 
> 
> Hi Jacek,
> 
> 
> > -----Original Message-----
> > From: Jacek Kopecky [mailto:jacek@idoox.com]
> > Sent: 03 October 2001 14:41
> > To: Williams, Stuart
> > Cc: David Fallside; xml-dist-app@w3.org
> > Subject: RE: Issue 140 bogus?
> > 
> > 
> >  Yes, my text was more a primer-speak (I think), your text is
> > more spec-speak. 8-)
> >  The information about Actor URIs seems to be scattered now, both
> > sections 2.2 and 4.2.2 contain some of it, maybe some
> > consolidation is necessary.
> 
> Yep...
> 
> >  Other than that, I tend to prefer putting the actor-choosing
> > discussion note in the primer and not in the spec, as it
> > basically says "you can do anything you will". I don't think such
> > a section belongs to the spec which is mant to set rules.
> 
> My preference is still that the spec. say something rather 
> than nothing.
> 
> 
> >  Let's see what the telcon brings. 8-)
> 
> Sure... 
> > 
> >                             Jacek Kopecky
> > 
> >                             Idoox
> >                             http://www.idoox.com/
> 
> Stuart
> --
> 
> > 
> > 
> > 
> > On Wed, 3 Oct 2001, Williams, Stuart wrote:
> > 
> >  > Hi Jacek,
> >  >
> >  > > -----Original Message-----
> >  > > From: Jacek Kopecky [mailto:jacek@idoox.com]
> >  > > Sent: 03 October 2001 10:55
> >  > > To: Williams, Stuart
> >  > > Cc: David Fallside; xml-dist-app@w3.org
> >  > > Subject: RE: Issue 140 bogus?
> >  > >
> >  > >
> >  > >  Stuart,
> >  > >  so it seems that to resolve your issue #140 you'd like to see
> >  > > some informative discussion on the bases for determining the
> >  >                                      ^^^^^basis
> >  > > Actor URI set of the node for this message, right?
> >  >
> >  > Just about right! I'm less interested in enumerating the 
> > set of Actor URIs
> >  > than I am in discussion of the possible basis upon which a 
> > SOAP Node decides
> >  > that it performs the role of a particular actor with 
> > respect to a given
> >  > message. Enumerating the set and testing for set 
> > membership certainly would
> >  > do.
> >  >
> >  > >  I may try to propose a first draft of such a discussion. Below
> >  > > is what I would say taking into account my SOAP building
> >  > > experience:
> >  > >
> >  > > ------- begin
> >  > >  The set of Actor URIs that the node assumes for processing a
> >  > > message can come from various sources:
> >  > >
> >  > >  - the Specification: ".../next" is always in the set
> >  > >  - static configuration for a combination of the endpoint URL,
> >  > > SOAPAction URI (when applicable), even first Body child's qname
> >  > > or an other part of the message.
> >  > >  - dynamic configuration based on some (as yet 
> unknown) extension
> >  > > whose SOAP block would carry the necessary information.
> >  > >
> >  > >  This set could include the empty Actor URI which 
> would mean that
> >  > > this node is the final receiver of the message.
> >  > > ------- end
> >  > >
> >  > > This is a very first rough draft of what I think might satisfy
> >  > > issue #140. Stuart, others, is this a good proposal? 8-)
> >  >
> >  > I've a slightly different suggestion, but I think the 
> > spirit is the same.
> >  > Something like the following at the end of Section 4.2.2 
> > in Part 2 would
> >  > work for me. This may need a little work by the editors, 
> > the first two items
> >  > tersely restate what is in the 3rd to last and 2nd to last 
> > para of the
> >  > current 4.2.2. The last item is the informative item which 
> > I think would
> >  > cover what I think is missing. Stylistically the MAY may 
> > not be the right
> >  > way to 'tack' this on to the list...
> >  >
> >  > ---being
> >  > In determing whether a SOAP Node performs the role of a 
> > particular actor
> >  > with respect to SOAP message that is being processed, a 
> SOAP Node:
> >  >
> >  > 	- MUST always performs the role of the ".../next" actor.
> >  > 	- MUST never perform the role of the "../none" actor.
> >  > 	- MAY make a determination based upon such factors as:
> >  > 		local configuration information;
> >  > 		the receiving transport endpoint address;
> >  > 		the message content (covers dynamic content and 1st body
> >  > child);
> >  > 		any other implemenation dependent factors;
> >  > ---end
> >  >
> >  > >
> >  > > As for where to put it, I think that as a non-normative
> >  > > discussion it could fit very well into the primer. 8-)
> >  >
> >  > The primer might want to expand on it by example. 
> > Personally I continue to
> >  > think that the spec should offer something. Part 4.2.2 
> > seems like thre right
> >  > place to me, but I'll go with the flow.
> >  >
> >  > >
> >  > > It's on the agenda today, so we can propose some draft 
> resolution
> >  > > during the telcon. 8-)
> >  > >
> >  > >                             Jacek Kopecky
> >  > >
> >  > >                             Idoox
> >  > >                             http://www.idoox.com/
> >  >
> >  > Regards
> >  >
> >  > Stuart
> >  >
> > 
> > 
>

Received on Wednesday, 3 October 2001 17:42:20 UTC