Re: CR108

Ugh.  What an evil man you are, Tony.

All right, I'll need some clarity before proceeding, then.

On Fri, 8 Dec 2006 04:45:53 +1100
"Rogers, Tony" <Tony.Rogers@ca.com> wrote:
>As I tried to get to sleep I pondered Amy's comments on CR108, and I
>am not sure, but I think Amy may be mistaken.

That happens.  I think the last time was 1968, when I ... but that's another story.

:-)

>Is it really wrong to have two messages corresponding to the same
>message placeholder? 

Behavior in this case is "undefined," in the strict sense.  Since we are making the definitions, if we haven't defined behavior when multiple references point to the same place, implementations are free to a) treat them all as acceptable (the variant that you suggest), b) use only the first encountered, c) use only the last encountered, d) halt and catch fire.  If conformant behavior is not defined, any behavior is  conformant--but not necessarily interoperable.

<description xmlns="http://www.w3.org/2006/01/wsdl" 
             targetNamespace="joe:random-wsdl" 
             xmlns:tns="joe:random-wsdl" xmlns:joe="joe:random-schema">

    <types>
        <xs:import xmlns:xs="http://www.w3.org/yyyy/mm/" 
                   schemaLocation="http://ra.nd.om/loc/at/ion" />
    </types>

    <interface name="tns:sample" />

</description>

Think of that as the container for the snippets that follow, okay?

Is this legal?

<interface name="tns:sample">
    <operation name="tns:sample-op">
        <in element="#any" />
        <out element="#none" />
    </operation>
</interface>

I believe that it is; it gets the default: pattern="http://www.w3.org/2006/01/wsdl/in-out", the message references each are uniquely identifiable by direction within that pattern so can be assigned their required messageLabel properties, and an assertion at the end of 2.5.1 ensures that all the message labels are unique.  Section 2.5.3 asserts that a messageLabel attribute must be present on a message reference element if there is more than one placeholder in the exchange pattern matching the direction property, and its value if present must match a placeholder with correct direction ...

and if the messageLabel attribute is missing, then there must be a unique placeholder with the correct direction.  Note the pattern of assertions in 2.5.3; it's perfectly clear that the pattern was simply picked up and repeated in 2.10.3, with the interface operation replacing message exchange pattern and binding operation replacing interface operation.

Tsk.  What a pity, I was looking forward to finding a loophole, here.  *sigh*

Let's go ahead and create a second operation so that we can play with bindings.  Add this to the above interface, and I'll just have to give binding samples, below:

<operation name="tns:sample-noop" pattern="http://www.w3.org/2006/01/wsdl/in-only">
    <input element="#other" />
</operation>

Hey, and I don't even get to use joe random schema, when I carefully predefined it.  Just not my day, huh?  Oh, well, we've got a pack of cigarettes, a pair of sunglasses, half a tank of gas, and a wrecking bar, let's see what damage we can do to bindings, shall we?

<binding name="tns:sample-bind" interface="tns:sample" type="amy:random-binding">
</binding>

Note that I'm not bothering with a real binding here, because it would be too tedious to get the picky little details right.  The amy:random-binding binding binds XML messages inscribed onto very small pebbles (with pickaxes) to starving carrier pigeons loosed from shipboard.  ("Noo, they doon't *fly* soo mooch as *ploonge*, y'see."  *sploosh*  *burble*  *burble*  cheep!  cheep!  *flapflapflap*  *plop*)  HTH.  We'll use that binding container to stick various incarnations of tns:sample-op and tns:sample-noop bindings inside of, 'kay?

Ah, there's an assertion to prevent us from making several different bindings for the same operation.  Too bad, can't wreck that.  Light up another cigarette and finish siphoning the gas out; *something's* gonna catch fire, here.

Oh, wait.  More of a pity: section 2.10.1 explicitly asserts that we can't bind multiple binding message references to the same interface message reference.  One only.  Horror show, my li'l droogie droogs.  So:

