2011-07-23 19:02 UTC Improving on HTML
It's interesting (from a historical standpoint) to contrast RDFa with other W3C technologies that have tried to improve on HTML only to find HTML itself improve on them:
XForms: A well-designed technology that addressed a number of quite important use cases very well. Its fatal flaws: it wasn't backwards compatible with the Web, and it didn't do a good job of balancing the declarative with the imperative when it comes to the preferences of Web authors. End result: Web Forms 2 (later merged into HTML5, now just the forms features in HTML, which build on the forms features from HTML4 and the script APIs in DOM2 HTML) is addressing the same use cases, despite being a far less technically clean design. (XForms WG spends considerable resources trying to make HTML adopt XForms. Fails due to lack of browser interest.)
XHTML2: Primarily seemed intended to address a non-problem ("tag soup"). The language itself was clean, and had good ideas, but insufficient new features meant the language never gained wide interest. Its fatal flaws: it wasn't backwards compatible with the Web, and it didn't solve real problems. End result: Some of XHMTL2's strongest proponents (e.g. me) ended up reviving the old HTML and fixing the real problems that had been left unaddressed. Some of the good ideas were adopted and adjusted to work in a backwards-compatible way. (XHTML2 WG spends considerable resources trying to stop W3C adopting HTML at all. Ends up closed instead.)
RDFa: A horribly-designed technology that built on a technology without broad adoption. While it was the only game in town, it gained some traction, but its horrible usability actually pushed some of its biggest adopters (e.g. Google) to seek alternative solutions. End result: A vastly simpler technology designed to address the use cases that people actually care about that ignores the theoretical is developed. The RDFa community try to form a task force to do something about it. What happens next is as yet undetermined.
It's worth noting that quite the opposite has happened with some other W3C technologies. For example, SVG and MathML both got adopted by HTML, despite both of them having problems (both are IMHO over-engineered in various ways). I think the difference is that Math and Vector Graphics are problems so large that "doing it right" would have taken a prohibitively long time. In comparison, forms, document markup, and inline annotations are relatively trivial problems that can just be addressed directly in HTML without much effort.