|MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA|
SVG On the Rise
XML-powered graphics make sense
By now everyone knows that XML can solve all the world's problems! Seriously, using XML to mark up graphics is just as much of a benefit as using it to mark up textual data. It's about semantics; a graphic, or the pieces within that graphic, can have as much semantic meaning as any other document.
Of course, marking the image up as a collection of graphical primitives (e.g. circle, line, rectangle) might not always add much, but it does add something. Structure with semantics helps accessibility, and as XML is the dominant structured format on the Web at the moment, you get a whole bunch of tools that can work with that structure for free.
Then, as SVG is XML, you have the option of easily adding much more semantic meaning. You can describe parts of the image using RDF, or any other XML metadata format. You can include XHTML descriptions for each part.
You can also add data in your own custom namespace to describe whatever you want, whether it's more metadata, details on how to return from the graphic to the original representation of the data, or data that can be used to transform one graphic into another. It's not "the end of the road" for the image, as Jacek put it. XML is good for graphics, because it helps ensure that rich content is not lost to the user. It's about not losing data to a proprietary black box; it's about information you can truly reuse and recycle.
So by using XML syntax, SVG graphics are always structured and can have more embedded semantics, which is a very good thing. And it's not just financial data, medical records, and the like that can benefit from the structure XML provides. Graphics such as maps, logos, user interfaces, animations and illustrations are all improved by structure and semantics.
With XML you also get integration -- now. You have the huge range of server-side XML tools to work with, as well as the fact that using XML for graphics fits into the current model of XML workflows. This way, you leverage all the other XML technologies and interoperate with them, including standards such as DOM and XSLT, and tools with XML libraries such as JSP, ASP, and PHP.
The power of this integration can be demonstrated with the simple example of a custom graphic such as a business card or post card. A developer can create an SVG template for the graphic and use server-side tools such as transformations to customize it to the end user's needs. Nearly every modern programming language has support for XML. If your data is in XML and your tool set works with XML, it makes sense that your graphical representation is XML.
SVG already has a uniform platform
Jacek said there is an advantage to having a uniform platform. SVG has one -- it's called the SVG specification. There are lots of SVG implementations, including viewers, editors, and server-side tools for content generation. All these implementations must conform to the specification, mostly because if they don't, developers will use an implementation that does conform.
Developers are tired of having to check an implementation's documentation to see how it diverges from the specification, and the SVG implementors have noticed this. Furthermore, we have a fully conformant SVG viewer in Apache Batik, which is available under an open-source license. Having such a freely available and complete open-source solution available helps the platform: it keeps the closed-source implementations honest, it gives them something to compare to (and even examine the source if their licensing terms allow), and it gives the developers ammunition for guaranteeing the uniform platform.
So I agree with Jacek, a uniform platform is a good thing to have, and I am glad we started with one in SVG.
SVG files are bandwidth-friendly
Jacek calls SVG a bandwidth hog. I disagree, and for two reasons. Firstly, in many cases the declarative animation syntax used by SVG (e.g., move this shape from point A to point B, over 10 seconds, while fading from blue to red) is much more efficient than a frame-based approach (drawing multiple frames, each with the shape in a slightly different location with a slightly different color -- i.e., many static images shown one after the other).
This size advantage becomes more obvious the longer the animation. Of course, the size difference between the declarative and frame-based approach is also very dependent on the animation itself, but SVG animations make effective use of bandwidth. Again, I point to Antoine's excellent Sacré SVG! column for an example of an interactive SVG animation being smaller than the SWF equivalent, and that is for a very small animation.
Secondly, it is worth noting that the SVG Working Group specifically decided to use gzip compression as it does a fantastic job of compressing SVG files. We put our trust in compression experts! Every SVG viewer is required to support gzip-compressed SVG files. Not only that, gzip compression is included in many system libraries, meaning that it is not adding to implementation footprint. The size of SVG files was a major concern to the Working Group and we think we addressed it. I hope the misconception that SVG files are over-verbose does not stick.
The mobile community has chosen SVG
About the time SVG became a W3C Recommendation, the Mobile Device community adopted SVG. Mobile industry companies such as Nokia, Ericsson, and Openwave joined the SVG Working Group. They needed a format for vector graphics on third-generation mobile phones. They wanted it to be an open, XML-based, modularized, profilable technology that would fit into their architectural plan, which included XHTML Basic, CSS, and SMIL. They chose SVG and you can see the results of the work in the Mobile SVG Profiles.
The mobile standards body 3GPP is defining the platform for the next generation of mobile phones in Europe and the U.S. They have chosen SVG Tiny as a required format for Multimedia Messaging (SVG Basic is recommended). I've already seen implementations of SVG on current generation U.S. mobile phones (even with a 75x25 black and white display), as well as Palm Pilots, PocketPC devices, other PDAs, electronic books, Japanese mobile phones (Sharp sells an SVG-capable phone in Japan), and in-car navigation systems.
I was once concerned that the completeness of SVG would lead to too much of a burden on implementors. I don't have that concern anymore, now that I've seen many interoperable implementations, from many vendors, on many devices. The recent modularization and profiling of SVG into SVG Basic and SVG Tiny can only help future implementors.
Why SVG fits into the Web
As this is a web development forum, I think it is important to outline how SVG fits into the overall architecture of the Web. Let's have a closer look:
As you can see, SVG was designed to be an important component in the established and open Web architecture. Adopting open, truly standards-based solutions ensures that the pieces fit together in powerful, extensible, and economical ways. SVG, along with XHTML and CSS, will be part of the two-dimensional rendering engine of the Web.
Final thoughts (or </article> <svg>)
SVG was not designed to replace any existing technology; it was designed to be the best solution for vector graphics on the Web. By producing SVG with regular public review, requirements for implementation experience of its features, and having the participation of organizations and companies leading the development of -- and sometimes competing with each other on -- graphics technologies, you could have bet on the positive outcome. I think SVG's time has already come.
SWF is an extremely popular, proprietary format that has been around for years, with an extremely popular authoring tool. SVG is a new, open XML format, generally acknowledged to be technically superior, which has not yet reached the same level of popularity. But with the enthusiasm shown by the people currently developing SVG content and the strong support from industry and Open Source developers, it shouldn't be long before SVG has the authoring tools and market share to be a dominant Web format.
Dean Jackson is a member of the SVG Working Group.
Return to the Web Development DevCenter.
Comments on this article
1 to 8 of 8
1 to 8 of 8