>We definitely need to disambiguate placeholders - no question. And we
>need to tie messages to placeholders. But I suspect the mapping is
>one-way - I'm not sure that we need only one message tied to a given
>placeholder.

Well, see above.  Assertion in 2.10.1 says: no.

Ah, and the failure in the language is no doubt because we're working at a couple of removes.  The binding operation refers to the interface operation, which refers to the message exchange pattern.  We have binding messages mapping one to one to interface messages.  Or ... should we say up to 1:1?  Lovely, smashing!

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

Can someone find an assertion that that violates?  I can't.  And yet, it maps to an in-out interface operation.  Likewise:

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

Alas, this is illegal:

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

The binding message reference has no interface message reference properties.  Pity.  We were singin' in the rain for a few minutes, there.  Cheery little blaze, wot?

So.  This is illegal, too:

<operation ref="tns:sample-op">
    <output messageLabel="In" />
    <input messageLabel="Out" />
</operation>

*There's* a real pity; if it were legal we could truly burn the place down.  But it violates the second assertion in 2.10.3.

However ... I don't think that the third assertion in 2.10.3 has any point.  By the assertions above, every binding message reference *must* uniquely map to an interface message reference (it's true that you don't have to completely bind every interface message reference, so there's a chance for a little in, out there).  If the referred-to pattern has more than one message in a given direction, then the messageLabel must be explicit.  If it exists, it must match direction.

In our examples so far, we mostly haven't bothered with message labels.  So let's not bother some more, and see if we can ever violate the third assertion of 2.10.3, shall we?

<operation ref="tns:sample-noop"> <!-- the simple sample -->
    <input />  <!-- output is illegal due to 2.10.1, see above -->
</operation>

That di'n't 'elp none, guv'nuh.  'Cept to show that you violate some *other* assertion before you can get to violating the third assertion of 2.10.3.

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

Illegal via 2.10.1.  2.10.1 requires the interface message reference property to exist, and for it to be unique, which means that we inherit all the constraints placed on the interface operation and its relationship to the message exchange pattern--exactly as it should be, so you can take the toothpicks out of Tony's eyelids, now.  This binds to an interface operation that has only one placeholder message in direction in, so both inputs have to bind to the same reference, which violates the assertion.

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

Illegal via 2.10.1.

Sorry, dears, we don't *need* assertion three in 2.10.3.  We need the first two assertions (examples not shown, because we don't have predefined message exchange patterns with more than one message in any given direction) to force messageLabels to appear for disambiguation, and to force those labels to match "appropriate" things when they do appear (example of the mismatch and violation of the second assertion of 2.10.3 above, input="Out" and output="In").  Third assertion is never reached, because 2.10.1 kicks in, enforcing the constraints expressed in various places in 2.5.

Proposal: drop the third assertion in 2.10.3.  Reason: it is clumsy in wording, and impossible to violate (due to the raising of an error by earlier-encountered assertions) in practice.

However, this exercise has pointed out two incomprehensible constructs which are not marked illegal.  We can make some more.

<operation ref="tns:sample-op" />
<operation ref="tns:sample-noop" />

According to the rules, these and the versions of sample-op that bind only one of the messages in the exchange are all legal.

Should they be?  Maybe they should (the whole roll-up thing).  Should our specification (part one, that is) remain discreetly silent on the topic, and let bindings talk about which children are and are not required?  Roll-up allows children to be known without being seen.

If we want to *require* a one-to-one mapping (for instance, we could create the binding message reference *properties*, and force the number to match the number and direction of the children of the referenced interface), then we need a proposal for that, but it might break some of the weird feel-good sorts of interfaceless binding tricks that people have been proposing.

I would say, in the end, after trying like *heck* to set fire to this mausoleum, that stone don't burn too good, and maybe all we can do is pry off this one useless assertion as a trophy and take it away, but leave the rest alone.

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

Received on Thursday, 7 December 2006 19:52:17 UTC