- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Fri, 3 Oct 2003 09:33:52 +0600
- To: "Roberto Chinnici" <Roberto.Chinnici@Sun.COM>
- Cc: "Amelia A. Lewis" <alewis@tibco.com>, <jeffsch@windows.microsoft.com>, <www-ws-desc@w3.org>
"Roberto Chinnici" <Roberto.Chinnici@Sun.COM> writres:
>
> My observation then is that the versions with infault/outfault
> are much easier to understand: you can tell at a glance in
> which direction the faults are flowing. Using just "fault"
> everywhere obfuscates this important piece of information.
I do not disagree that there's more immediate information with
infault/outfault vs. fault. It seems to me that the 80-20 usage
will be outfault (even for MTF rules ... as those will likely
appear in one-way scenarios) and hence the concern about the
redundant naming.
Another possibility is to use a syntax like this:
<operation ..>
<input>
<message reference="xs:NCName" body=".." ../>
<fault reference="xs:NCName" details=".."/>
</input>
<output>
<message reference="xs:NCName" body=".." ../>
<fault reference="xs:NCName" details=".."/>
</output>
</operation>
Faults appearing inside would be infaults etc.. The bad thing
with this is that the fault associated with the input incoming
ref is actually inside the output element and vice versa .. not
quite intuitive.
I'll try to summarize later today for normal people to follow.
Sanjiva.
Received on Thursday, 2 October 2003 23:34:22 UTC