OK, so Indigo is officially out of the closet…. somewhat. And Christian Weyer, who’s been a part of the Indigo SDR team for about as long as I have (perhaps longer, dating back to TechEd of last year), has started commenting on the Indigo programming approach, starting with the explicitness of Indigo’s contract model. In it, he says:
What really annoys me is that nearly everybody seems to ignore the interoperability aspect of services (and Web Services…) nowadays. If you (try to) do serious interop in your daily work, you won’t even bother starting with C# or VB or Java… and yes: I know that you might want to see C# interfaces and some square-bracketed attributes as one valid way to write down your service’s interface description.
As he points out (quoting Steve Vinoski as he does), going at an interoperability problem from the perspective of a programming language inevitably leads to failure, because few programmers have the discipline to ignore the trap that Steve mentions:
When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don’t work so well will care.
But unfortunately, it gets worse.
I’ve come to recognize that we’re still looking to XSD and WSDL to be a sort of "IDL for interoperability", and the problem is that both Schema and WSDL allow for things to be defined that don’t fit our existing programming languages. Facets on schema types, in particular, create a particular brand of Hell for the Schema-to-class automatic translators, and fact is, most tools (xsd.exe and all of the Java-based toolkits I’ve tried thus far) basically punt on them. Which leads us to a nasty discipline problem all over again: Not only do you have to be disciplined enough to avoid the styles or notions or idioms of a particular programming language into your service, but you have to be disciplined enough to avoid the styles or notions or idioms of the wire-level representation, as well, or the consumers of the message on both sides will find it awkward to work with.
How do we avoid this? At the moment, there’s less concern for the latter than the former, but as people start to go with a more "contract-first" approach, we either have to bury the angle brackets behind a subset of what schema can offer (and thereby piss off the angle-brackety crowd), or else we have to just publish mounds of texts and patterns  to describe to people what to avoid and when.
Neither one sounds truly appealing, which leaves a third option, one far more radical but infinitely more satisfying: just ratify and stamp with approval the current programming practices, and introduce XML and schema types as first-class citizens into our programming languages.
 I categorically refuse to use the term ‘best practices’ because THERE ARE NO SUCH THINGS! Anyone who talks about ‘best practices’ is basically saying they’ve never considered the alternatives or why a particular approach is good or bad. A given solution never has all-good or all-bad consequences, but a mix of both, and how can you judge which consequences are good or bad when you take the solution out of the context of a problem that needs to be solved? DEATH TO BEST PRACTICES!