New features in the third public working draft of Scalable Vector Graphics (SVG) 1.2 move SVG well beyond an XML format for graphics, positioning it as an application platform. The new draft, edited by Dean Jackson, specifies SVG version 1.2 as "a modularized language for describing two-dimensional vector and mixed vector/raster graphics in XML" and outlines areas of new work under discussion. Some new features include: Rendering Custom Components (RCC); Live Templates (an RCC alternative); dSVG reference (a UI toolkit); filter region extensions; SVGTimer interface (a replacement for setTimeout/Interval); better network data fetching support; Document Simple Model (scripting without the DOM); Tooltips; an experimental draft RelaxNG schema.

"Many content developers are using SVG as the graphical user interface to their XML data, either through declarative transformations such as XSLT or through scripting. The current Rendering Custom Components (RCC) proposal focuses primarily on low-level, foundation technology and relies on scripting for all but the most trivial transformations. It may be possible to provide more support for a declarative syntax, similar to, or using parts of, XSLT. A proposed 'Live Templates' alternative seeks to improve SVG's usability as a front-end for fully interactive Web applications." Some members of the WG favor the creation of a "standardized set of user interface controls built into the SVG language. A Dynamic Scalable Vector Graphics (dSVG) proposal is the most advanced user interface library that the SVG Working Group are examining; where the RCC model attempts to provide an extension mechanism for custom XML content, dSVG provides a set of predefined user interface elements, behaviors and controls."

About Scalable Vector Graphics (SVG) 1.2, Third Public Working Draft

Scalable Vector Graphics (SVG) 1.2. Edited by Dean Jackson (W3C). W3C Working Draft 15-July-2003. Version URL: http://www.w3.org/TR/2003/WD-SVG12-20030715/. Previous version URL: http://www.w3.org/TR/2003/WD-SVG12-20030429/. Latest version URL: http://www.w3.org/TR/SVG12/. Third public working draft of the SVG 1.2 specification, produced by the W3C SVG Working Group as part of the W3C Graphics Activity within the Interaction Domain.

"Here's the list of new features in the 1.2 specification; you'll all notice that most of these features are in response to increasing demand for SVG as an application platform. It's no longer just an XML format for graphics:

• Rendering Custom Components (RCC)
• Live Templates (an RCC alternative)
• dSVG reference (A UI toolkit)
• Filter region extensions
• SVGTimer interface (replacement for setTimeout/Interval)
• Better network data fetching stuff
• Document Simple Model (scripting without the DOM)
• Tooltips
• A draft RelaxNG schema [from Dean Jackson, July 16, 2003]

"There are lots of new goodies in this [1.2 WD-3 version of SVG], including a much more detailed section on Rendering Custom Content (RCC), the feature formerly known as Rendering Arbitrary XML (RAX). I will post some demos of RCC in the coming days, as will other people from the Working Group I'm sure, and obviously soon all the fine folks on this list. It is worth noting that the RCC syntax presented in the document is implemented by the Adobe SVG Viewer 6 technology preview so everyone can play with this. Quite a few SVG 1.2 features are implemented by public implementations out there too. Rock on! [from Antoine Quint, July 15, 2003]

Note the 'Draft RelaxNG Schema for SVG 1.1' in section 14: "In order to give the public an example of the probable approach for the SVG 1.2 schema, a modularized RelaxNG schema for SVG 1.1 has been made available. This schema should not be considered to be complete or without error. Even though it is a schema for SVG 1.1, it is still in development and has not been thoroughly tested. It is likely that future drafts of SVG 1.2 will provide element definitions using RelaxNG or a schema language independent format. The SVG Working Group plan to make W3C XML Schema and RelaxNG schemas available for the complete SVG 1.2 language."

Rendering Custom Components (RCC)

