MOF <--> XML, UML <--> XHTML
Don Box has written a response posting after our discussion about DSLs and UML. A point I only noticed during that discussion was that there is in fact a very nice analogy with MOF/UML and XML/XHTML — with a lot of arguments that could easily be interchanged between the two domains:
- If I build my own MOF meta-model (or DSL, if you prefer), I can explicitly build what I want — nothing unneeded, just what I require. The same is true if I design my own XML language.
- If I instead use UML, I get a lot of pre-defined functionality and semantics, many of which I’ll be able to use, and a lot of unneeded baggage. The same is true with XHTML — I get a lot of things for free that I can probably use, but I also am unlikely to use 100% of it.
- In both cases, I’ll be able to use general-purpose tools — those that understand MOF in the first case, those that can do XML in the second case.
- With UML, I can use a CASE tool that understands what a class, an operation, a package etc. is. With XHTML, I get editors that know paragraphs, tables, blockquotes etc.
- Both UML and XHTML offer their own extensibility mechanisms — much as the technology on the next meta-level does. (In fact, this is the reason I picked XHTML instead of HTML for the comparison).
I’m sure there are many more similarities that I didn’t think of. It’s also interesting to take a look at an old posting by Tim Bray:
Here’s the real dirty secret; every time you cook up your own tag-set, you lose interoperability. The deep semantics that XML tags are labels for can’t be captured in any one of a schema or a write-up or lunchroom chats or running code; they need all of these things. (The notion, inherent in the phrase “custom schemas”, that a schema captures the essence of a language, is just totally wrong). The lesson is, to the extent that you can use a language that someone else already wrote, you win.
Tim is talking about Office document formats, but obviously the reasoning works for the DSL/MOF/UML debate as well.