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 13:15:01 UTC