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.
 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.
 Let's see what the telcon brings. 8-)

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



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 09:41:07 UTC