When is a door not a door? When it's a jar!

So when is an optional feature not an optional feature? When it's required.

OK, that's not as funny as the title (was that funny?), but it's not meant to be. We're doing some work with some other vendors in the Web Services space (names withheld to protect the innocent) and this requires us to use a couple of Web Services specifications that have various optional fields defined in them. We have implementations and they have implementations and we need to talk to one another. Now, my reading of optional is:

(i) it doesn't have to be there;

(ii) if it is present, then you can use it (maybe there are preference rules associated with when you can or should use it);

(iii) if it isn't there, then you should be able to deal with that.

Certainly the specifications I'm referring to here make it clear what optionality means and it's covered in those 3 rules.

Unfortunately the implementation of the foreign system we're working with takes a different approach. In some cases:

(a) if the optional field is present, then it assumes the message is invalid;

(b) if the optional field isn't present, then it assumes the message is invalid.

Oh, and neither (a) nor (b) are publicized anywhere. Very annoying. Now I'm not entirely against an implementation requirement for something that is optional. But if such a thing exists, it should be mentioned somewhere.

Now here's the punchline: we're doing this for interoperability! Laugh? I nearly cried!