Re: proposal for faults

"Roberto Chinnici" <Roberto.Chinnici@Sun.COM> writes:
> Our disagreement in that thread carries over to this one.

Yes, I expected that it would ;-).

> Plus, for consistency I think we should either keep input/output and
> infault/outfault or get rid of both and go with message/fault. (This
> keeping in mind that I'm not in favor of defaulting the "pattern"
> attribute on an operation.)

I also thought about the consistency issue, but I see the use of 
infault being rather rare .. and hence leaving those for non-trivial 
patterns to specify via messageReference names is acceptable to me.
If someone can show otherwise (that infaults are not rare) I'm 
happy to be convinced.

So in this case I'd like to break the consistency rule and go with
just "fault."

> I still don't see why you're arguing in favor of
> 
>   <fault messageReference="xs:NCName" details="xs:QName"/>
> 
> over
> 
>   <fault messageReference="xs:NCName" details="list of xs:QName"/>
> 
> Can you please explain? As I said in an earlier email, I can declare
> an arbitrary number of faults as replacements for a given message.

Glad to .. the semantic of the list would be that EXACTLY ONE of
them would appear at any given time, yes? My gut feeling when you
said "list of QNames" was that it would be all of them .. so for
one thing its not clear that the different faults are actually 
options. Furthermore, I think that's a bad way to indicate that
different faults may be thrown (see below).

(Now dusting off one of the anti-<message> arguments ;-)) Isn't 
this also in effect a way to define an <xsd:choice>??? If yes,
there's already a perfectly good XSD way of doing this and, um,
we shouldn't fight the XSD religion! You will be assimilated.
I have been.

> With your syntax, I'd be forced to write:
> 
> <definitions>
>    <interface name="if">
>      <operation name="op">
>        <input body="ns:foo"/>
>        <output body="ns:bar"/>*
>        <fault messageReference="response" details="ns:fault1"/>
>        <fault messageReference="response" details="ns:fault2"/>
>        <fault messageReference="response" details="ns:fault3"/>
>        <fault messageReference="response" details="ns:fault4"/>
>      </operation>
>    </interface>
>    <binding name="bind" interface="tns:if">
>      <operation name="tns:op">
>        <input/>
>        <output/>
>        <fault messageReference="response"/>
>        <fault messageReference="response"/>
>        <fault messageReference="response"/>
>        <fault messageReference="response"/>
>      </operation>
>    </binding>
> </definitions>
> 
> How would I then know which binding fault corresponds to which abstract 
> fault? And what does the ability to bind each fault separately buy you
> when they're all meant to replace the same message?

I think that's a "bad" pattern. If a pattern can result in differnt
faults, IMO it should name each one differently and in the pattern
description say clearly that only one of f1 .. fn will occur etc..
That way the WSDL mapping of a fault message reference to an actual
element has a unique mapping and its very clear what that means.

If we go with your approach, do you also allow two different places
in the pattern to use the same fault message reference name? I assume
not, yet you want to allow the same name to be used when one of many
different kinds of faults may be thrown. I'd prefer to keep it simpler
and force the pattern author to do more work. 

(BTW, I noticed that you took the shortcut I'm advocating and
defaulted @pattern in the fragment above ;-). See, your heart is
with it!!!)

> With the old syntax, we'd have this instead:
> 
> <definitions>
>    <interface name="if">
>      <operation name="op">
>        <input body="ns:foo"/>
>        <output body="ns:bar"/>*
>        <outfault messageReference="response" details="ns:fault1 
> ns:fault2 ns:fault3 ns:fault4"/>
>      </operation>
>    </interface>
>    <binding name="bind" interface="tns:if">
>      <operation name="tns:op">
>        <input/>
>        <output/>
>        <outfault messageReference="response"/>
>      </operation>
>    </binding>
> </definitions>
> 
> As you can see, at the binding level everything is clear.
> 
> Roberto

Yes, this approach does have the advantage of being able to refer
to multiple different faults that occur at logically the same "place"
in the pattern with a single name. I would prefer to put the 
extra pain on the pattern designer and keep the WSDL level simple
and say a fault message reference maps uniquely to a single element
just like regular message references.

Given that pattern authors are rare compared to WSDL authors, I 
think that's an ok trade-off.

Sanjiva.

Received on Wednesday, 1 October 2003 13:42:16 UTC