Come for the XML, stay for the desired-state approach
by William (@vambenepe on Twitter)What would you think of programmers who switch from C to Java in order to be able to use Javadoc for interface documentation? On the one hand, if the benefits of Javadoc alone justify the effort to switch then why not? On the other hand, you can’t help thinking that it’s a pity that they don’t realize (and take advantage of) all the other improvements they are getting for switching to Java. Especially if they start to rewrite some of their existing C code in Java in a way that smells more like C than real Java. Wouldn’t you want to sit with them for a talk?
Well, I am seeing early signs of this happening with SML. As I wrote earlier, the main difference between CIM and SML is that of usage model. Unlike CIM, SML is designed to enable desired-state management. That’s the real difference. But it also happens that SML is XML-based (and naturally compatible with document exchange types of interactions, be they Web Services or REST) while CIM is not (and its XML form is unusable in practice for anything other than RPC). And the difficulty of doing XML doc exchange with CIM happens to be a more immediate problem to many people than desired-state management. As a result, it is tempting to look at SML as a solution to CIM’s lack of XML friendliness. But moving to SML for this reason, while keeping the same level of granularity and the same usage model, is just like moving from C to Java for the Javadoc.
Moving to SML because it is defined around XML documents is hard to justify. BTW, moving to SML because it’s based on XSD is even worse, as I’ll explain in the next post.
