Can CML + SVG become the de facto approach for Chemical Web Graphics?

This document is being dictated to Arcturus. I have just dictated about half an hour’s work (with some struggle and the need to teach the machine new words) when some command was interpreted as “destroy all work up to now and save nothing”. I suppose that is part of the learning process. In any case when we come to instruct our intelligent fume cupboard Amy, we need to have mastered the ability to speak reliably to our computers. I’d probably need to save the documents at regular intervals, but I suppose this is nothing new.

I moaned in my post about the failure of Microsoft and Adobe to support SVG in the browser but also that there were some small rays of hope. The first comes from a comment which I reproduce in full.

Jeff Schiller says:

May 3, 2010 at 1:47 am  (Edit)

Just an update:

* Firefox is moving to support SMIL (animation) in its next release (3.7) and the nightlies now support it pretty well
* All WebKit-based browsers support SVG+SMIL for almost two years
* Microsoft has announced support for SVG in IE9 (though no animation yet)
* FakeSmile is a JS library that can be used to fake SMIL support for browsers that don’t have it yet
* the Chrome Frame plugin, Renesis plugin can be used to give IE8- support for SVG

This means that it’s now possible to get SVG+SMIL support in a good amount of browsers. When IE9 is released I hope Microsoft will continue its support of web standards and implement SMIL.

This is good news. I looked at SMIL about a decade ago and decided that although valuable it didn’t address what I wanted to do. SMIL is about running multi media streams (for example combined text audio and slides) while what I want to do is animate the primitives of Scientific Data. This includes changing coordinates, opacity, scale, and other programmable attributes in SVG. Nevertheless this is good news is there is a lot that we can do with static diagrams.

The attraction as xml as a format over the web is that all browsers can be expected to support it. I believe that Chemical Markup Language (CML) is a simple and universal way of transmitting chemical graphics over the web. We should be able to rely on some form of xml transformation such as JavaScript or XSLT to carry out the transformation from native chemistry to graphics primitives with no knowledge or need for Chemical Software. Indeed I wrote a complete transformation library for CML to SVG. This allows anyone to serve CML or even to transmit simple CML files and have them rendered in the browser with no other plugins or helper software. If Jeff is right then in a few months’ time it should be possible for us to display all our chemistry in cml, provides an XSLT library, and have it rendered in the browser. This could be the mainstream way that Wikipedia could OFFER scalable graphics for chemistry.

The second piece of good news is that Wikimedia has been addressing the problem of editing semantic graphics and they have produced a proposal and summary which looks moderately optimistic. Of course Wikipedia by itself does not have the power to change the deployment of graphics technology but I suspect its voice and actions will speak for themselves and will help to change the culture. Here is part of the proposal in some detail (http://strategy.wikimedia.org/wiki/Proposal:Editable_Graphics ).

This is a proposal for a unified approach to editable graphics in MediaWiki. It draws from and is inspired by a number of technology related proposals concerning graphics on this wiki and also from some proposals on structured data handling.

• WYSIWYG editing from within the browser is used to edit the graphics.
  
• Diverse types of graphics are supported with each type potentially having its own custom representation and component elements. For example maps represented in terms of roads, stave music in terms of notes, graphs in terms of numbers, genealogies in terms of relationships.
  
• The underlying data is used to generate the graphics. We may generate SVG or bitmap formats to show in the browser, but that need not be the underlying format. This promotes editability, verifiability and flexibility of the graphics. Updating a pie chart is easiest when you have the underlying numbers. There is little danger of wedge sizes not matching the numerical values. A map can be presented in different projections and with different levels of detail. This is easiest if it is represented as its underlying GIS data rather than as vector graphics.
  
• One toolchain is used to generate graphics of many kinds in spite of the diversity of types of graphic. The in-browser WYSIWYG editor is smart enough to customise itself to different graphics types. You’ll have a different palette of elements to add if you’re working with a road map than if you are working with a biochemical pathway.
  

One possibility is to use XML and XSLT technology to support the diversity of graphics types and their representations yet bring all the different types of editable graphics into the same toolchain. Enhancements to that toolchain benefit all graphics types supported.

They also give a table of the current state of play. It’s patchy but IF Microsoft start to deploy SVG and if all parties make software Open Source then, who knows, we might have an interoperable web no more than 20 years after some of us were debating the vision in Geneva 1994.

Browser Technology For Images

• This is a comparison table of the technology available in browsers for rendering images.
  

Edit hint: Comparison table could be made into a new page ‘Comparison of Browser Technology for Images’ and linked to from here

• All methods marked ‘(code)’ in the syntax column can, with the appropriate programming (a non-trivial task), be used to render from XML or from custom text formats.
  
• In-browser editing marked as ‘possible’ indicates the method can potentially edit data if so programmed, but that’s not a built-in feature.
  
• SVG can be added to IE 6 and above by using the Chrome frame plug-in and there is also an SVG->Silverlight adapter extension. However neither of these plug-in is commonly installed on IE. A third possibility is svgweb which uses flash.
  

Thank you everyone who is working for Open Graphic Interoperability. As soon as it becomes a reality we will redeploy CML to use SVG displays. And volunteers will be highly valued.