Re: proposal for faults

Sanjiva Weerawarana wrote:
> "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 guess I could live with that. Infaults do seem rare, except when
you're writing down the conjugate of a in-out-with-fault operation.

>>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).

Hmmm, so you're saying that it behaves differently from the headers
attribute in <input body="..." headers="..."/>, right? I still don't
think it would be confusing, esp. if we can find a better name than
"detail(s)" for it.

I actually like the idea of listing all faults that are interchangeable
in the same place, I really don't see why giving them distinct
identities would be important to a WSDL author.

> (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.

You sure have!  ;-)

>>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.

I'm not following you very well here. The pattern will say, e.g., that
fault "F" can replace response message "B" in an interaction, period.
Based on the actual service being define, you can have countless
different application faults be mapped to "F", things like "invalid
employee ID" or "invalid SSN", or "salary out of range". The pattern
author couldn't possibly know about all these faults, from his pov "F"
is enough.

> If we go with your approach, do you also allow two different places
> in the pattern to use the same fault message reference name?

Off the top of my head no, at least not in fault-replaces-message mode.

> 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. 

But that seems to break the layering: patterns are defined independently
of the services that use them. Or perhaps I completely misunderstood
what defining a fault in a pattern means.

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

Don't read too much into it, it's just a byproduct of cut-and-paste.
Normally, I actually enjoy typing in long, mysterious URIs.  :-)

Roberto


>>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 14:47:57 UTC