Re: LC 76 - What makes a msg WS-A?

Martin Gudgin wrote:

>  
>
>     ------------------------------------------------------------------------
>     *From:* David Hull [mailto:dmh@tibco.com]
>     *Sent:* 14 July 2005 16:32
>     *To:* Martin Gudgin
>     *Cc:* Katy Warr; public-ws-addressing@w3.org
>     *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>     Is this really a question of how to support both WSA and old-style
>     HTTP requests on the same endpoint?  
>     [MJG] I don't know, I didn't ask the original question.
>
Hmm ... my message was in-reply-to yours, but the question was really
aimed more at Katy.  Maybe we need BPEL here :-).

>
>       I.e., if I don't see any WSA headers at all, I assume it's an
>     old-style request and act accordingly, but if I see anything WSA,
>     I follow the rules in section 3? 
>     [MJG] I guess one could do that...
>
Well, one should do /something/ to ensure that old-style requests are
accepted as such.

>
>     The tricky bit is that, since MAPs like [destination] and [reply
>     endpoint] can default, a message with no wsa: elements on the wire
>     could still be assigned values for some of its MAPs, since the
>     /infoset/ will still have values for the corresponding elements. 
>     [MJG] Which Infoset are you talking about? The XML Infoset has no
>     such values.
>
Sorry, I didn't get that quite right.  I was going by section 3.2,
particularly the descriptions of wsa:To:

    This OPTIONAL element (whose content is of type xs:anyURI) provides
    the value for the [destination] property. If this element is NOT
    present then the value of the [destination] property is
    "http://www.w3.org/@@@@/@@/addressing/anonymous".


(and similarly for wsa:ReplyTo). I initially misread this as stating
that the element defaulted, as opposed to the MAP.  So s/since the
/infoset/ will still have values for the corresponding elements/since
the properties are defaulted in the absence of the corresponding
elements in the infoset/.  This sort of confusion could be seen as an
argument against the two-layered approach (or simply as an argument that
I read too quickly).

In any case, you can't simply look at the abstract properties and say
"some WSA properties are defined, so it's a WSA message".

>
>        So either we have to drop down to look at the infoset level,
>     and in particular at the non-defaulted elements in the infoset, or
>     we have to find some marker that can't be defaulted away.  This is
>     why the [action] property looks significant here.  But on the
>     other hand, what if I include a wsa:ReplyTo element and no
>     action?  By the "it's WSA iff [action] is present" rule, that's
>     not a WSA message and therefore not an error.  This seems wrong. 
>     [MJG] Why does it seem wrong?
>
It seems wrong not to fault for a message that contains a wsa:ReplyTo on
the wire but not a wsa:Action.

>
>     Put another way, when would one get a fault for omitting [action]? 
>     [MJG] Whenever another wsa: header is present in a message.
>
In other words, the answer to your question ("Given that the wsa:Action
is mandatory, isn't it the presence of that header?") is "No."

This is why at the Berlin meeting we tried to make sure that all the
possibilities were covered for various combinations of the MAPs.  I
believe we've satisfied ourselves that they are, but perhaps we need to
revisit this work?

>      
>
>     Martin Gudgin wrote:
>
>>     Given that the wsa:Action is mandatory, isn't it the presence of
>>     that header?
>>      
>>     Gudge
>>
>>         ------------------------------------------------------------------------
>>         *From:* public-ws-addressing-request@w3.org
>>         [mailto:public-ws-addressing-request@w3.org] *On Behalf Of
>>         *Katy Warr
>>         *Sent:* 14 July 2005 16:07
>>         *To:* public-ws-addressing@w3.org
>>         *Subject:* LC 76 - What makes a msg WS-A?
>>
>>
>>         Please could we discuss the following in the context of LC76?
>>
>>         When is an incoming message deemed to be a WS-Addressing
>>         message and therefore subject to the appropriate
>>         WS-Addressing validation?   Is it based on the presence of
>>         any WS-addressing Message Addressing Property?  For example,
>>         does a message containing a reference parameter (but no other
>>         WS-Addressing information) need to result in a
>>         MessageAddressingHeaderRequired?    Or, for example, does the
>>         declaration of the wsa namespace rendor the message
>>         WS-Addressing?
>>
>>         Thanks
>>         Katy
>>
>