VML and OOXML: Cum mortuis in lingua mortua

In this post, I will look at the history of Vector Markup Language (VML), how it lost out to the W3C’s SVG back in the 1990’s, but has come back from the dead, showing up in the draft Ecma Office Open XML (OOXML) specification. I offer some opinions on why this is a bad thing.

First, a bit of history. The field is vector graphics, the type of graphics composed of lines and shapes and background fills, the type of graphics that scales nicely to different sizes/resolutions, and different devices, as opposed to raster graphics which is a bunch of pixels such as a GIF or JPEG file. This is a gross oversimplification, but it will suffice.

Vector Markup Language (VML) was an XML vocabulary for vector graphics submitted to the W3C by Microsoft and others back in mid-1998. I will not comment on its quality or merits, but merely note that it was rejected by the W3C in favor of Scalable Vector Graphics (SVG) specification which became a W3C Recommendation (that’s what the W3C calls their standards) in 2001. Since then, SVG 1.0 was upgraded to SVG 1.1. in 2003 and several mobile profiles (SVG Tiny and SVG Basic) were created. SVG has native support in Firefox and Opera, with Plugins available for most other browsers. There is support on mobile phones and PDA’s. A search of Amazon.com shows 19 books dedicated to SVG. The SVGOpen Conference has been going for 5 years strong. This all adds up to SVG being an established, open standard, widely implemented with a thriving implementor/user community and signs of continued innovation. It is a standard with a past, a present and a future.

But what ever happened to VML? VML has been a dead-end, from a standards perspective, for 8 years now, an eternity in web time. I was not able to find any VML books on Amazon. I could not find any VML conferences (unless one counts the Virgina Municipal League’s get-together at Virgina Beach in October). However, there is some lingering VML support in Internet Explorer and Office. Developers still use VML to target those applications, but I wonder, is it done out of preference or out of necessity? Although it is the users who are portrayed as dinosaurs for not upgrading to Office 2003, doesn’t it seem like Microsoft Office and Internet Explorer are the ones in need of an upgrade? They should join the rest of the world and start using SVG rather dragging along a dead spec.

But it is worse than this. I wouldn’t have bothered writing this just to point out something you already know, that Internet Explorer slowly or never adopts relevant web standards. The thing I wish to bring to your attention is that VML, the same VML rejected in 1998, is now being proposed as part of the draft Ecma Office Open XML. Take a look for yourself (warning, 25 MB specification download!).

Section 8.6.2 of the spec (Ecma Office Open XML, Working Draft 1.3) says:

VML specifies the appearance and content of certain shapes in a document. This is used for shapes such as text boxes, as well as shapes which must be stored to maintain compatibility with earlier versions of consumer/producer applications.

How should one parse “earlier versions of consumer/producer applications”? Is this a circuitous way of saying “MS Office and Internet Explorer”?

Now take a look at Chapter 23, VML, pages 3571-3795 (PDF pages 3669-3893). We see here 224 pages of “VML Reference Material”, which appears to be a rehash of the 1999 VML Reference from MSDN, and in this form it hides itself in a 4,081-page OOXML specification, racing through Ecma and then straight into ISO. Is this right? Should a rejected standard from 1998, be fast-tracked to ISO over a successful, widely implemented alternative like SVG?

Why should you care? It is all about reuse.

If a standard reuses an already successful standard, it reuses the collective community wisdom that went into making that standard. It also reuses the considerable editorial effort in writing, editing and reviewing a technical specification. Reusing this effort lets the TC focus their time on on truly innovative aspects of their specification, and leads to a higher quality standard.

When you reuse a standard, you allow implementors to reuse the experience and knowledge they have already developed around that standard. Remember the 19 books dedicated to SVG? There is a lot of SVG knowledge out there. Why waste it?

Reusing an existing standard, especially a popular one like SVG, allows implementors to reuse the various code bases, both commercial and open source that support it. Why reinvent the wheel? Do you really want to rewrite a vector graphics engine? SVG has several good open source libraries including Apache Batik and librsvg.

Use SVG and you get reuse on three fronts. Stick with VML and the only thing that is reused is Microsoft’s legacy code. Using SVG is clearly the better choice.

I suggest that Ecma TC45 investigate this issue and consider moving off of VML and move to SVG, or at least demonstrate why it is impossible to do so. Why does the world need yet another XML vector graphics standard? If there is something missing in SVG (which I doubt) then why not work with the W3C to propose a enhancement for SVG rather than re-proposing the VML standard which was rejected back in 1998?

Again, I make no technical argument why SVG is or isn’t superior to VML. I merely note that SVG has been an adopted W3C standard for 5 years now and should have a presumption of suitability for the task, especially over a specification which were rejected 8 years ago.

Good catch! In my opinion, this is the sort of analysis which is going to be most effective in coalescing support around ODF instead of Open XML, as it does not simply say “Open XML is bad because it is proposed by Microsoft”, but rather “Open XML is bad because of specific features which are only included to help Microsoft but which would be difficult/painful for other vendors to support”. Like your earlier analysis of the hard coded borders, this is the sort of valid criticism of a proposed standard which should be done, no matter where the proposed standard originated. Thank you.

Problem is getting this sort of knowledge widespread. Any such issues need to be highlighted with the standards committees since ratifying a “standard” that clearly disregards agreed open standards simply discredits the whole process.

Microsoft will most likely never support SVG but go straight to XAML. A next version of the OOXML format will then probably replace the VML format with XAML.The .NET 3.0 framework will most likely contain a lot of support for XAML and probalby the next version of IE (IE8?) will then also support XAML and pretty soon all of SVG will be ancient history before it got of the ground