Re: Issue with binding message references in the abstract component model

Sanjiva Weerawarana wrote:
> Hi Roberto,
> 
> 
>>Following the WG's decision to rename the "name" attribute of the
>>wsdl:input and wsdl:output elements to "messageReference", and
>>correspondingly to rename the {name} property of the message
>>reference component to {messageReference}, we ended up with a
>>mismatch between the interface-level message reference components
>>and the binding-level ones.
>>
>>At the interface level, we have a message reference component with
>>a {messageReference} property and a fault reference component with
>>a {name} property. Although the latter needs more work to bring it
>>into the new brave message-free world, I assume we won't modify its
>>{name} property; unlike the old message reference component's {name},
>>the {name} of a fault reference component is indeed arbitrarily
>>chosen by the WSDL author and it doesn't depend on the MEP in use.
> 
> 
> I know I don't understand the fault rules etc. in the MEP stuff
> yet, but why doesn't the name matter for faults too? In a complex
> MEP there can be faults going in different directions etc. and 
> in such cases it seems to be necessary to say which fault I'm
> talking about when I indicate the actual message contents.

Good point, there are many questions surrounding faults.

It seems that when using "fault replaces message" you should be able to
specify (with @messageReference) which message the fault replaces; similarly,
in "message triggers fault", you would use @messageReference to say which
message can trigger this fault. But then, in both cases, you could have a
fault that replaces (or is triggered by) more than a message. Would we then
allow a @messageReferences (plural) attribute on infault/outfault or would we
require that you declare multiple faults, each with different values for
@messageReference? Also, how about the uniqueness of the "name" attribute --
should it be operation-wide (the status quo) or scoped to a message reference?

Hmmm, all these issues... I predict we'll see a spike in the price of beer
around Palo Alto next week... ;-)

> +1 to the proposal to rename binding/operation/(input|output)/@name
> to @messageReference.

Great, thanks!

Roberto

Received on Sunday, 21 September 2003 14:12:15 UTC