RE: Issue 7 convo from Melbourne

A few comments on [reference parameters].

First of all, it might be less confusing to choose a different term
(e.g. [address] and [destination]) to make it easier to distinguish
between MAPs and EPR properties.  It would be nice not to have to
qualify [reference properties] whenever I use the term out of context.
Maybe [addressing headers] for the new MAP?

First of all, I would hope that by including the rule extracting
[reference properties|addressing headers] from a message that there is
no implication that all [reference properties] must of necessity be
reflected on the other end in [addressing headers].  All [reference
properties] turn into headers, the message is sent, but by the time it
gets to the destination some of the headers may have been "expended" by
intermediary processing and [addressing headers] has fewer items than
the original [reference properties] did.  It should be clear that
reference properties are different than the other MAPs in this sense.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Hugo Haas
> Sent: Friday, February 18, 2005 7:43 AM
> To: Glen Daniels
> Cc: public-ws-addressing@w3.org
> Subject: 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/

Received on Monday, 21 February 2005 23:16:49 UTC