Re: AI for more detailed faults.

I'm a little unclear on what you think we should be adding to core.  
You seem to be advocating that we define abstract faults in core and  
then bind them to SOAP faults in the SOAP binding doc - is that  
right ? FWIW, I don't think we really need to do that.

I expected a different form for your proposal, I was under the  
impression that you would be proposing some spec text to augment the  
existing Fault section in the SOAP binding - did I get that wrong ?

Thanks,
Marc.

On Jul 15, 2005, at 3:55 PM, David Hull wrote:

> Here's a more rigorous treatment of the ongoing proposal for more  
> detailed faults.  I've managed to fold together a few of the  
> cases.  I've also added a few faults defined in the SOAP binding.
>
> As before, there is open content everywhere for adding location and  
> other pertinent information.  All attributes and content are  
> optional.  There are no defaults.  If it's not there, we don't know  
> the value or we do but we're not telling.
>
> Please let me know if any of this is not clear.
>
> Detail Elements (pseudoschema) <!-- EPR problems -->  
> <MissingAddressInEPR @{any}>{any}*</MissingAddressInEPR>  
> <MalformedAddressInEPR @{any}> <badIRI>{any}*</badIRI>? {any}* </ 
> MalformedAddressInEPR> <!-- MAP problems (which in some cases stem  
> from EPR problems --> <MAPCardinality @propertyName={PropertyName}?  
> @inRequest={boolean}? @{any}> <ActualCardinality @role={string}> 
> {int}</ActualCardinality>* <!-- One per role, if need be, so  
> element, not attribute --> {any}* </MAPCardinality> <MalformedMAP  
> @propertyName={PropertyName}? @{any}> ( {MissingAddressInEPR} |  
> {MalformedAddressInEPR} | <MalformedIRI>{any}*</MalformedIRI> |  
> <NonAbsoluteIRI>{IRI}</NonAbsoluteIRI> )? {any}* </MalformedMAP>  
> <DuplicateMessageID @{any}> <MessageID>{IRI}</MessageID>? <!-- Same  
> as infoset in 3.2 --> {any}* </DuplicateMessageID> <!-- Faults  
> mentioned in the SOAP binding --> <MismatchedAction @{any}>  
> <SOAPAction>{IRI}</SOAPAction>? <WSAAction>{IRI}</WSAAction>? {any} 
> * <MismatchedAction> <DestinationUnreachable @{any}> <Destination> 
> {EPR}</Destination>? <!-- Same as infoset in 3.2 --> {any}* </ 
> DestinationUnreachable> <ActionNotSupported @{any}> <Action>{IRI}</ 
> Action>? <!-- Same as infoset in 3.2 --> {any}* </ 
> ActionNotSupported> <EndpointUnavailable @{any}> <Endpoint>{EPR}</ 
> Endpoint>? <RetryAfter>{unsignedLong}</RetryAfter>? {any}* </ 
> EndpointUnavaiable> <!-- This is a string, not a QName, on the  
> assumption that we're complaining about properties, not infoset  
> items --> PropertyName = "destination"|"source endpoint"|"reply  
> endpoint"|"fault endpoint"|"relationship"|"relationship type" Where  
> and how to use the above The EPR elements can be used in any fault  
> complaining about a bad EPR.  E.g., I give you an EPR to send some  
> sort of notification to, but its [address] is not well-formed.   
> You'll probably want to send me back a fault if possible.  If you  
> do, you can use wsa:MalformedAddressInEPR in the detail for that  
> fault.  Similarly, anyone receiving a message with bad MAPs may use  
> the appropriate detail elements above.
>
> In terms of the places where we actually mandate a fault:
> In core section 3.3, we MUST fault if a request is missing a [reply  
> endpoint].  The detail should look like this:
> <MAPCardinality property="reply endpoint" inRequest="true">  
> <ActualCardinality>0</ActualCardinality> </MAPCardinality>
> In core section 3.3, we MUST fault if a request is missing a  
> [message id].  The fault will be as above, but with  
> property="message id".
> In SOAP Binding section 2.4 (and in more detail later in 4.2), we  
> MUST fault if a the wsa:Action of the message does not match the  
> SOAP http://www.w3.org/2003/05/soap/features/action/Action  
> property.  The detail should look like this:
> <MismatchedAction> <SOAPAction><!--Value of SOAP property--></ 
> SOAPAction> <WSAAction><!--Value of WSA MAP--></WSAAction> </ 
> MismatchedAction>
> In SOAP Binding section 3.2, we MUST fault if there is more than  
> one To, ReplyTo, FaultTo, Action or MessageID targeted at a  
> recipient.  Suppose, for example, there is one ReplyTo targeted at  
> "role1" and one targeted at "role2", and the recipient is playing  
> both roles.  The detail should look like this:
> <MAPCardinality property="reply endpoint"> <!-- inRequest might be  
> true, false or absent --> <ActualCardinality role="role1">1</ 
> ActualCardinality> <ActualCardinality role="role2">1</ 
> ActualCardinality> </MAPCardinality>
> SOAP Binding section 5.3 defines the InvalidAddressingHeader detail  
> element.  This should be allowed to have any of MAPCardinality,  
> MalformedMAP, DuplicateMessageID and MismatchedAction as child  
> element.
> SOAP Binding section 5.4 defines the  
> MessageAddressingHeaderRequired detail element.  There are at least  
> three possible approaches here:
> Remove it in favor of InvalidAddressingHeader with MAPCardinality  
> children. ("children", not "child", as the receiver might be  
> playing multiple roles, none of which supplies the header.  The  
> role attribute on the ActualCardinality element captures this).
> Allow it to have MAPCardinality children.
> Try to add the information that MAPCardinality conveys (in this  
> case, mainly which roles were active) to  
> MessageAddressingHeaderRequired directly.
> SOAP Binding section 5.5 defines the DestinationUnreachable subcode  
> with no detail element.  This should allow the  
> DestinationUnreachable detail element, to show what destination we  
> thought we were trying to reach.
> SOAP Binding section 5.6 defines the ActionNotSupported detail  
> element.  This looks fine, except that it should probably allow for  
> open content like everything else, as shown above.
> SOAP Binding section 5.7 defines the EndpointUnavailable subcode,  
> with the RetryAfter detail element.  I've folded this into an  
> EndpointUnavailable detail element with open content and a slot for  
> the offending endpoint.
> And it looks like that's it.
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.