RE: are fault-replaces-message (FRM) and message-triggers-fault ( MTF) equivalent

Hi Amy,

Thanks for the clarification. Please see my comments marked with <kevinL>

Best Regards,
Kevin

From: Amelia A. Lewis [mailto:alewis@tibco.com] 
> But with the introduction of multi-in and multi-outs, it might be
> becoming confusing now. The meaning seems maybe different based on the
> pattern. (e.g, for an in-out pattern, it may still mean alternatives,
> but for in-multi-out, it's unclear) 

Sorry, I don't see why this is the case.  We currently have no
"multi-in" or "multi-out" patterns in our part two.  
If someone can comeup with a situation in which different faults are generated for the same
messageReference in a fashion that *needs to be described in WSDL*, then
I will stand corrected and humbled.  I don't see it.  I don't see it at
*all* with the current set of patterns; I don't see that one could
easily generate a pattern or set of patterns in which there is a
different semantic than "alternative" for multiple faults associated
with a single messageReference.  But if someone can, let's talk about
it.

<kevinL>
Are you suggesting to formally remove section 3.4 and 3.9 for the to-be-published working draft? The multi patterns are still "conditionally" retained in part 2 spec, and if such patterns are used, the meaning of multiple faults within one operation is not clear. 

I am not intended to champion the multi patterns since I don't say any real use cases for them. To the opposite, it seems to me that the lack of clarity can be another reason to remove them from the spec.
</kevinL>
 

> BTW, I just finished reading the part 2 spec and my impression is that
> this difference is not efficiently expressed, especially since the
> scenario you described below is not included in the spec. Would it be
> nicer for the readers if we can add your example to the spec?

If someone would like to propose the MTF request/response (with multiple
nodes) as a pattern, I'm certainly willing to write it up and include it
on the direction of the WG.  Having been the pushy b***h who got several
patterns in *already*, I think that perhaps someone else should push for
that one, if they see value in it.  I have no problem in offering a
writeup, if that would help, but I'm not going to be the one to make the
proposal that it be included.

As to the difference ... this is the difference between MTF and FRM?  I
think that you are probably correct.  

<kevinL> 
Yes, I meant the difference between MTF and FRM. 

If people in the WG was not able to see the subtle differences between the two rulesets (as indicated by the suggestions to merge them) without the "MTF request/response (with multiple nodes)" scenario, I will not be surprised to see that the general readers will be more confused. 

I don't think that we have to define a new pattern to offer the clarification.  The patterns provided in part 2 is not an exhaustive list, and others are free to define their own patterns. The fault rulesets are intended to work for all potential patterns, right? If that's the case, we can just offer some rationale text in section 2.
</kevinL>


The thing that I would like to add to the part two spec would be brief narrative descriptions of use cases
and applicability for each pattern, no more than a couple sentences each.

<kevinL> 
that would be really helpful, too.  Looking forward to seeing it in the part2 draft.

Some diagrams illustrating the direction and cardinality of each pattern should also be helpful. The pattern task force provided a set of diagrams for each pattern a little while ago [1], why should we hide them from the general readers? If the editors are interested, I can offer to provide an updated version of these diagrams for your use.

http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm 
</kevinL>

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 7 November 2003 19:04:41 UTC