"Public feedback [on SVG] has suggested that many content developers are using SVG as the graphical user interface to their XML data, either through declarative transformations such as XSLT or through scripting (loading XML data into the SVG User Agent and transforming using the DOM)... The SVG Working Group is investigating approaches to see whether new features might be added to SVG 1.2 in order to better facilitate these techniques... The Rendering Custom Content (RCC) approach is based on a formalization and unification of the shadow tree approach which already exists in various ways within SVG 1.0/1.1, where particular features such as the use, pattern and marker elements required a rendering tree which differs from the original document tree. With RCC, all non-SVG elements are given an optional 'shadow DOM tree'. For backwards compatibility with SVG 1.0/1.1, by default the shadow trees are empty. However, if RCC is used, then certain non-SVG elements can have a shadow tree which represents the rendering and interactive behavior for that particular custom element using SVG content within the shadow tree, thus allowing custom elements (i.e., non-SVG elements) to get rendered because the Original XML for the custom elements has a corresponding Generated Alternative SVG within the a shadow tree which defines its rendering and behavior. The working group is looking into opportunities for unification and simplification of the specification of many existing language features based on the RCC proposal, but these exercises are in their early stages. The current RCC proposal focuses primarily on low-level, foundation technology and relies on scripting for all but the most trivial transformations. It may be possible to provide more support for a declarative syntax, similar to, or using parts of, XSLT..." [from 3.1 Introduction]

Live Templates: An Alternate Approach to RCC

"Live Templates is the name of an alternate proposal to the Rendering Custom Content feature... The SVG Working Group believe that it can reconcile the RCC and LiveTemplates proposals, taking the best features from each to produce a better final proposal. The objective of Live Templates is to improve SVG's usability as a front-end for fully interactive Web applications. In classical UI, the data model is in any appropriate XML grammar, the view is SVG, and there is the ability to view (transform the XML to SVG), edit (manipulate the view via DOM or post instructions to a server that would change the XML), and update the view (incrementally change only those parts of the SVG that are affected by changes in the XML, thereby avoiding a complete screen refresh)... Live Templates provides the ability to run a specified XML transformer on a specified XML file or branch of the DOM with specified parameter values, and place the results as a generated SVG sub-tree in a specified location in the SVG. An XML transformer is something that takes XML as input, and produces XML as output, like an XSLT stylesheet. The newly generated SVG subtree could be placed either directly in the DOM or as a shadow tree accessible as a separate DOM tree by calling a method on the element that generates this shadow tree . Live Templates also provides ability to re-run the XSLT/XML transformer at any time to replace just the generated results, while leaving the rest of the SVG untouched..." [from the overview]

Dynamic Scalable Vector Graphics (dSVG)

"A very common request of SVG from application developers is to facilitate the creation of user interfaces. In the section on RCC, the SVG Working Group shows its current majority thinking: building a mechanism that allows developers to extend the base SVG language in an interoperable manner to provide their own custom components, an example of which could be user interface controls and behaviors. While that is the current majority, other parts of the SVG Working Group believe that developers would better benefit from a standardized set of user interface controls built into the SVG language. The dSVG proposal is the most advanced user interface library that the SVG Working Group are examining. Where the RCC model attempts to provide an extension mechanism for custom XML content, dSVG provides a set of predefined user interface elements, behaviors and controls. The design goals of dSVG are: (1) to minimize the amount of script a developer has to author, and if possible to allow a developer with no programming skill to create a Web application; (2) to minimize the application development time; (3) to make automatic generation of user interfaces as easy as possible; (4) to facilitate dynamic data mapping; (5) to perform better than scripting; (6) to not require scripting, especially on resource-limited devices; (7) to allow for expressions as attribute values. At its core, dSVG is an XML markup for user interfaces. It defines all the common user interface controls and enables those controls to be positioned and attached to particular actions. It is not tied to a form model, allowing an author to create a user interface that is not intended to capture data..." [from Section 4, Dynamic Scalable Vector Graphics]

This specification "defines the features and syntax for Dynamic Scalable Vector Graphics (dSVG), an XML language that extends SVG, providing enhanced dynamic and interactive capabilities that were previously only available via scripting. It describes the features required, in addition to those provided by SVG, to use SVG as a platform for building robust Web applications; it provides the syntax description of dSVG, examples of dSVG use, and description of the advantages of using dSVG." [from the spec]

Dynamic Scalable Vector Graphics (dSVG) 1.1 Specification. Edited by Gordon G. Bowman. July 09, 2003. Copyright (c) 2003 Corel Corporation. See the Expanded Table of Contents and file listing.

Overview of Dynamic Scalable Vector Graphics (dSVG)

