Incremental SVG mobility and update

Keywords: incremental computation, optimization, XML, DOM, SVG Tiny, Mobile SVG, J2ME

Andrew Girow
TinyLine
Tel Aviv
Israel
andrew@tinyline.com
http://www.tinyline.com

Biography

Andrew Girow specializes in creating and implementing high-performance J2ME and Java technologies as well as SVG and XML. In addition to Java and embedded software he develops server C/C++ applications under UNIX platforms. Andrew Girow latest development project TinyLine (http://www.tinyline.com) is devoted to SVG and 2D graphics implementations on J2ME platform.


Abstract


Several application domains need a more flexible approach to SVG data mobility than can be achieved with SVG documents and SVG document fragments. The proposed approach allows updating the SVG by transferring pieces of the new SVG from a server to the phone and then dynamically patching the original SVG. We refer to such SVG pieces as SVG increments. We describe how to use SVG Tiny increments to achieve more small-grained SVG data mobility than in the approaches that are based on the SVG document structure.


Table of Contents


1. Introduction
2. Incremental SVG Processing
     2.1 Incremental DOM updates
     2.2 SVG document fragments
     2.3 SVG document increments
3. Prototype Implementation
     3.1 TinyLine SVG Toolkit for J2ME
         3.1.1 Features
         3.1.2 Modules Architecture
         3.1.3 TinyLine 2D
     3.2 SVG Tiny messaging system
     3.3 Appendix A. Examples SVG source codes
Bibliography

1. Introduction

Several application domains need a more flexible approach to SVG data mobility than can be achieved with SVG documents and SVG document fragments. This flexibility can either be required as a result of low network bandwidth, scalability or adaptability requirements. For instance, the bandwidth between a server and a GSM mobile phone cannot cope with downloading large amounts of SVG data from a server, every time an update is needed. In case of mobile GPRS or UMTS networks, where the bandwidth is much larger, providers will charge by transmitted data volumes; also, in this case, the update of SVG data for services on the phones needs to be small-grained to achieve cost effectiveness. If SVG data on big number of mobile devices have to be kept in sync and be updated with new SVG documents or SVG document fragments: scalability issues rise in this context, due to the number of devices and to the frequency of the updates.

The proposed approach allows updating the SVG by transferring pieces of the new SVG from a server to the phone and then dynamically patching the original SVG. We refer to such SVG pieces as SVG increments. Unlike SVG document or document fragments, SVG increments does not confine us to sending granular units of SVG; SVG increments do not need to begin with the SVG element, they can also start with other parts of the SVG tree. This enables us to specify sub-trees and individual leafs. The SVG increments will be shipped together with some information on how to modify the remote SVG tree.

Typical usage scenarios might be fleet management, map viewing, monitoring, etc. For example, in a case of map applications very often the user starts with the general view of the given area. Then he asks for more specific information, such as "give me a road leading to", "give me a nearest shop", etc. This process is incremental in nature. First the user gets a big chunk of the information such as an area map, that he refines his view on the area map step by step using some query system.

In this paper, we use a simple SVG Tiny messaging system, based on TinyLine SVG Toolkit. We describe how to use SVG Tiny increments to achieve more small-grained SVG data mobility than in the approaches that are based on the SVG document structure. Also, we describe how to support incremental insertion, removal or substitution of, possibly small, SVG increments on J2ME mobile clients.

2. Incremental SVG Processing

Typically, if an SVG viewer requests an update of some SVG file, all previous information stored at the viewer memory (DOM tree) is erased and completely a new DOM is built from scratch. The same picture is on a server side. If a server process makes an update to an existing SVG file it deletes the previous one and processes a new one as unbreakable chunk of information. This situation most likely represents a "raster picture" approach when if you want to update a raster picture you just replace it with a new one. But SVG format can be used more enhanced way utilizing its XML nature and DOM representation.

Currently, the DOM usage in SVG processing is restricted in space and in time. "Restricted in space" means that a DOM on one host typically does not talk to other DOM on other host. "Restricted in time" means that a single DOM instance of SVG has a very short lifetime. Once a parsing or serialization process is completed a DOM is erased from a host memory. Lets see how DOM API can be used for incremental updates and can be adopted for DOM-to-DOM dialog.

2.1 Incremental DOM updates

Incremental computation takes advantage of repeated computations on inputs that differ slightly from one another. Incremental program produces each output efficiently by exploiting the previous output.

In general, given a program F and an operation O, a program F* is called an incremental version of F under O if F* computes F (x O y) efficiently by making use of F (x).

Suppose F is an SVG processing program that builds DOM and may be also renders it. S1 is an SVG input file and O performs changes to S1 to make it S2. Then F* is an incremental SVG processor that process a new SVG file S2 by updating the old DOM rather then building from scratch.

The following examples demonstrates S1, S2 and O for some mobile SVG applications.

Example 1. A monitoring and positioning system produces the following S1 and S2 pictures, representing movements of some object in the given area of interest.

S1 (1 sec.) S2 (5+ sec.)
incremental_svg_mobility-01-t.svg
incremental_svg_mobility-02-t.svg

Table 1

The corresponding operation O might be:

Replace node which id equals "object-0" with the following code
   <circle id="object-0" cx="225" cy="175" r="20" fill="red" stroke="black" />

Example 2. A remote control system produces the following S1 and S2 files, representing data from two controls.

S1 (1 sec.) S2 (5+ sec.)
incremental_svg_mobility-03-t.svg
incremental_svg_mobility-04-t.svg

Table 2

The corresponding operation O might be:

Replace node which id equals "control2" with the following code
     <rect id="control2" x="325" y="80" width="100" height="160" fill="red" stroke="blue" stroke-width="4" />

Example 3. A remote power control system produces the following S1 and S2 files:

S1 (1 sec.) S2 (5+ sec.)
incremental_svg_mobility-05-t.svg
incremental_svg_mobility-06-t.svg

Table 3

The corresponding operation O might be:

Insert after the node which id equals "sensor-a" the following code
    <g id="sensor-b">
      <rect x="160" y="100" width="30" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="125" fill="red">b</text>
    </g>
Insert after the node which id equals "sensor-c" the following code
    <g id="sensor-d">
      <rect x="160" y="180" width="80" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="205" fill="red">d</text>
    </g>

What we can see from the above examples? The incremental SVG processor allows us to update a DOM of SVG by transferring small pieces of a new SVG from a server to a mobile device and then dynamically to patch the original DOM. We refer to such SVG pieces as SVG document increments and we will define them more formal way later on.

We have small updates rather then large documents, which gives us a lower bandwidth and higher scalability. As soon as the incremental SVG processor operates directly on DOM then no reparsing of a whole new document is needed. Very often, updates damage only part of a screen, and then just relatively small areas of a screen need to be redrawn.

What is a relationship between SVG document fragments and SVG document increments?

2.2 SVG document fragments

[SVG 1.1] defines an SVG document fragment as any number of SVG elements contained within an 'svg' element.

An SVG document fragment can be an empty fragment or a fragment, containing a single SVG graphics element (such as a 'rect') or even a collection of container elements and graphics elements.

An SVG document fragment can be standalone, in which case the SVG document fragment is an SVG document, or it can be embedded inline as a fragment within a parent XML document.

The following example shows simple SVG content embedded inline as a fragment within a parent XML document. Note the use of XML namespaces to indicate that the 'svg' and 'ellipse' elements belong to the SVG namespace:

<?xml version="1.0" standalone="yes"?>
<parent xmlns="http://example.org" >
   <!-- parent contents here -->
   <svg width="40" height="80" xmlns="http://www.w3.org/2000/svg" >
      <ellipse cx="20" cy="40" rx="20" ry="10" />
   </svg>
   <!-- ... -->
</parent>

Why SVG document fragments are not good enough for us? There are at least two reasons for that.

First, an SVG document fragment is built on 'svg' element. A single graphics element such as an 'ellipse' cannot be represented without being a child of a parent 'svg' element. If an SVG document fragment is inserted into a DOM, a new 'svg' element is always inserted as well. This is not only redundancy. Often we want to insert just a single graphics element; we don't what meaningless 'svg' elements to be inserted into a DOM.

2.3 SVG document increments

An SVG document increment formal definition is influenced by [Jabber] XML streams and is based on well-formed XML documents [XML 1.0] .

Jabber Protocol defines the asynchronous exchange of small chunks of XML between presence-aware nodes. A node's session with a host can be seen as two open-ended XML documents that are built up through the accumulation of the XML chunks that are sent over the course of the session. This notion of building XML documents is very attractive for SVG documents mobility and updates, but the model is too simple and flat.

XML 1.0 gives the following formal definition to well-formed xml documents.

Well-Formed XML Documents

A textual object is a well-formed XML document if:

  1. Taken as a whole, it matches the production labeled document.
  2. It meets all the well-formedness constraints given in this specification.
  3. Each of the parsed entities which is referenced directly or indirectly within the document is well-formed.

Document

   [1] document	::= prolog element Misc*

Matching the document production implies that:

  1. It contains one or more elements.
  2. There is exactly one element, called the root, or document element, no part of which appears in the content of any other element. For all other elements, if the start-tag is in the content of another element, the end-tag is in the content of the same element. More simply stated, the elements, delimited by start- and end-tags, nest properly within each other.

As a consequence of this, for each non-root element C in the document, there is one other element P in the document such that C is in the content of P, but is not in the content of any other element that is in the content of P. P is referred to as the parent of C, and C as a child of P.

SVG document increment

Our point of interest is that node C mentioned above. A document increment is a non-root element C in the well-formed XML document as it defined above with its own namespace.

The following example shows simple SVG content embedded inline as an document increment within a parent XML document. Note the use of XML namespaces:

<?xml version="1.0" standalone="yes"?>
<parent xmlns="http://example.org" >
  <ellipse cx="20" cy="40" rx="20" ry="10" xmlns="http://www.w3.org/2000/svg"  />
</parent>

3. Prototype Implementation

At this early stage of this project, I have decided to implement a very basic functionality that will give some indication of the future developments. In order to examine the on-line DOM updates, I evaluate a very primitive SVGT messaging system based on the TinyLine SVG Toolkit for J2ME platform.

3.1 TinyLine SVG Toolkit for J2ME

TinyLine SVG Toolkit is a J2ME software development kit for applications that want to use images in the SVGT format. The main target platform of the TinyLine SVG API is J2ME/CLDC.

3.1.1 Features

Document Structure

TinyLine supports the 'svg' , 'title', 'desc', 'defs' and 'metadata' elements as defined in SVGT. TinyLine supports the JPEG, PNG and GIF formats on the 'image' element depending on which J2ME profile it is running. The 'switch' element is not supported.

Styling

In order to simplify parsing TinyLine uses presentation attributes and property inheritance rules and does not support CSS (Cascading Style Sheets).

Coordinate Systems, Transformations and Units

Coordinate systems in TinyLine are fixed point numbers as well as angles scales and other attributes. The finite useable coordinate range is defined by the scope of signed 16-bit integers. TinyLine supports 22.8 and 15.15 fixed point numbers. TinyLine supports nesting of transformations. The types of transformations that are allowed are generic transformation matrices, or simple operations such as rotation, scaling, skewing, and translation.

coords-trans-02-t.jpg

Shapes

TinyLine supports all SVGT/SVGB path commands. It also supports the basic shapes (rectangles, circles, ellipses, lines, polylines, and polygons)

paths.jpg

Text and Fonts

TinyLine represents text with Unicode characters. It supports the SVGT 'text' element. In order to use fonts across platforms TinyLine supports SVG fonts with glyph outlines expressed using the "d" attribute on the 'glyph' element. TinyLine doesn't use system fonts.

text.jpg

Color

TinyLine supports colors defined by 'color' property in sRGB color space using '#FFFFFF' and '#FFF' notations , and 16 color keywords defined in HTML.

Linking

TinyLine supports hyperlink activation from SVG content to other Web resources through the 'a' element.

Animation

TinyLine supports the animations as it defined in SVGT:

anim.jpg

3.1.2 Modules Architecture

The following figure illustrates TinyLine SVG Toolkit module types

modules.jpg

Application Modules

The Application Modules illustrate the functionality that TinyLine offers. For example, the SVGT Viewer is built using several Core Modules and illustrates how TinyLine lets you view, zoom, pan and rotate SVGT documents.

Core Modules

The core modules are the kernel of the TinyLine architecture. They can be used individually or in combinations for various purposes, and the Application Modules offer some usage examples.

Low Level Modules

The Low Level Modules include:

The SVGT Parser module contains parsers for SVGT documents and complex SVGT attributes such as transform or color attributes. Higher level modules rely on the SVGT Parser module.

The TinyLine 2D module is a 2D graphics library for J2ME platform.

3.1.3 TinyLine 2D

The TinyLine 2D is a library of Java classes for 2D graphics supporting a superset of the SVG Tiny imaging model, designed to be integrated with graphics, artwork, and illustration programs for J2ME platform.

Design Goals

The main target platform of the TinyLine 2D API is J2ME/CLDC. The CLDC devices typically have little processing power and memory, and no hardware for 2D graphics and floating point arithmetic support.

The design goals for the TinyLine 2D API include:

Features

The list below summarizes the features provided by the TinyLine 2D API.

TinyLine 2D API Fundamentals

The TinyLine 2D API handles arbitrary shapes, text, and images and provides a uniform mechanism for performing transformations such as rotation and scaling. The TinyLine 2D API also provides comprehensive font and color support.

Drawing Model

The TinyLine 2D models graphics at the level of graphical objects rather than individual drawing functions. All graphical objects (nodes) are organized into the graphics tree. Each graphical object "paint" operation draws over some area of the integer array (off screen buffer). When the area overlaps a previously painted area the new paint partially or completely obscures the old. When the paint is not completely opaque, the result is defined by the simple alpha blending rules. Nodes in the graphics tree have an implicit z drawing order. Subsequent nodes are painted on top of previously painted nodes.

Coordinate systems and Transformations

The TinyLine 2D system supports two coordinate spaces: USER SPACE and DEVICE SPACE. USER SPACE is the logical coordinate system. It allows to be independent of the resolution of the output device. In TinyLine 2D user space coordinates are fixed point numbers. Coordinates in DEVICE SPACE specify a particular pixel. Device space is a device-dependent coordinate system and it varies according to the target device. In TinyLine 2D device space coordinates are integers. The origin of device space coordinate system is at the upper left corner with the positive direction of the y-axis pointing downward, and the positive direction of the x-axis to the right. Transformations can be nested to any level of the Graphics Tree. The effect of nested transformations is to post-multiply (i.e., concatenate) the subsequent transformation matrices onto previously defined transformations.

Paths

A path is defined in TinyLine 2D using the TinyPath class.

Paths represent the geometry of the outline of an object, defined in terms of

Compound paths (i.e., a path with multiple subpaths) are possible to allow effects such as "donut holes" in objects.

Colors and Images

Nowadays Java devices support 16 bit or less colors. In a nearest future 24 colors will be available. TinyLine 2D supports accurate ARGB color, where ARGB color component values range from 0 to 255.

A solid color is specified by the combined ARGB value consisting of the alpha component in bits 24-31, the red component in bits 16-23, the green component in bits 8-15, and the blue component in bits 0-7.

Painting: fill and stroke

Nodes can be filled (which means painting the interior of the object) and stroked (which means painting along the outline of the object).

With TinyLine 2D, you can paint (i.e., fill or stroke) with:

Text

TinyLine 2D text objects are rendered like other graphics nodes. Coordinate transformations, painting. clipping apply to text nodes in the same way as they apply to shapes nodes. The textual content of a text node is array of characters, where each character is a Unicode code.

A font consists of a collection of glyphs together with the information necessary to use those glyphs. The font tables include the information necessary to map characters to glyphs, to determine the size of glyph areas and to position the glyph area.

3.2 SVG Tiny messaging system

In order to examine the on-line DOM updates, I evaluate a very primitive SVG increments "update" protocol.

The proposed protocol can perform several updates as one transaction using the 'transaction' element, which has no attributes and plays a role of general container for updates.

The 'update' element is used to define the target node of the current DOM to be changed and the corresponding operation type along with a new content.

For our Example 1, to replace node which id equals "object-0" with the new code, you can specify:

<?xml version="1.0" standalone="yes"?>
<transaction xmlns="http://example.org" >
  <update target="object-0" type="REPLACE" >
   <circle id="object-0" cx="225" cy="175" r="20" fill="red" stroke="black" xmlns="http://www.w3.org/2000/svg"  />
  </update>
</transaction>

Attribute definitions:

target="ID" An ID of the element which is the target of this update and which therefore will be modified.

type="INSERT_BEFORE | INSERT_AFTER | REMOVE | APPEND | REPLACE" specifies the type of update to be performed on the target node of the DOM.

For our Example 2, to replace node which id equals "control2" with the new code, you can specify:

<?xml version="1.0" standalone="yes"?>
<transaction xmlns="http://example.org" >
  <update target="control2" type="REPLACE" >
   <rect id="control2" x="325" y="80" width="100" height="160" fill="red"
     xmlns="http://www.w3.org/2000/svg"
     stroke="blue" stroke-width="4" />
  </update>
</transaction>

For our Example 3, to insert new nodes, you can specify:

<?xml version="1.0" standalone="yes"?>
<transaction xmlns="http://example.org" >
  <update target="sensor-a" type="INSERT_AFTER" >
    <g id="sensor-b" xmlns="http://www.w3.org/2000/svg" >
      <rect x="160" y="100" width="30" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="125" fill="red">b</text>
    </g>
  </update>
  <update target="sensor-c" type="REPLACE" xmlns="http://www.w3.org/2000/svg" >
    <g id="sensor-d">
      <rect x="160" y="180" width="80" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="205" fill="red">d</text>
    </g>
  </update>
</transaction>

Here are our example screen shorts.

S1 (1 sec.) S2 (5+ sec.)
7650_mobility-01.jpg
7650_mobility-02.jpg

Table 4

Currently, I am investigating JMS implementations as well as JXTA peer-to-peer model in order to build a full prototype of the proposed approach.

3.3 Appendix A. Examples SVG source codes

Example 1. The S1 SVG code

<svg version="1.1" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   id="svg-root" width="100%" height="100%" viewBox="0 0 480 360">
   <title id="test-title">monitoring-01-t</title>
   <g id="buildings-set-0">
     <rect id="building-0" fill="silver" stroke="#000000"  x="50" y="50" width="50" height="100"/>
     <rect id="building-1" fill="silver" stroke="#000000"  x="150" y="50" width="50" height="100"/>
     <rect id="building-2" fill="silver" stroke="#000000"  x="250" y="50" width="50" height="100"/>
     <rect id="building-3" fill="silver" stroke="#000000"  x="350" y="50" width="50" height="100"/>
     <rect id="building-4" fill="silver" stroke="#000000"  x="50" y="200" width="50" height="100"/>
     <rect id="building-5" fill="silver" stroke="#000000"  x="150" y="200" width="50" height="100"/>
     <rect id="building-6" fill="silver" stroke="#000000"  x="250" y="200" width="50" height="100"/>
     <rect id="building-7" fill="silver" stroke="#000000"  x="350" y="200" width="50" height="100"/>
   </g>
   <circle id="object-0" cx="225" cy="100" r="20" fill="red" stroke="black" />
   <text id="name" x="10" y="340" font-size="40" stroke="none" fill="black">Monitoring</text>
   <rect id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000000"/>
</svg>

Example 1. The S2 SVG code

<svg version="1.1" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink"  id="svg-root" width="100%" height="100%"
   viewBox="0 0 480 360">
   <title id="test-title">monitoring-02-t</title>
   <g id="buildings-set-0">
     <rect id="building-0" fill="silver" stroke="#000000"  x="50" y="50" width="50" height="100"/>
     <rect id="building-1" fill="silver" stroke="#000000"  x="150" y="50" width="50" height="100"/>
     <rect id="building-2" fill="silver" stroke="#000000"  x="250" y="50" width="50" height="100"/>
     <rect id="building-3" fill="silver" stroke="#000000"  x="350" y="50" width="50" height="100"/>
     <rect id="building-4" fill="silver" stroke="#000000"  x="50" y="200" width="50" height="100"/>
     <rect id="building-5" fill="silver" stroke="#000000"  x="150" y="200" width="50" height="100"/>
     <rect id="building-6" fill="silver" stroke="#000000"  x="250" y="200" width="50" height="100"/>
     <rect id="building-7" fill="silver" stroke="#000000"  x="350" y="200" width="50" height="100"/>
   </g>
   <circle id="object-0" cx="225" cy="175" r="20" fill="red" stroke="black" />
   <text id="name" x="10" y="340" font-size="40" stroke="none" fill="black">Monitoring</text>
   <rect id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000000"/>
</svg>

Example 2. The S1 SVG code

<svg version="1.1" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink" id="svg-root" width="100%"
   height="100%" viewBox="0 0 480 360">
   <title id="test-title">control-01-t</title>
   <g id="test-body-content">
     <g font-family="Helvetica" font-size="14" text-anchor="end"  stroke-width="3" >
       <text x="80" y="244">100</text>
       <line x1="80" y1="240" x2="200" y2="240" fill="none" stroke="green" />
       <text x="80" y="124">3</text>
       <line x1="80" y1="120" x2="200" y2="120" fill="none" stroke="green" />
       <rect id="control1" x="100" y="80" width="100" height="160" fill="red" stroke="blue" stroke-width="4" />
       <text x="305" y="244">200</text>
       <line x1="305" y1="240" x2="425" y2="240" fill="none" stroke="green" />
       <text x="305" y="124">10</text>
       <line x1="305" y1="120" x2="425" y2="120" fill="none" stroke="green" />
       <rect id="control2" x="325" y="80" width="100" height="60" fill="red" stroke="blue" stroke-width="4" />
     </g>
   </g>
   <text id="revision" x="10" y="340" font-size="40" stroke="none" fill="black">Controls</text>
   <rect id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000000"/>
</svg>

Example 2. The S2 SVG code

<svg version="1.1" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
   xmlns:xlink="http://www.w3.org/1999/xlink" id="svg-root"
   width="100%" height="100%" viewBox="0 0 480 360">
   <title id="test-title">control-01-t</title>
   <g id="test-body-content">
     <g font-family="Helvetica" font-size="14" text-anchor="end"  stroke-width="3" >
     <text x="80" y="244">100</text>
     <line x1="80" y1="240" x2="200" y2="240" fill="none" stroke="green" />
     <text x="80" y="124">3</text>
     <line x1="80" y1="120" x2="200" y2="120" fill="none" stroke="green" />
     <rect id="control1" x="100" y="80" width="100" height="160" fill="red" stroke="blue" stroke-width="4" />
     <text x="305" y="244">200</text>
     <line x1="305" y1="240" x2="425" y2="240" fill="none" stroke="green" />
     <text x="305" y="124">10</text>
     <line x1="305" y1="120" x2="425" y2="120" fill="none" stroke="green" />
     <rect id="control2" x="325" y="80" width="100" height="160" fill="red" stroke="blue" stroke-width="4" />
     </g>
   </g>
   <text id="revision" x="10" y="340" font-size="40" stroke="none" fill="black">Controls</text>
   <rect id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000000"/>
</svg>

Example 3. The S1 SVG code

<svg version="1.1" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
id="svg-root" width="100%" height="100%" viewBox="0 0 480 360">
  <title id="test-title">sensor-02-t</title>
  <g id="test-body-content" font-family="Helvetica" font-size="30">
     <line x1="190" x2="190" y1="45" y2="300" stroke="#880000" stroke-width="4"/>
     <line x1="460" x2="460" y1="45" y2="300" stroke="#880000" stroke-width="4"/>
     <text x="156" y="32">0-2 </text>
     <text x="400" y="32">200+ </text>
     <g id="sensor-a">
        <rect x="160" y="60" width="300" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
        <text x="20" y="85" fill="red">a</text>
     </g>
     <g id="sensor-c">
        <rect x="160" y="140" width="130" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
        <text x="20" y="165" fill="red">c</text>
     </g>
     <g id="sensor-e">
        <rect x="160" y="220" width="120" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
        <text x="20" y="245" fill="red">e</text>
     </g>
     <g id="sensor-f">
        <rect x="160" y="260" width="200" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
        <text x="20" y="285" fill="red">f</text>
     </g>
  </g>
  <text id="name" x="10" y="340" font-size="40" stroke="none" fill="black">Sensors</text>
  <rect id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000000"/>
</svg>

Example 3. The S2 SVG code

<svg version="1.1" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
id="svg-root" width="100%" height="100%" viewBox="0 0 480 360">
  <title id="test-title">sensor-02-t</title>
  <g id="test-body-content" font-family="Helvetica" font-size="30">
    <line x1="190" x2="190" y1="45" y2="300" stroke="#880000" stroke-width="4"/>
    <line x1="460" x2="460" y1="45" y2="300" stroke="#880000" stroke-width="4"/>
    <text x="156" y="32">0-2 </text>
    <text x="400" y="32">200+ </text>
    <g id="sensor-a">
      <rect x="160" y="60" width="300" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="85" fill="red">a</text>
    </g>
    <g id="sensor-b">
      <rect x="160" y="100" width="30" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="125" fill="red">b</text>
    </g>
    <g id="sensor-c">
      <rect x="160" y="140" width="130" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="165" fill="red">c</text>
    </g>
    <g id="sensor-d">
      <rect x="160" y="180" width="80" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="205" fill="red">d</text>
    </g>
    <g id="sensor-e">
      <rect x="160" y="220" width="120" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="245" fill="red">e</text>
    </g>
    <g id="sensor-f">
      <rect x="160" y="260" width="200" height="30" fill="#FFAA44" stroke="#FF00FF" stroke-width="4"/>
      <text x="20" y="285" fill="red">f</text>
    </g>
    </g>
    <text id="name" x="10" y="340" font-size="40" stroke="none" fill="black">Sensors</text>
    <rect id="test-frame" x="1" y="1" width="478" height="358" fill="none" stroke="#000000"/>
</svg>

Bibliography

[Mobile SVG]
Mobile SVG Profiles: SVG Tiny and SVG Basic , Tolga K. Capin, Editor, W3C, W3C Recommendation, 14 January 2003. See http://www.w3.org/TR/SVGMobile.
[DOM Level 3 Load and Save]
Document Object Model Level 3 Load and Save Specification , J. Stenback, A. Heninger, Editor, W3C, July 2002. See http://www.w3.org/TR/DOM-Level-3-LS.
[SVG 1.1]
Scalable Vector Graphics (SVG) Version 1.1 Specification , Dean Jackson, Editor, W3C, 15 February 2002, See http://www.w3.org/TR/SVG11/.
[XML 1.0]
Extensible Markup Language (XML) 1.0 (Second Edition) , T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler,, Editors, W3C, 6 October 2000. See http://www.w3.org/TR/REC-xml/.
[Jabber]
Jabber Protocol , Jabber Software Foundation, 2002. See http://www.jabber.org/protocol/xmlstreams.html.
[TinyLine]
TinyLine Project , Andrew Girow, 2002-2003. See http://www.tinyline.com/.

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.