Pramod Jain

Subscribe to Pramod Jain: eMailAlertsEmail Alerts
Get Pramod Jain: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Java EE Journal, XML Magazine

J2EE Journal: Article

Data Driven Web Graphics with SVG: A Declarative Approach

Data Driven Web Graphics with SVG: A Declarative Approach

Scalable Vector Graphics is likely to revolutionize the way Web graphics are rendered, stored, manipulated, and associated with content. SVG, a 2D portable Web graphics standard recommended by the W3C in September 2001, is an XML-based standard for specifying both graphics and content. SVG replaces server-side image file creation or applet-based graphics with client/Web browser-based rendering of images.

This article focuses on Web annotation applications in which users draw on a Web browser and associate properties with the drawing. The graphical and nongraphical (business) properties of the annotations created by users are stored in a database.

The appeal of SVG is that it's data driven, not bitmap driven, meaning that the graphical content of an image is described in SVG as a sequence of commands to draw a line from one point to another, draw a circle with a specified center and radius, and so on. Thus the entire SVG image is created, stored, and rendered using commands and data in an XML format.

This article presents a declarative approach to creating a middle tier for SVG applications. The J2EE/XML-based middle tier:

  • Updates data sources (relational databases, EJB, and/or Java objects) with data in SVG files
  • Delivers SVG XML files with graphics and business data extracted from data sources.

    The declarative approach requires no coding in Java or VB. Instead, the SVG application is created by declaratively specifying:

  • Data sources (relational databases, EJB, Java objects, and others)
  • Data methods (SQL, stored procedures, Java objects) for retrieving data from and updating data into data sources
  • Tag-based JSP or XSL-based transformations for placing collected data into an SVG XML file

    The intent of this article is to provide insight into the rapid development of SVG-based Web applications that contain both graphical and business content. Applications of this approach include Web simulation, Web charting, Web reporting, and Web-based image annotation.

    The Appeal of SVG
    Although currently popular browsers like Internet Explorer and Netscape don't render SVG directly, plug-ins to the browsers from Adobe (SVG Viewer) and others will render an SVG document. We believe that because SVG is a W3C standard, it will be supported by future releases of browsers.

    SVG has a number of characteristics that make it appealing for Web graphics - for example, vector graphics. All the graphical information is stored in a sequence of commands to draw lines, shapes, and other objects. This information is eventually converted to a display application-specific bitmap, also called raster graphics. SVG is converted to a raster image by a vendor-specific program.

    SVG is also scalable. Zooming into an SVG image doesn't distort the image (by producing jagged edges) because redrawing instructions are sent to the rendering program, rather than pixel values in a bitmap.

    Being XML-based, SVG is data driven. It specifies an XML format for vector graphics commands. In addition, the SVG XML file can include business data tied to the graphical objects. Listing 1 is a simple SVG code for creating a ball object by first creating a graphical element - a circle - and associating properties like weight, material, and price with it. (To try out the example, download the SVG plug-in for your browser [one source for the plug-in is]; create a new file, circle.svg; copy the code into the file; open it from the Web browser. All the examples have been tested on IE5.5 with Adobe's SVGViewer.)

    Data driven in this case means that the center of the circle and the radius are specified explicitly. SVG makes Web graphics declarative: an SVG XML file declaratively specifies the properties of a drawing element. This is substantially different from bitmap-based graphics like GIFs or JPEGs.

    SVG is like HTML in that the source code for what's displayed in a browser can be viewed, making it easier to learn. <g> is a group tag. The three properties of the ball are accessible through JavaScript by walking through the DOM (Document Object Model) of SVG. For example, it can be programmed in JavaScript to display the three values in three input text boxes when a user clicks on the circle, and it can update the values in DOM when a user changes values in the text boxes.

    The SVG specifications contain the DOM, an API for accessing, adding, deleting, and changing the contents of the SVG-XML document. For instance, interactivity and animation can be controlled by JavaScript. The example in Listing 1 is modified to illustrate this point:

    <g id="ball" onmousedown="DoOMD(evt)" onmouseup="DoOMU(evt)">
    <circle cx="200" cy="200" r="100"/>

    In this example, when the user clicks down on the ball, an event is generated.This event is processed by a user-defined JavaScript function, DoOMD().

    For animation consider the following, where an onmouse click increases the radius of the ball from 100 to 200 in one second:

    <svg width="800" height="440">
    <g id="ball">
    <circle cx="200" cy="200" r="100">
    <animate begin="click" attributeName="r" from="100" to="200"
    dur="1s" fill="freeze"/>

    Furthermore, using SVG DOM, mouse events captured by JavaScript can be used to draw. This allows drawing and annotation on the Web browser. For examples of such tools see SVG Editor by Adobe at The focus of most SVG applications thus far has been on creating better Web pages using SVG. The focus of this article is data-driven business applications with an emphasis on creating graphical and business content from a browser.

    Declarative Framework for SVG Applications
    Floor Plan Example
    The remainder of this article will use the floor plan of a building for illustrative purposes. Users should pull up a digital image (GIF or JPEG file) of the floor plan and review existing and create new annotations for locations of electrical outlets, phone jacks, and Ethernet jacks, then save the changes into a database. Annotations will take the form of rectangles: red for electrical outlets, blue for phone jacks, and green for Ethernet jacks.

    In addition to the graphics, the user has to specify the number of electrical outlets and phone and Ethernet jacks at each location, as well as the IP address.

    In the example in Listing 2, the appeal of SVG is that on a Web browser annotation markings (AM) can be created on the floor plan using drawing tools, and annotation properties (AP) can be associated with the markings. While AM and AP are created on the browser, JavaScript populates the DOM with AM and AP data. When the user saves the annotation, JavaScript takes the content of the DOM, creates an XML file, and sends it to a middle-tier application. The middle-tier application then stores the data in the database. In the other direction the middle tier creates the SVG XML file by extracting data from the database and delivers it to the browser.

    The example in Listing 2 will be used to illustrate how the declarative nature of SVG can be combined with the declarative nature of the middle tier to rapidly deliver scalable applications. With this combination there is little or no Java coding to build SVG-based enterprise Web applications.

    The example in Listing 2 is used in two ways:
    1.   To create Annotation Markings and Properties (AMP): When a user enters the floor plan example for the first time, the drawing canvas will be empty. The user will see a background image of floorplan.jpg. As the user creates AMP, the contents inside the drawing canvas will be created in the DOM. When the user saves, JavaScript will create the SVG XML file in Listing 2 from the DOM and submit it to the middle tier, which extracts the AMP data and inserts it into the database.
    2.   To display AMP with data extracted from data sources: When the user asks to see AMP created in the previous step, the middle tier executes data access methods on the database or other data sources and converts relational and nonrelational data returned by data access methods to an infoset (a hierarchical data model for XML). Next, the middle tier transforms the generated infoset into the SVG XML file using one of the available transformations - XSL, JSP, or tags - and delivers the file to the browser

    The database schema in Figure 1 illustrates the example. A layer is like a transparency placed over an image on which a user draws annotations. It contains multiple markers, each either a "hand-drawn" image (custom icon) or a standard predefined icon (the elements defined inside the <defs> in Listing 2). Each marker is associated with multiple properties.

    Overall Process
    The internals of the middle tier are described later; however, the tier is completely controlled by declarative specifications contained in two files, DDS and DTS (see Figure 2). A programmer constructs an application by creating a Declarative data source and a Data access and update methods Specification (DDS) along with a Declarative Transformation Specification (DTS). DDS specifies data sources, access methods, and update methods. Using the API of the middle tier, plug-in modules can be written to interface with other data sources. An example of DDS is provided in later sections of this article.

    A user request from a browser contains a request name that points to a section of the DDS XML file containing data access or update methods executed on the database. The returned data is held in the middle tier as XML infosets (an example of the data format is given later). The data is then transformed using the transformation method (XSL, JSP, and tags) and an associated file specified in DTS.

    Approaches to Updating the Database
    Three declarative approaches are discussed in this section with the goal of simplifying the saving into and extracting from data sources while enhancing maintainability, that is, making it easy to change and enhance the application. In the simplistic approach JavaScript submits the SVG XML file and individual data fields to be put in the database. The middle tier then inserts the entire XML file in a CLOB field of the database, and the individual data elements are updated into the database.

    Following is an example of how this is done declaratively: Submit URL = http://ip/servlets/UpdateServlet

    Entry into the DDS file for the request named updateAnnotation will be data source-specific. For example, if the data source is Oracle, a call to the stored procedure updateAnnotation may look like this:

    call updateAnnotation({xmlfile},{field1},{field2}).

    For the XPATH approach we created a concept called Transparent Data Pipelines that has been used successfully to bridge the gap between the HTML pages and relational databases. In this approach an incoming HTML document is processed by calling a series of data access and update procedures in a transactionally secure manner. These procedures are declared in an XML/properties file. The necessary parameters for the procedures are culled from the incoming HTML form.

    This approach is extended for incoming XML documents so parameter values can be culled directly from the XML document, using XPATH expressions. This gives the added flexibility to get at values that are hierarchical. Multiple repeated nodes can be accessed by specifying an XPATH repeated node attribute on the business procedure (in the DDS file) and repeating that procedure for each instance of the node.

    One of the pros of this approach is its ability to call multiple procedures declaratively using the incoming XML document as input. In addition, XPATH allows for a rich set of selections for parameters. It is a declarative approach with no Java or JDBC code, which results in fewer bugs. It also provides transparent transport of XML data back and forth from data sources.

    Some of the cons are that the XPATH approach can't cover all the ground that custom Java code can, complexity increases when multivalued items and conditional storage have to be taken into account, and error handling is less sophisticated.

    We're exploring the XSLT approach in greater detail because it provides a complete approach to processing the incoming SVG XML file and updating all the data sources. This keeps the benefits of the previous approach while addressing some of the drawbacks. XSLT will be employed on the incoming SVG XML document to generate a set of procedures that will then be executed. XSLT (see Listing 3) will process the incoming SVG XML document and create an exec-XML (see Listing 4). The exec-XML contains all the procedures to be executed and arguments to these procedures. The overall process (diagrammed in Figure 3) is as follows:
    1.   A complete set of procedures is defined declaratively in the DDS file.
    2.   An XSL document is created for the incoming XML file.
    3.   Embedded in the XSL document are references to procedures specified in step 1.
    4.   When the XSL document is processed, it creates an exec-XML document (in-memory) containing the procedures to be called, along with their parameters.
    5.   This exec-XML document is processed and all procedures mentioned are executed to update the database with AMP.

    While Figure 3 illustrates the process, the examples in the following listings provide details of the relevant inputs and outputs. Input XML is the floor plan example cited earlier. Listing 3 is an XSL transformational file that generates the "exec-XML" executable file in Listing 4.

    The middle tier processes the exec-XML file and executes each of the execProc statements. RequestName from the execProc is used as a lookup key into the DDS. The remainder of the argument string is called execProcArgs. The code snippet in the next section is the structure and content of the DDS file that supports the execProcs.

    DDS File
    Data sources, update methods defined declaratively

    Following is an example of the Oracle database specification in the DDS file:
    <!-- section 1 of dds.xml -->

    This definition is used every time "MyDataBase" is referenced in code. Note that the DDS file contains the declarative specification of the data update method. In the example below, sp_updateUse is a stored procedure that will parse the arguments passed through execProcArgs and update the database.

    <!-section 2 of dds.xml -->
    <UpdateExec name="updateUse">
    <stmt>call sp_updateUse(?,{execProcArgs})</stmt>

    The entire execXML file is executed in a single transactional context. It's possible to apply a variety of transactional modes to support the requirements of the transaction.

    In summary, the approach presented here takes an SVG XML file submitted by the browser, applies an XSL transform to extract the data, and creates an execution XML file. This file is then run by the middle tier to update the database. XSL and stored procedure are the two programs that have to be created to accomplish this task.

    Approaches to Creating SVG XML Files from Data
    Creating SVG XML data from data sources follows the same declarative approach advocated above. The process is as follows:
    1.   A series of procedures in DDS is defined to retrieve the data.
    2.   The middle tier generates an internal XML document with a predefined structure.
    3.   A transformation (like XSLT, tags, or JSP) on this internal XML data structure is then used to arrive at the target SVG XML.

    The three examples in Listings 5-7 illustrate the nature of transformations. The first two are tag based; the third, JSP based.

    Template SVG file
    The first example is of tag-based transformation. The input tag file is in Listing 5.

    Compare the template file to the desired SVG file. All the drawing elements in the canvas have been replaced with a loop tag, loop1. Inside the loop tag is a replacement tag {{gElements}}. The middle tier transforms the template file by replacing loop1 and the {{gElements}} with rows of data obtained from data sources. In this example the entire XML code for the element is obtained from the database.

    Next, examine the data access specifications to gather data from the data source mentioned above. The userid is passed in from the HTML page, which returns one row from the layer table with the layerid. This value is used in loop1 to get the entire SVG segment for a marker (see Listing 6).

    An alternate method is to return individual data elements from the database and replace them in the template file. The template file in Listing 7 is much larger, with all the XML code (interspersed with replacement tags) for the drawing elements in the canvas. The associated DDS are similar to the one in Listing 6 but contain two loops.

    JSP-Based Transformation
    Programmers familiar with Java may want to use JSP to transform the retrieved data to SVG XML. The example in Listing 8 shows how this is accomplished. The JSP sections are highlighted for clarity. The associated DDS are the same as in the previous example.

    The process is as follows:
    1.   Retrieve a Java interface representing the entire data set: IFormHandler.
    2.   Report any errors if this object is null.
    3.   Retrieve a Java interface representing a loop of data: IControlHandler3.
    4.   Iterate through the loop: gotoNextRow().
    5.   Retrieve values from the current row: getValue(key).
    6.   Complete the document.

    XSLT to Generate the Target SVG-XML
    The data set retrieved in the middle tier is XML, and the target SVG is XML. It's certainly straightforward to write XSLT to convert from one XML to the other. As a result, the XSLT sample code is not shown here.

    Format of the Retrieved Data Set
    The relationship between the tag elements and named procedures in the DDS is accomplished through a conceptual XML data model (infoset) of the retrieved data from named procedures. This XML data structure plays an important role in tags, XSLT, and JSP transformations. This well-defined data model is the cornerstone for allowing pluggable data sets in the back end from any sort of data source. The middle tier is responsible for generating and maintaining an efficient version of this data model and making it available for transformations (see Listing 9).

    The data set is essentially a collection of key/value pairs and loops derived from the key/value pairs. The loops themselves are a collection of rows. Each row again contains a collection of key/value pairs and more derived loops.

    Specification of Transformations to Create SVG
    DTS is responsible for specifying which of the preceding transformations is actually used to obtain the target SVG XML. Listing 10 is one such example specification.

    Note that "getMarkers" is the same name used in section 2 of dds.xml. After the middle tier creates an XML document using the getMarkers specification, DTS.xml transforms the XML using the getMarkers specification. As seen in Listing 10, depending on the Java class and the template transformation file (floorplanTemplate.svg), the source data set is transformed to the appropriate output (floorplan.svg).

    General Architecture
    In depicting how browsers are connected to the middle tier, and hence to the data sources via DTS (Transformations) and DDS (Data), Figure 4 puts in perspective how such a middle tier can be architected.

    We borrowed this architecture from one of our implementations of it - Aspire, a J2EE/XML-based middle tier (for details see The architecture allows:

    • Multiple output formats (HTML, XML, text)
    • Multiple choices for transformations (JSP, XSL, tags)
    • Use of standard J2EE principles
    • Data gathering and transformation, specified declaratively
    • Access to any data source through well-defined plug-ins
    We've presented a declarative approach to creating SVG-based applications for creating, editing, and displaying graphics, and associating properties with the graphical elements. The approach is standards based, widely deployable, and doesn't require Java programming (when working with relational databases as the data source). All the data and transformation-related specifications are put in external files, and not hard-coded into the middle tier.

    SVG References

  • SVG specifications:
  • Watt, A.H. (2001). Designing SVG Web Graphics. New Riders Publishing.
  • Eisenberg, J.D. (2002). SVG Essentials. O'Reilly XML.
  • Jain, P. (2002). "Data-Driven SVG Apps: A Rapid Development Approach," February:
  • SVG tutorials, sample programs, SVG Viewer, others:
  • PopCharts ImageServerPro: Commercial SVG-based product for graphs and charts; Web-based data-driven charting solution, using charting templates.
  • Komatineni, S. (2001). "Applying Java/XML/XSLT Technology:
    Developing Web Applications Powered by Relational Databases." XML-J,
    Vol. 2, issues 4,5. Using TDP to convert relational data to XML data
    on the fly.
  • -."A JSP Architecture for Oracle Stored Procedures." Java Report, July. Stored procedures as plug-in adapters developed for declarative middle tier.
  • More Stories By Pramod Jain

    Pramod Jain is president of Innovative Decision Technologies, Inc. (INDENT,, in Jacksonville, FL. Their clients include Recruitmax, NASA, and NIH. Pramod has a PhD from the University of California, Berkeley.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.