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

FW: PROPOSAL: enhanced Fault information

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 19 Jul 2005 07:09:19 -0700
Message-ID: <7DA77BF2392448449D094BCEF67569A50845313F@RED-MSG-30.redmond.corp.microsoft.com>
To: <public-ws-addressing@w3.org>

Bad keystroke caused a send prematurely ...

The goal is to define a small number of consistently structured
elements, based on the type of the offending data returned.  Here's a
cut...

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws- 
> addressing-request@w3.org] On Behalf Of Rogers, Tony
> Sent: Tuesday, July 19, 2005 6:01 AM
> To: public-ws-addressing@w3.org
> Subject: PROPOSAL: enhanced Fault information
> 
> Here is what I compiled from David's proposals, and Marc's outline. It

> could be tidied up (editorial discretion), but the fundamentals seem 
> sound.
> 
> (Please excuse the disturbed formatting - for some reason my webmail 
> client decided everything was double-spaced.)
> 
> 
> (revised) General layout of the fault:
> 
> <Fault>
>   <Code><Value>sender</Value>
>     <Subcode><Value>wsa:InvalidAddressingHeader</Value>
>       <Subsubcode><Value>wsa:InvalidAddress</Value></Subsubcode>
>     </Subcode>
>   </Code>
>   <Detail>
>     <wsa:InvalidAddressingHeader>wsa:FaultTo
      </wsa:InvalidAddressingHeader>
>     <wsa:MalformedAddress>http:/foo</wsa:MalformedAddress>
>   </Detail>
> </Fault>
> 
> 
> 
> Additional text in Section 5 as follows - all are new subsections 
> under existing sections. Note that the [Detail] in the subsections is 
> appended to any [Detail] in the parent section.
> 
> 
> 
> Under 5.3 Invalid Addressing Header

  <wsa:BadHeaderQName>xs:QName</wsa:BadHeaderQName>?

> 
> 5.3.1 Invalid Address
> 
> The invalid header contains an invalid address - additional detail 
> specifies the invalid address
> 
> [Subsubcode] wsa:InvalidAddress
> 
> [Detail] a <wsa:MalformedAddress> element giving the content of the 
> faulty address
> 
>                 <wsa:MalformedAddress>any<wsa:MalformedAddress>
> 

  <wsa:BadIRI>xs:string</wsa:BadIRI>?

> 5.3.2 Invalid EPR
> 
> The invalid header contains an invalid EPR - additional (optional) 
> detail specifies the invalid EPR
> 
> [Subsubcode] wsa:InvalidEPR
> 
> [Detail] a <wsa:InvalidEPR> element containing the invalid EPR. Note 
> that the content is any because it may be structured
> 
>                 <wsa:InvalidEPR>any</wsa:InvalidEPR>

  <wsa:BadHeader>xs:any</wsa:BadHeader>?

> 5.3.3 Invalid Cardinality
> 
> The invalid header has an inappropriate cardinality - additional 
> detail specifies the actual cardinality by role.
> 
> [Subsubcode] wsa:InvalidCardinality
> 
> [Detail] a <wsa:InvalidCardinality> element containing a list of 
> <wsa:ActualCardinality/> elements
> 
>                 <wsa:ActualCardinality 
> role="anyURI">int</wsa:ActualCardinality>

  <wsa:BadCardinality>xs:positiveInteger xs:anyURI</wsa:BadCardinality>*

> 5.3.4 Missing Address in EPR
> 
> The invalid header contains an EPR which is missing an address - 
> additional detail specifies which address in the EPR is missing
> 
> [Subsubcode] wsa:MissingAddressInEPR
> 
> [Detail] a <wsa:MissingAddress> containing the name of the missing 
> address (such as "wsa:FaultTo")
> 
>                 <wsa:MissingAddress address="wsa:FaultTo"/>

  <wsa:BadHeaderQName>xs:QName</wsa:BadHeaderQName>?

> 5.3.5 Malformed Address in EPR
> 
> The invalid header contains an EPR which is missing an address - 
> additional detail specifies which address in the EPR is malformed
> 
> [Subsubcode] wsa:MalformedAddressInEPR
> 
> [Detail] a <wsa:MalformedAddress> containing the name of the missing 
> address (such as "wsa:FaultTo") and (optionally) the content of the 
> malformed address
> 
>                 <wsa:MalformedAddress
> address="wsa:FaultTo">anyURI</wsa:MalformedAddress>

  <wsa:BadIRI>xs:string</wsa:BadIRI>?

> 5.3.6 Duplicate Message ID
> 
> The invalid header contains a message ID which has already been used -

> additional detail specifies the message id in question
> 
> [Subsubcode] wsa:DuplicateMessageID
> 
> [Detail] a <wsa:DuplicateMessageID> containing the message id in 
> question
> 
> 
> <wsa:DuplicateMessageID><messageID>anyURI</messageID></wsa:DuplicateMe
> ssageID>

  <wsa:BadIRI>xs:string</wsa:BadIRI>?

> Under 5.4 Message Addressing Header Required
> 
> 
> 
> 5.4.1 Invalid Cardinality
> 
> The required message header which is missing has inappropriate 
> cardinality - additional detail specifies the actual cardinality, by 
> role, of this header
> 
> [Subsubcode] wsa:InvalidCardinality
> 
> [Detail] a <wsa:InvalidCardinality> element containing a list of 
> <wsa:ActualCardinality/> elements
> 
>                 <wsa:ActualCardinality 
> role="anyURI">int</wsa:ActualCardinality>

(Think this is a duplicate section that should be removed.)

> Under 5.5 Destination Unreachable
> 
> 
> 
> 5.5.1 Unreachable EPR
> 
> 
> 
> [Subsubcode] none
> 
> [Detail] a <wsa:ProblemEPR> element containing the name of the 
> offending EPR, and (optionally) its content
> 
>                 <wsa:ProblemEPR epr="wsa:ReplyTo">any</wsa:ProblemEPR>
> 

  <wsa:BadHeaderQName>xs:QName</wsa:BadHeaderQName>?
  <wsa:BadHeader>xs:any</wsa:BadHeader>?

> Under 5.6 Action Not Supported - nothing - no changes required

  <wsa:BadHeader>xs:any</wsa:BadHeader>
  (or)
  <wsa:BadIRI>xs:string</wsa:BadIRI>

> Under 5.7 Endpoint Unavailable
> 
> 
> 
> 5.7.1 Unavailable EPR
> 
> 
> 
> [Subsubcode] none
> 
> [Detail] a <wsa:ProblemEPR> element containing the name of the 
> offending EPR, and (optionally) its content
> 
>                 <wsa:ProblemEPR epr="wsa:ReplyTo">any</wsa:ProblemEPR>

  <wsa:BadHeaderQName>xs:QName</wsa:BadHeaderQName>?
  <wsa:BadHeader>xs:any</wsa:BadHeader>?
Received on Tuesday, 19 July 2005 14:09:40 GMT

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