Re: Issue 7 convo from Melbourne

* Glen Daniels <gdaniels@sonicsoftware.com> [2005-02-04 07:55-0500]
> At the F2F in Melbourne, we got into a discussion of issue 7 (processing
> model for WSA SOAP headers) which resulted in some new
> thoughts/questions.  I took an action to facilitate moving the
> conversation forward, and as such this email will bring out some of the
> points I believe we covered in the conversation there, and hopefully
> encourage further discussion.
> 
> The issue involves the processing model for the WSA SOAP headers, and
> there has already been a great thread about this beginning at [1].
> 
> The first part of this involves the specification of just what a node
> should do when processing the WSA headers in a received message.  I
> believe we should at a minimum specify (which we don't quite at present)
> that processing the WSA headers has the result of filling in the
> abstract message properties appropriately at the processing node.

Actually, the SOAP binding is currently not really defined in terms of
binding abstract message properties.

The SOAP binding is written in terms of binding of EPRs (section 2.
Binding Endpoint References[0]) and has text which looks like taken
from reply rules:

   The SOAP binding for endpoint references is defined by the following
   three rules:

     * The [address] property in the endpoint reference is copied in the
       [destination] message information property. The infoset
       representation of the [destination] property becomes a header block
       in the SOAP message.

     * Each [reference parameter] element becomes a header block in the SOAP
       message. The element information item of each [reference parameter]
       (including all of its [children], [attributes] and [in-scope
       namespaces]) is to be added as a header block in the new message.

     * Each header block added as a result of the above rule is annotated
       with a wsa:Type attribute whose value is "parameter".

AFAICT, nowhere is explained in the binding how to bind the rest of
the message addressing properties, which is actually what we want to
bind. The binding concentrates on [destination] and [reference
parameters], leaving out all the others.

And as you say, this only concentrates on the sending of a SOAP
message, not the receiving of one.

I would propose making the 4 changes to address the first part of your
issue:

1. Define the following as the first rule of the SOAP binding when
   _sending_ a message:

    1. All the message addressing properties are serialized as SOAP
       header blocks using their XML Infoset representation defined in
       Core section 3.1 XML Infoset Representation of Message
       Addressing Properties[2].

This covers and completes the first of the three rules currently
expressed. The two others are about the serialization of reference
parameters.

Note: as part of the resolution of issue i044, we should have added
[reference parameters] as a message addressing property. I am saying
"should" here as I proposed it as part of the resolution (see my note
at the end of [3]) and I realized that it wasn't explicit in my final
email[4] though I'm using it in the proposed text. So, my proposed
resolution for i044 which was accepted relied on [reference
parameters] being a message addressing property, which I'll use here
too.

I think that we will need to Core's section 3.1 their XML Infoset
representation. Therefore, to complete the addition of [reference
parameters] started in issue i044, I further propose to:

2. Make the [reference parameters] message addressing property's XML
   Infoset representation in Core's section 3.1 the following, which
   was the second rule of the SOAP binding:

    /[reference parameters]*

     Each element information item of found in [reference parameters]
     (including all of its [children], [attributes] and [in-scope
     namespaces]) is represented as is.

I struggled with how to express this one the right way, so the text
may be improved.

3. Add the following second rule to the SOAP binding of the MAPs when
   sending a message:

    2. Each SOAP header block resulting from a [reference parameters]
       is annotated with a wsa:Type attribute whose value is
       "parameter".

Another way to go around this would be to simply have the wsa:Type
annotation be part of section 3.1 in the core and limit the SOAP
binding to rule 1 above. I'm ambivalent on this.

4. Add the following rules when _receiving_ a SOAP message:

     1. The value of each message addressing property takes the value
	from the corresponding SOAP header block in the wsa namespace
	which matches the XML Infoset representation described in Core
	section 3.1.

     2. Each SOAP header block annotated with a wsa:Type attribute
	whose value is "parameter" is added to the content of the
	[reference parameters] MAP.

Again, if the wsa:Type annotation is part of the core, then rule 2
goes away.

Comments?

Cheers,

Hugo

  0. http://www.w3.org/TR/2005/WD-ws-addr-soap-20050215/#_Toc77464317
  2. http://www.w3.org/TR/2005/WD-ws-addr-core-20050215/#_Toc77464323
  3. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0004.html
  4. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0091.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/