"dSVG is a language for describing UI controls and behaviors in XML [XML10]. It contains eleven types of UI controls ('button', 'checkBox', 'radioButton', 'contextMenu', 'comboBox', 'listBox', 'listView', 'slider', 'spinBox', 'textBox' and 'window'), six categories of behaviors (DOM manipulation, viewer manipulation, coordinate conversion, constraints, flow control and selection ability), and two container elements ('action' and 'share').

dSVG UI controls have instrinsic states (up, down, hover, focus and disabled), which change according to mouse and keyboard events. Their appearances are defined in skins that are completely customizable. These skins can also contain dSVG constraints, which allow the UI controls to be 'intelligently' resized.

SVG files with dSVG elements are interactive and dynamic. Behaviors can be directly or indirectly associated to SVG elements or to dSVG UI controls and triggered by specified events.

Sophisticated applications of SVG are possible by use of a supplemental scripting language which accesses the SVG Document Object Model (DOM), which provides complete access to all elements, attributes and properties. A rich set of event handlers such as onmouseover and onclick can be assigned to any SVG graphical object. However, scripting has many downsides..." [adapted from the dSVG V1.1 spec]

Public Commentary on dSVG

dSVG vs. RCC vs. Live Templates: Written by schepers on Slashdot. "First off, let me say that I have toyed around with the Corel SmartGraphics Studio, and I think that it's a very good first pass at simplifying the process of creating SVG for a lot of users. As a big fan of SVG, I appreciate all the effort that Corel has put forth. That being said, I think that the Open Source community should know that dSVG is only one of three UI-defining proposals that the SVG Working Group is considering for SVG 1.2. One of the other two, currently known as RCC, proposes the ability to create a kind of template with a separation of style and functionality, but defined in the document rather than being built in the plug-in. Ultimately, I think that this is a better way to go, since it is far more adaptable. It uses scripting and an XSLT-like syntax to transform semantic content into graphical elements (like form controls, scrollbars, etc.). The last proposal, Live Templates, seems like a generalized case of RCC, and I suspect they could be married together. Adobe has released a tech preview of ASV6, the next version of their plugin (Windows only for now). It implements an early version of RCC (as well as some other cool features like text wrapping, audio, video, and external resources), and looks very promising. At SVG-Open, I saw an RCC forms widget toolkit for SVG, which worked well and weighed in at all of 6KB. I also saw ASV6pr working on a Linux box, and with the latest build of Mozilla. It's still buggy, but it's more conformant to the Spec than ever. May the best spec proposal win!..."

Gord Bowman's reply July 20, 2003: "I don't think that dSVG really competes that much with RCC and Live Templates. Those two proposals are about allowing the author to better handle arbitrary XML via script or XSLT -- they are both quite elegant. dSVG, on the other hand, is a proposal to standardize the sort of markup that a lot of people actually need right now, to prevent everyone from having to reinvent the wheel and implement things themselves. So while UI controls could be implemented with RCC and Live Templates, we would prefer that UI markup be a standard as soon as possible, so that they can be natively implemented ASAP. Plus having a dozen different markups and implementations for UI controls doesn't make the SVG standard look good (IMHO). So long as the UI controls can be completely customizable, there's no need for numerous variations on the markup. Standards are good. And dSVG's behavior elements are an attempt to get away from script--so that authoring tools can more easily author interactive SVG, as well as edit the interactive SVG produced by other authoring tools. Plus, markup could be implemented natively on small devices, so that they might not need a script engine at all--which is very appealing. The fact that something CAN be done with script, should never be an excuse not to invent a standard way of doing it with markup..."

What can dSVG do that Javascript DOM does not? "It's XML markup, therefore it can be data-mapped and transformed via XSLT. It's easier for an authoring tool to create markup (which the author can customize) than to create script. It's more high-level than DOM methods, providing a more direct linkage between the syntax and the intent of the author. So it's more intuitive to non-developers than script, thus allowing designers to create web apps all by themselves. Because it's markup, it (or something like it) has the potential to become a standard one day and thus become natively implemented. This would allow SVG on small devices to still have excellent interactivity without needing a script engine, which typically takes up half of the footprint (aside from being slow). Markup is guaranteed to be interoperable on the authoring side, while scripting is not..." By Gord Bowman, Slashdot, July 19, 2003.