Contents
The W3C SVG Working Group has issued an invitation for comments on its third Working Draft specification for SVG's XML Binding Language (sXBL). The document has been produced by the sXBL subgroup of the W3C SVG Working Group as part of the W3C Graphics Activity, within the Interaction Domain.
Scalable Vector Graphics (SVG) is W3C's specification defining XML Graphics for the Web. SVG is "a platform for two-dimensional graphics, specified in two parts: an XML-based file format and a programming API for graphical applications. Key features include shapes, text, and embedded raster graphics, with many different painting styles. It supports scripting through languages such as ECMAScript and has comprehensive support for animation. SVG is used in many business areas including Web graphics, animation, user interfaces, graphics interchange, print and hardcopy output, mobile applications and high-quality design."
The sXBL specification uses the XML Binding Language as a mechanism for defining the presentation and interactive behavior of elements described in a namespace other than SVG's. It is intended to be used to enable XML vocabularies implemented in terms of SVG elements. For instance, a tag set describing a flowchart could be mapped to low-level SVG path and text elements, possibly including interactivity and animation." Section 8 of the draft defines a grammar for sXBL using a RelaxNG schema.
The sXBL mechanism for defining the presentation and interactive behavior of elements a non-SVG namespace uses the XML Binding Language to declare that "a particular element in a particular namespace is implemented by a particular binding. The element thus bound by the XBL declaration acquires the new behavior and presentation specified by the binding. XBL is currently defined as a set of new elements that can be used in SVG document fragments and SVG resources. A future version may extend XBL to be applicable to any markup, and the current version has been designed with this goal in mind."
XBL "cannot be used to give a document new semantics unless a script invoked by XBL explicitly changes the original DOM. The meaning of a document is thus not changed by any bindings that are associated with it — only its presentation and interactive behavior."
The release of the third Working Draft for sXBL is accompanied by an explicit request for feedback by the SVG developer community on three specific issues. Following evaluation of public feedback on these issues, it is anticipated that the next public draft of sXBL will be a Last Call Working Draft.
One issue is that the XBL task force has not decided upon a syntax to use for includes attribute in association with the content element. "The content element is used inside 'shadow content' to specify insertion points for explicit content that might already exist underneath the bound element. Any shadow content the binding places between the bound element and the content elements is interleaved between the bound element and its explicit children without affecting the document model." The two syntaxes being considered are a small subset of XPath and a small subset of CSS Selector syntax.
A second issue for review relates to how CSS selectors match against elements that are part of the shadow content. The Binding Task Force does agree that CSS selectors attach styling properties to shadow content and that binding document stylesheets should be used to attach styling properties to shadow content. The open technical issue relates to CSS selector processing on shadow trees: "Should selectors match only based on Core DOM parent-child links, ignoring XBL DOM links both in the bound document and the xblShadowTree subtree; or should they match against just the flattened tree traversals at each scope; or always match against both; or provide a switch to match against either?"
The third issue for review relates to what happens with children of the bound element which are not explicitly referenced by content elements; in particular, are the unmatched children are they excluded from the fully flattened tree or auto-included within the fully flattened tree. One option is to say that "if an explicit child of the bound element does not match any of the content elements, that child does not appear in the rendering tree; a second proposal says the non-matching child should be inserted at an implied content element at the end of the shadow tree."
"SVG is a language for describing two-dimensional graphics in XML.
SVG 1.1 and SVG Mobile Profiles are Web standards (W3C Recommendations); these include SVG Basic and SVG Tiny, targetted to resource-limited devices and are part of the 3GPP platform for third generation mobile phones. Work continues on SVG Version 1.2 and future profiles for Mobile and Printing; SVG Print is a set of guidelines to produce final-form documents in XML suitible for archiving and printing.
SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. Text can be in any XML namespace suitable to the application, which enhances searchability and accessibility of the SVG graphics. The feature set includes nested transformations, clipping paths, alpha masks, filter effects, template objects and extensibility.
SVG drawings can be dynamic and interactive. The Document Object Model (DOM) for SVG, which includes the full XML DOM, allows for straightforward and efficient vector graphics animation via scripting. A rich set of event handlers such as onmouseover and onclick can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on SVG elements and other XML elements from different namespaces simultaneously within the same Web page...
Mobile SVG: In 2001 the mobile phone industry chose SVG as the basis for its graphics platform. Many leading companies joined the SVG effort to produce the SVG Tiny and SVG Basic profiles, collectively called SVG Mobile and targetted at resource-limited devices such as mobile handsets and PDAs. The SVG Mobile specification was adopted by 3GPP as the required graphics format for next-generation phones and multimedia messaging (MMS). Already there are SVG-enabled handsets shipping worldwide. SVG Mobile is primarily used for messaging in applications such as greeting cards, diagrams and animations...
SVG for Print: The combination of rich graphical features, comprehensive text support and resolution independence in SVG produce a format suited to printing. Leading print hardware companies are currently developing the SVG Print specification: a version of SVG specifically suited to hard-copy output. Use cases of SVG include an XML-based page description language similar to Postscript and PDF, a final-form archiving format and variable data printing, where the information is provided by a database and output using a graphical SVG template. SVG provides identical online and hardcopy display. Being based on XML, SVG Print fits neatly into existing XML workflows. That is, organizations which have a data processing pipeline that supports XML can insert SVG Print capabilities easily into their publishing workflow, enabling dynamic document generation. SVG Print also integrates with common job description formats such as PODi's PPML and CIP4's JDF...
SVG for Web Applications: Web-based applications are increasing in popularity. Developers are often limited by browser incompatibilities and missing functionality. With powerful scripting and event support, SVG can be used as a platform upon which to build graphically rich applications and user interfaces. With SVG, the application developer gets to use a collection of open standards. They are not tied to one particular implementation, vendor or authoring tool...
SVG for Design and Interchange: SVG is well suited to the high-end graphical design market common in the Aerospace, Transportation, Automotive and Telecommunication industries. The extensibility of XML allows SVG diagrams to have embedded metadata in proprietary formats without affecting the presentation. For example, a CAD program could export to SVG for online display, but embed data within the file that facilitates future editing or roundtripping. Also, since many design tools support import and export of SVG, it can be used as an interchange format between applications...
SVG for GIS and Mapping: Geographic Information Systems have very specific requirements: rich graphics features, support for vector and raster content and the ability to handle a very large amount of data. SVG is well-suited to this market and many GIS systems provide SVG export. Like the design case mentioned above, the ability to extend SVG and embed metadata is useful to the mapping community. For example, graphical elements can be identified as their native objects (such as a lake), allowing applications to interact with the objects in a graphical manner. SVG is a perfect complement to the OpenGIS consortium's GML format. GML, also XML-based, describes geographical elements such as rivers and roads. It can be converted into SVG using an XML pipeline for online display...
SVG in Embedded Systems:
Most embedded systems have severe resource limitations, including smaller screens, limited memory and reduced processing capability compared to typical desktop systems. The SVG Mobile specification was designed for such devices and allows for the development of graphical user interfaces for embedded systems. In its support for input events and scripting, devices can use an SVG frontend for control and monitoring, such as a control system for industrial devices... [adapted from About]
