Re: Issue 7 convo from Melbourne

* Jonathan Marsh <jmarsh@microsoft.com> [2005-02-21 15:16-0800]
> 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?

I agree that this is confusing and that we would benefit from having
distinct names for properties in each bag. This is an orthogonal — and
hopefully straightforward and editorial — issue though.

> 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.

That's a good point. Actually, an interesting question is the
following: since reference parameters (I assume you meant parameters
above) are serialized as SOAP headers for processing by the SOAP
processing model, is there any point doing any particular processing
at the Addressing level?

I believe that the answer is yes, as they are particular headers that
have been tagged as such per the result of i008. In particular, we may
want to add a note about that.

Also, in the spirit of Glen's comments about targeting, I think that
we need to specify that we're dealing with headers targeted to a
particular node.

Here is a version 2 of my proposal (reordered, improved, and
condensed):

1. 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.

2. 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. Each SOAP header block resulting from a [reference parameters]
       is annotated with a wsa:Type attribute whose value is
       "parameter".

3. 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
 targeted at the node which matches the XML Infoset
 representation described in Core section 3.1.

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

     3. The SOAP header blocks annotated with a wsa:Type attribute
 whose value is "parameter" targeted at the node are processed
 as normal SOAP headers as per SOAP processing model. Note that
 these headers are resulting from the serialization of an EPR's
 [reference parameters] property, and may require additional
 security and sanity checks by the SOAP received.

I believe that this addressing point 2) of Glen's proposal[3], and can
be the basis for the other points.

Cheers,

Hugo

  3. http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0011.html
-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/