RE: Question on section 2.7.1, Part 1

Noah,

As for the meta concern, my feeling is that we should focus on last call
issues unless we really think something is fundamentally broken. I agree
that the wording around roles could be clearer and I would be happy to
work on whatever we can do to improve the state of affairs.

FWIW, the semantics of roles is in my view fundamentally different from
that of header blocks and I don't see them being used interchangeably.
For example, it is not obvious how one would define a header block with
the semantics of the "ultimate receiver" role. It seems unfortunate if
the only reason such roles work is because they are baked into the spec.

Of course we can't prohibit the use of conflicting semantics in a SOAP
message. Whether features "make sense together" is outside our control.
All we can realistically do is defining the semantics of the extension
hooks, the rest is up to the extension designers and application
builders.

Henrik 

>-----Original Message-----
>From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
>Sent: Friday, October 04, 2002 18:53
>To: Henrik Frystyk Nielsen
>Cc: marc.hadley@sun.com; Martin Gudgin; moreau@crf.canon.fr; 
>Nilo.Mitra@am1.ericsson.se; www-archive@w3.org
>Subject: RE: Question on section 2.7.1, Part 1
>
>
>Meta concern: if we're going to pursue this discussion,
>I think we should take it to distApp.  So, let's decide
>that first.  Anyone who has contributed object to
>having their text copied to distApp if I decide to move
>it?
>
>Now, to ignore my own advice, a response:
>
>Henrik writes:
>
>
>>> Just to elaborate a bit on the explanation below: In
>>> order for a SOAP node to know that it can act in a
>>> certain role, it must understand the semantics of that
>>> role. For example, for the roles named in the SOAP 1.2
>>> spec, we define not only how they are identified but
>>> also the semantics of acting in those roles: Acting in
>>> the role of the ultimate receiver requires that you
>>> process the body and don't act as an intermediary and
>>> so on.
>
>This is where I'm not sure I agree.  I had always
>interpreted the ultimate receiver as a special case,
>that we baked into the spec as special for that reason.
>Your interpretation is coherent, but the spec certainly 
>declines to introduce any explicit notion of 'understanding' a 
>role, something with which we take great care for headers.
>
>
>>> The same is the case for roles not defined in SOAP 1.2 although we 
>>> don't say much about it in general. However, we at least recognize 
>>> this model in step one of the processing model where we require a
>>> SOAP Node to determine the set of roles in which the
>>> node is to act.
>
>Right, we don't say much, and determining a list of
>roles you play is arguably not the same as
>understanding a set of semantics that >> can change the 
>processing model for intermediaries as clearly described in 
>section 2.7.1.  So, I think your interpretation is not just 
>that knowing how to act in a role implies knowing the 
>semantics as conveyed in some spec for that role, but that 
>roles can in effect embody features!  I see this is a 
>fundamental structural 
>change.<<
>
>For that reason, I believe your proposal on a spec for
>the relay role would have to be rewritten to imply that
>any header addressed to that role would necessarily be
>in some sense understood and processed (because we're
>clear in 2.7.1 that it's processing that causes
>reinsertion.)  There would have to be 
>an implication that, whether or not you
>recognized the QName in any distinct sense, that you
>would infer that any such header had a processing
>semantic of "reinsert me if you choose not to do any
>other useful processing of me."  What's disturbing
>about that is that I might (admittedly erroneously)
>include a QName with a spec that says just the opposite
>and address it to relay. Then what? So, I don't think we
>have any precedent that roles implement features.
>Lacking that, I think that your proposed formuation of
>2.7.1 violates the spec, and would at best have to be
>replaced with something like I've proposed here.
>
>>> Any extensibility should obviously be designed with
>>> care and the best extensibility mechanism should be
>>> used for any particular extension. I am in no way
>>> saying that the extensibility of roles should be used instead of mU 
>>> but for the specific semantics you point out below, the notion of 
>>> roles does seem to be a useful fit, especially as "forwarding" is 
>>> itself a feature not defined in the SOAP 1.2 spec as described in 
>>> section 2.7.1.
>
>I remain nervous about the whole state of affairs.  Take it to distApp?
>
>Thanks.
>
>Noah
>
>------------------------------------------------------------------
>Noah Mendelsohn                              Voice: 1-617-693-4036
>IBM Corporation                                Fax: 1-617-693-8676
>One Rogers Street
>Cambridge, MA 02142
>------------------------------------------------------------------
>
>
>
>