AbstractThis article is not yet public. For now it is just some ramblings. |
1 SVG's Branding Problem
2 Modularity versus Feature Profiling
3 Getting Import Right
4 Graphical Editing
5 Proposed SVG modularization
6 Degrading gracefully
7 Vertical SVG Variants
8 Modularity, Extensibility and type detection
9 Timing of the change
Every standard goes through a maturation process. Part of this process is what we in the software development discipline call refactoring. This article is designed ot make the case that SVG is approaching its middle age and in need of refactoring to recover some of its youthful vigour. I propose that SVG be split up into a family of specfications.
In my SVG Open 2003 keynote, I noted that one of the key barriers to acceptance of both SVG and XML is that they are so generic that it is difficult to tell people what they are. The technologies always seem designed to solve someone else's problem. SVG is not entirely a better Flash than Flash for Web animation and game designers. It is not entirely a better vector graphics interchange format than WMF or PDF. It is not be clearly a better way to offer graphics and movies on the Web than animated GIFs. There are both technological and marketing reasons why it does not seem to be properly focused on each of these domains.
SVG needs to be modularized so that targetted standards can focus on each domain and become the leading player in that domain in terms both of technical quality and ubiquity. Each domain requires different solutions to the competing design goals that the SVG working group must balance.
SVG 1.1 is a modular specification. But it is not a family of separate specifications that build upon each other as I am suggesting. It is moving in that direction with SVG Print, SVG Tiny and SVG Basic but these are still defined in terms of: "take the big spec and ignore these bits and add these other bits." This approach is messy and makes learning "simple" SVG more difficult than it should be. A person looking for a simple lines and circles markup vocabulary should be able to find a specification for it without wading through prose on animations and the DOM.
Also, the various modular specifications should be able to evolve separately. The big bang approach to new versions probably puts undue stress on the working group.
It would be tragic if SVG did not replace the hodge-podge of older vector graphics formats like WMF, EPS and PICT. None of these gained the critical mass necessary to become a standard. WMF and PICT are designed specifically for Windows and the Macintosh respectively. EPS is based upon Adobe's corporate-controlled PostScript format and Adobe seems more interested in PDF than EPS these days anyhow. There should be a well-defined subset of SVG with the specific goal of replacing these three formats for exchanging vector graphics between programs in workflows that may span operating systems.
Not only is this market easier to address than the Flash market, it is also in more urgent need of a solution. It is frankly disturbing to see how often vector diagrams, logos and maps are transmitted between applications and systems as bitmaps. This results in a shameful degradation of information that proprietary standards like Flash are powerless to prevent. SVG must save the vectors!
The first thing this subset would have to remove is runtime-generated SVG. Consider this perfectly legal SVG document:
<svg ... onload="doScript()"> <script type="text/ecmascript" href="external_script.js"/> <script type="text/ecmascript"> function doScript(){ someExternalFunction(); } </script> </svg>The external function could actually generate the SVG entirely. For instance it might be a fractal. No authoring tool could import this kind of SVG without access to a full ECMAScript (Javascript) interpreter. And if it did have an ECMAScript interpreter it would have to be careful how it invoked it because the script might go into an infinite loop and hang the embedding program. It should be possible to move simple, static graphics between programs without taking this risk or forcing the vendor to implement scripting. Scripting is probably fine for attached behaviours because those can be ignored if they are not relevant.
On the other hand, SVG IDEs would of course be expected to handle this sort of thing routinely. They would treat SVG as code and handle the full spectrue.
If the goal is to replace proprietary vector graphics interchange standards, SVG's audio, video, animation and interactivity features are also more of a hinderance than a help. The vector Interchange subset should leave them out. Let's call this subset "static SVG". It is also the logical basis for SVG fonts. Do we really need fonts that include audio and video?
Of all of the documents that can be reliably imported, only a subset can be edited in a reliable way. I believe that many SVG features are simply too powerful to round-trip through today's authoring applications sucessfully. For instance, SVG offers powerful ways of composing pictures out of layers of patterns referenced from stylesheets. This is very cool for those hand-authoring and will also be amazing when offered by native SVG editors but it will simply confuse traditional graphics tools like Adobe Illustrator and CorelDraw. SVG extremists may claim that SVG does things in the right way and the tools should catch up. They may be right in the long term but in the short term there should be a subset even more constrained than the authoring subset specifically for sharing editable diagrams.
Some attention should also be paid to the appropriate model for round-tripping and editing metadata. I envision authoring tools that allow object metadata to be edited in a panel like the Visual Basic properties window. But this implies a simple name/value pair system without verbose and confusing namespace names. Somehow, there should be "friendly names" associated with each metadata field.
Half-baked ideas of how the variants would break down:
SVG exporters should put in effort to have alternate versions of data that may not render properly to a less powerful importer. For instance, movies can have an alternate bitmap associated with them. The SVG specs themselves should define graceful fallback behaviours for features like interactivity and animation. Viewers should alert users when importing is going to lose information.
If an authoring tool can generate SVG optimized for being edited it should clearly state what is going to be removed in order to achieve that (e.g. merging patterns from styles into the main picture) and should allow the end-user to choose whether editability or visual fidelity is a higher priority. On platforms where users can choose clipboard formats there should be two different clipboard formats for editability versus visual fidelity.
An XML document can be considered "SVG" if it renders in an SVG viewer. But RCC offers the possibility of SVG that is really domain-specific data with an SVG rendition "attached". This sort of data cannot be edited reliably in a vector graphics editing tool. At best it can be treated as a scalable, renderable, opaque blob. But this kind of data can be edited reliably in a tool designed for that specific kind of domain-specific data. As long as we are clear that this is not SVG intended for authoring in WYSIWYG SVG tools, we can take advantage of this powerful capability where it is appropriate.
Here are some brainstorms:
The SVG community needs to do some careful thinking about how this all interacts with MIME types, clipboard formats and file extensions. One issue is that we need to tread carefully between the native browser SVG implementations (those should arrive any day now!) and the plugins that will probably lead the way with advanced features.
I would roughly guess that there should be different SVG MIME types for each domain-specific variant, for the static variant and editable static, animated and editable animated variants.
I think that the modularization should probably happen between SVG 1.2 and SVG 2.0 (call it SVG 1.3). The SVG community would not want the SVG modularization process to hold up the features that they are already looking for in SVG 1.2. But after 1.2 ships it will take quite a while for all of the users and implementors to catch up. That offers a perfect window for refactoring, just as the break between 1.0 and 1.2 did.
HTML rendition created using stylesheets by Wendell Piez of Mulberry Technologies.