W3C home > Mailing lists > Public > www-ws-desc@w3.org > December 2006

re cr108; violating MessageLabel-0006

From: Amelia A Lewis <alewis@tibco.com>
Date: Thu, 14 Dec 2006 12:32:03 -0500
To: www-ws-desc@w3.org
Message-Id: <20061214123203.76e8b39b.alewis@tibco.com>


Following up.

BindingMessageReference-0060-summary:  For each Binding Message Reference  component in the {binding message references} property of a Binding Operation  component, the {interface message reference} property MUST be unique. (see 2.10.1).

MessageLabel-0006:  The messageLabel attribute information item  of a binding message reference element information item  MUST be present if the message exchange pattern has more than one placeholder message with {direction} equal to the message direction. (2.10.3).

MessageLabel-0014:  If the messageLabel attribute information item  of a binding message reference element information item  is absent then there MUST be a unique placeholder message with {direction} equal to the message direction.

Okay, let's pretend we have a pattern that looks like this: In, Out, In.  The labels are "Initial", "Output", and "Acknowledge".  Assume that the interface operation and its children pass the assertions in 2.5 (otherwise, the binding issues are irrelevant, by BindingMessageReference-0060-summary, which I will call "2.10.1" from now on 'cause it's shorter).

Binding operation:

<operation ref="tns:sample-complex">
    <input messageLabel="Initial" />
    <output />
    <input />

2.10.1 is satisfied: it is trivial to map the binding message references to their corresponding interface message references.

MessageLabel-0006 is not satisfied.  You could argue that MessageLabel-0014 is not satisfied, if you wanted, I suppose.  And in fact, this is not an ambiguous situation; since you've identified all-but-one of the messages in a given direction, it's easy to complete the mapping.

<operation ref="tns:sample-complex">
    <input />
    <output />
    <input />

This is the case that 0014 is *supposed* to address, but it can't, because you can't get to it, because before you can think about it, you've violated 2.10.1.  It also violates 0006.  In fact, you could argue that you violate 0006 before you violate 2.10.1, but it's hard to argue that 0014 is violated, because there's all this other stuff that is likely to be checked first.

So.  Imagine a pattern with three inputs, "First", "Second", and "Third" (yes, I think it's stupid, too, but it's legal to define such).

<operation ref="tns:triple-in">
    <input messageLabel="Third" />
    <input />

Heh.  Doesn't violate 2.10.1.  While there's no interoperable way to associate that second input to one of the remaining inputs in the interface message, it is trivial for it to be associated with one of the two remaining unique references in the given direction, at random.

Violates MessageLabel-0006.  There *must* be a messageLabel on this one.

Arguably, violates 0014.  In that sense, 0014 is a duplicate of 0006, but 0006 mandates the presence of an attribute, while 0014 mandates the content of the message exchange pattern pointed at by the interface operation pointed to by this binding operation.

In short: it's not too difficult (though a little pointless, maybe) to violate 0006, which asserts that an attribute MUST appear under certain circumstances.  It's a bit more difficult (I argue that it is impossible to reach this assertion) to violate 0014, which asserts that when an attribute is absent, the abstraction pointed to MUST be unambiguous.

Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Thursday, 14 December 2006 17:33:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:55:02 UTC