Runtime Interface Dependency

Don Box disagrees with my opinion that stubs and skeletons are evil:

Ultimately folks who use languages with dots (e.g., Ruby, C#, Javascript) or with slashes (XPath, XSLT, XQuery) often make assumptions about the “shape“ of the messages they process. At MS, we’ve built “dot-based“ programming models over XML that are liberal in what they allow, but ultimately if a user depends on access to an element named “foobar“ that element needs to be in the XML whether the user is using dots or slashes. Yes, people can program around missing/optional data (thank God for null), but again, most programs that consume XML make some commitment to element and attribute names that wind up being an intrinsic part of the definition of the program (even when those parts of the program are stored out of band from the code stream (e.g., attributes)).

I agree with this — my code will depend on some elements and attributes in the document. The problem, though, is that even if my application only accesses 20% of the elements and attributes in the XML it consumes, the (un)marshaling/(de)serialization code will require a perfect match between the XML and the schema that was current when the code was generated. In other words: while my application code may be tolerant to at least some changes, the generated infrastructure code isn’t (at least not in the general case — BOCTAOE, possibly the MS tooling being one).

I much prefer what Spring WS creator Arjen Poutsma calls the anatidaeic approach ;-)