W3C home > Mailing lists > Public > public-ws-addressing@w3.org > September 2005

Re: FW: New Issue: SOAP Binding CR ([Details] for wsa:ActionMismatch Subsubcode)

From: Hugo Haas <hugo@w3.org>
Date: Mon, 19 Sep 2005 21:03:50 +0200
To: Jonathan Marsh <jmarsh@microsoft.com>
Cc: public-ws-addressing@w3.org
Message-ID: <20050919190350.GA12690@w3.org>
Hi Jonathan.

* Jonathan Marsh <jmarsh@microsoft.com> [2005-08-29 15:19-0700]
[…]
> This redundancy represents needless complication.  I propose we keep
> <wsa:ProblemHeader> and <wsa:ProblemHeaderQName> for consistency and to
> enable "dumber" conveyance of this information, and strip down
> <wsa:ProblemAction>.  (I fix another problem as well - that
> was:ProblemAction/wsa:SoapAction doesn't seem to be extensible which is
> inconsistent with other elements we define.)

I was looking at your proposal from the perspective of other fault
subcodes, in particular wsa:InvalidAddress.

> I propose we replace the following sections:
[…]
> With:
> 
> 
> 5.3.4 Problem SOAPAction
> 
> 
> The following describes the <wsa:ProblemSOAPAction> element:
> 
> /wsa:ProblemSOAPAction 
> 
> An optional element that provides the SOAPAction IRI that caused the
> problem.
> 
> /wsa:ProblemSOAPAction/{any} 
> 
> Optional extensibility elements that do not affect processing.
> 
> /wsa:ProblemSOAPAction/@{any} 
> 
> Optional extensibility attributes that do not affect processing.
> 
> ...
> 
> 
> 5.4.1.6 wsa:ActionMismatch
> 
> 
> Specifies that the [action] and SOAPAction for the message did not
> match, [Details] MAY contain a <wsa:ProblemSOAPAction> element in
> addition to the <wsa:ProblemHeader> element or <wsa:ProblemHeaderQName>
> element.

wsa:InvalidAddress reads:

  Specifies that an [address] was invalid, [Details] MAY contain a
  wsa:ProblemIRI element in addition to the <wsa:ProblemHeader>
  element or <wsa:ProblemHeaderQName> element.

I was curious about why we suggest to use wsa:ProblemIRI for problems
with [address] in wsa:InvalidAddress, when you don't for [action] in
wsa:ActionMismatch. I believe that the answer is that
wsa:ProblemHeader can already be used to carry the information that
wsa:ProblemIRI would contain.

So wsa:InvalidAddress seems to have a similar redundancy issue, that
we could solve by removing wsa:ProblemIRI as a suggested content for
[Details].

BTW, I was wondering about the subtle difference between
wsa:InvalidAddress and wsa:DestinationUnreachable. Are we expecting to
use the former when the content of [address] is not an IRI as
expected? If so, this is another argument against wsa:ProblemIRI here
as the type of this element is anyURI.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Monday, 19 September 2005 19:03:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:09 GMT