The Next Generation of SVG Files: SVG Fragments

Keywords: XML, SVG, XLink, WebCGM, URI, Web Services

Benoît Bézaire
Software Developer
Corel Corporation
Ottawa
Ontario
Canada
benoit.bezaire@corel.com
http://www.corel.com/smartgraphics

Biography

Benoît Bézaire is a Software Developer with the Smart Graphics team at Corel. Benoît has extensive knowledge of SVG (Scalable Vector Graphics) and played a key role in the development of Corel Smart Graphics Studio. Prior to joining the Smart Graphics team, Benoît worked with Corel's Creative Applications group on a number of products including CorelDRAW and Corel Painter.

Benoît represents Corel on a number of industry technical committees including the W3C SVG Working Group and the CGM Open organization. He graduated with a Bachelor of Applied Sciences, Computer Engineering, from the University of Ottawa.


Abstract


Until now, the most common SVG workflow has been to use an authoring tool (native or not) to create stand-alone SVG files ready to be consumed by a viewer. This situation exists because SVG is not being used to its full potential.

SVG can accomplish much more than developers may currently believe to be possible. The typical stand-alone document workflow might be adequate for some, but it is not powerful enough to address all of the needs of public and private enterprises and spur wide-spread adoption of SVG technology. The typical producer/consumer workflow that we are familiar with is about to change.

We are entering into a new era when people will no longer be asking for SVG stand-alone documents. Instead, they will be looking for SVG fragments. The producer will no longer be limited to generating only the final-form SVG, but will now be able to create reusable assets. This paper suggests methods for improving some of the painful workflows that enterprises are currently confronting. These include:

I believe that introducing the use of SVG fragments in these workflows can greatly improve the situation. I will identify some unused features in the form of SVG elements and properties, and demonstrate how they can be used to simplify these painful workflows.

Enterprises require - and are asking for - SVG fragments. A new generation of tools is about to take advantage of the untapped potential of SVG. Graphics artists and developers will use the Web to share and publish SVG assets for third parties to consume or reuse. The era of smart, live, and reusable SVG assets has arrived.


Table of Contents


1. Vector Graphics and the World Wide Web
2. Requests from Enterprises
3. What's a URI?
4. The SVG 'use' and 'tref' elements
5. Using SVG fragments
6. Conclusion
Bibliography

1. Vector Graphics and the World Wide Web

Over the past 15 years the WWW (World Wide Web) has experienced a dramatic evolution. In the early days, Web developers handcoded static HTML documents. To improve this workflow, and make coding HTML easier, vendors introduced HTML authoring tools; but the Web remained mostly static. Just a few years back, before the recent boom of Internet accessibility, the Web was still very much text based. Pressure from enterprises forced alterations to the original structure of the Web. The image below gives a visual representation of this evolution (image from Steve Bratt, W3C Technical Planery 2003):

W3C_block_specs.png

As shown in the diagram, today's Web developers have a much broader range of technologies at their disposal - URIs, XML, SVG, XSLT and Web Services, just to name a few. One of the many breakthroughs of the W3C (World Wide Web Consortium) was to satisfy the demand for a more graphical Web. The evolution of the WWW created a demand for a standard vector graphics language. The W3C satisfied that demand with SVG. We have seen several graphics formats (open standard and proprietary) that use some of the basic functionality that the Web offers, yet, it is my belief that today's vector graphic languages do not use the full power of the Web. Fortunately, in the case of SVG, this is about to change.

The vector language, SVG, was built on top of other W3C technologies such as URI references, XLink and XML. One of the reasons SVG is so powerful is because it was meant to work with these other technologies. The next generation of SVG files will be links to SVG fragments. The files will be decentralized and consist of sharable assets in different locations. These new SVG files will likely be a mix of static and dynamic content. Dynamic content will be generated from a Web service, a database or some other server-side deployment process.

Web content is becoming highly accessible. The inclusion of technologies such as Xlink and URI references in many areas of the current SVG specification offers powerful features that will soon be unveiled.

2. Requests from Enterprises

The topic of SVG fragments could be taken in many different directions. In this paper, I will focus on what I believe are the most important requests from enterprises. When it comes to markets that deal with graphical workflows, enterprises have expressed a strong need for the following capabilities:

The SVG files of today are still very much 'Web static'. They exist as separate entities on people's desktops. Enterprises are now asking for live, rich and interactive data-driven vector graphics. Enterprises would like parts of graphics to be easily updated based on new data. One of the typical examples is the stock market chart... People need an easy way to generate instant and accurate information in graphical form. This can be done today, but not cheaply or easily.

Enterprises are also asking for the ability to collaborate in the creation of graphical files on the Web. It is still fairly complicated to share individual components of graphical files; very few tools offer this type of functionality, however when they do, it represents a subset of what is possible to do with SVG. What if company A could work in collaboration with company B on the same graphical file? It would certainly be easier to do if the graphical file was componentized. In that case, company A could work on one fragment of the file while Company B worked on another fragment.

Manufacturing enterprises typically require technical illustrations. We often see graphical files which are basically a composition of pre-defined symbols or objects gathered from a library. The problems start to occur when the graphical representation of one of the symbols or objects is modified. The process of updating thousands of documents is lengthy. Companies are looking for methods that will reduce the time spent updating and maintaining such documents.

The same is also true for non-graphical elements. There is a common case in which the actual symbol or object doesn't change enough to require updating the graphical representation. However, it is still important to update the text-based information provided with the graphics, for example, part number: 1001-A becomes 1001-B.

These are only a few examples of high-cost problems enterprises are facing. From a technical standpoint, SVG in conjuction with a few companion technologies is probably the only technology that can satisfy the demands of enterprises. The next step is to take a closer look at SVG Fragments and study how they help solve these problems.

3. What's a URI?

The WWW is a network with many points of content. The W3C created the URI (Uniform Resource Identifier) as the mechanism to identify one point of content. URIs are a crucial aspect of the Web that are often taken for granted. With a URI, it is possible to distinguish any resource (text based, video, image etc.) over the Internet. Usually a URI describes:

Therefore, the following URI,

http://www.ietf.org/rfc/rfc2396.txt

identifies a file that can be accessed using http (Hypertext Transfer Protocol ) that resides on a computer called www.ietf.org. On this computer, the path required to access the file is "/rfc/rfc2396.txt".

The above example probably represents the general understanding of URIs. However, in most cases, SVG uses URI references. The difference between a URI and URI reference is that the latter can identify an absolute or relative location and also contain additional information in the form of a fragment identifier.

With this bit of additional information, things get quite interesting.

Another aspect of URIs that is very important is the query component. The query component is a string of information to be interpreted by the resource. The query information is widely used in Web Services or similar schemes. Take, for example, a Web Service that returns the day's high temperature and provides the option of using the Farenheit or Celcius scale.

In this case the query information is passing two parameters to the resource, city with a value of 'Ottawa'; and scale with a value of 'C'.

One has to wonder if the same concepts could be used in SVG? Absolutely! This is the key to Web-scalable data-driven graphics.

4. The SVG 'use' and 'tref' elements

Now that we have covered the basic concepts of URI references, let's investigate where they can be used in SVG. URI references are widely used in the language, the specification allows URI references on all of the following elements and properties:

As observed, one of the important features of SVG is the ability to use URI references. There are not many graphics formats that offer such control over URI references on graphical primitives. The implication here is that with most of the above elements, one can reference another element with a simple URI and some optional additional information such as a fragment identifier (#fragment) and/or a query component (?param=paramValue). As one can imagine, URI references are more useful on some elements than others. If I had to identify two elements for which URI references are most useful, I would choose the 'tref' and 'use' elements. I believe they offer more power to the user and help to solve the problems that enterprises are having today. The remaining part of this paper will focus on these elements and demonstrate what possible functionality they offer to Web developers.

It it my belief that one of the most powerful features of SVG 1.0/1.1 is the 'use' element. According to the SVG specification, any 'svg', 'symbol', 'g', 'use' or graphical element is potentially a template object that can be re-used (via the 'use' element). That, by itself, is a pretty strong statement. The 'use' element references another element and indicates that the graphical contents of that element are included/drawn at that given point in the document. It helps us to meet the requirements mentioned earlier in the paper. Here are some simple examples that use the 'use' element. First is a simple example of how to code SVG files with the 'use' and 'symbol' elements:

In ref.svg (defines a star asset/symbol):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
   <symbol id="simpleStar" viewBox="0 0 250 250">
	  <polygon points="124,5 153,91 243,91 171,145 197,231 124,180 51,231 77,145 5,91 95,91" />
   </symbol>
  </defs>
</svg>
	 
In source.svg (references the star asset/symbol):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100px" height="100px" viewBox="0 0 100 100" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <use x="0" y="0" width="100" height="100" xlink:href="ref.svg#simpleStar" fill="darkgray" stroke="lightgray" stroke-width="10"/>
</svg>
		

The file source.svg is rendered as follows:

star.png

Next is an example that re-uses the star symbol, but this time with transformations and CSS inheritance:

In ref.svg (defines a start asset/symbol):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
	<symbol id="simpleStar" viewBox="0 0 250 250">
		<polygon points="124,5 153,91 243,91 171,145 197,231 124,180 51,231 77,145 5,91 95,91" />
	</symbol>
  </defs>
</svg>

In source.svg (references the star asset/symbol):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="250px" height="250px" viewBox="0 0 250 250" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
	<radialGradient id="back" gradientTransform="skewX(18)" r="50%" fx="20%" cx="35%" cy="50%" fy="20%" color-interpolation="sRGB">
		<stop offset="30%" stop-color="black"/>
		<stop offset="80%" stop-color="rgb(100,100,100)"/>
		<stop offset="100%" stop-color="white"/>
	</radialGradient>
  </defs>
   
  <rect x="0" y="0" width="250" height="250" fill="url(#back)"/>
  <g fill="yellow">
   <g id="g1" fill="inherit" stroke="white" stroke-width="10">
    <use x="0" y="0" width="10" height="10" xlink:href="ref.svg#simplestar"/>
    <use x="32" y="74" width="10" height="10" xlink:href="ref.svg#simplestar"/>
    <use x="163" y="32" width="10" height="10" xlink:href="ref.svg#simplestar"/>
    <use x="132" y="132" width="10" height="10" xlink:href="ref.svg#simplestar"/>
   </g>
  </g>
  <g id="g2" fill="blue">
   <g id="g3" fill="inherit">
    <use id="use1" x="150" y="150" transform="scale(0.5)" xlink:href="#g1"/>
    <use id="use2" x="150" y="150" transform="scale(0.4)" xlink:href="#g1"/>
   </g>
  </g>
  <g id="g4" fill="orange">
    <g id="g5" fill="inherit">
      <use id="use3" x="5" y="25" transform="scale(1.3)" opacity="0.7" xlink:href="#g3"/>
      <use id="use4" transform="scale(1.5 1.25)" xlink:href="#g3"/>
    </g>
  </g>
  <use id="use5" x="0" y="-65" transform="rotate(30,125,125), scale(0.9)" xlink:href="#g5" fill="magenta"/>
  <use id="use6" x="-50" y="60" fill="red" xlink:href="#g5"/>
</svg>
		

The file source.svg is rendered as follows:

star2.PNG

The above examples demonstrate the basic syntax and concepts of the 'use' and 'symbol' elements. In the next section of the paper, we will use these concepts in more realistic industry examples.

If you understand the concept of the 'use' element, then it's easy to understand how the 'tref' element works. According to the SVG specification: the 'tref' element has an attribute which is a URI reference to an element/fragment within an SVG document fragment whose character data content shall be used as character data for the 'tref' element. It is, in fact, a more simple case than the 'use' element. In general the 'tref' element allows users to have the text content in an external XML file. In many scenarios, this is very valuable functionality. In the following section we will demonstrate how a feature like the 'tref' element can be used cost-effectively.

In ref.svg (contains character data asset):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
	<text id="linkToText">Referenced character data</text>
  </defs>
</svg>

In source.svg (references the character data asset):

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="300px" height="80px" viewBox="0 0 300 80" font-size="20" font-family="Serif" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
	<text x="10" y="35" fill="blue">Inline character data</text>
	<text x="10" y="60" fill="red"><tref xlink:href="ref.svg#linkToText"></text>
</svg>

		

The file source.svg is rendered as follows:

tref.PNG

5. Using SVG fragments

In this section, we demonstrate how to solve the problems that are mentioned above using the concept of SVG fragements. I am not suggesting that these are the only solutions available to users; there are often many ways to solve a problem. I am instead making some suggestions on how to create logical data-driven graphics using methods that will reduce the high maintenance cost of technical illustrations.

Using a Web service

Let's first take a look at one method a developer could use to add logic to a vector graphic illustration. We will assume that a certain airline wishes to offer a service on its Web site. The service will display the flight trajectory, the current plane location and expected time of arrival. SVG is, of course, the ideal technology for such an application. The user interface to this service is quite simple. It consitutes a combo box for selecting a flight number. Since the map of the globe contains a substantial amount of information, it would be expensive to transfer the entire map across the Web for every request. A better approach would be to only request the additional information. We will structure the additional information in the form of an SVG fragment. The map of the globe will be the background, and on top of it we will overlay, with the 'use' element, the information users have requested.

The solution on the client side is fairly simple. Once the user has made a selection, the URI reference on the 'use' element is updated. The URI in this case will link us to a .Net Web service. I have decided to use a .Net Web service in this particular example to demonstrate the high level of interoperability within URI references, SVG, and Web services. Another method to generate the SVG fragment could have easily been used. I will use different methods throughout this paper to generate SVG fragments, the intent is simply to demonstrate that the solution is achievable in many ways.

Therefore, the 'use' element in this example has an xlink:href attribute with a URI reference similar to: http://www.someairline.com/webservice?flight=473#flightinfo

In the above URI reference, everything in front of the '?' is the resource location. The string 'flight=473' is the query information which will be interpreted by the resource, in this case a Web service. Finally at the end we have '#flightinfo' which identifies the name of the fragment to overlay on our map. As mentioned before, on the client side the coding is relatively easy, someone simply has to update the flight number (i.e. fligth=473) within the URI reference of the xlink:href attribute for the 'use' element in question. Everything else is done on the server side. In this case, the Web service will gather the information requested throught the query string and create a small SVG fragment with the appropriate data.

flygo.PNG

Benefits of using an SVG fragment in the airline application:

Using external text content

The following example is a simplified version of a technical document usage scenario. Various industries such as the aerospace industry, the naval industry or the automotive industry, regularly have to update large numbers of technical illustrations. In a domain such as the aerospace industry, there exists a large set of governmental regulations. Aircraft manufacturers have to update their technical illustrations several times during the year to meet these regulations. They commonly deal with documents such as the one shown below. The following illustration is an exploded view of a small part of complex machinery. In many cases, we also see a detailed list of all the individual parts that create the component. Since the life span of the major aircraft models are often 20 years or more, these documents must be maintained for a long time. The part numbers are usually included in the illustrations to allow the maintance crew to more easily inspect and replace parts. Often, a specific part will change but the graphical representation of the part will remain the same. For example, if an alloy of a part changes, the illustration remains the same, but the documentation must reflect the new part number so that the maintenance crew is aware that the part has changed.

In the case of an airplane such as a Boeing 747-400 or an Airbus 330, tens of thousands of illustrations are required. It is easy to see that maintaining all these illustrations can be a lengthy process. One approach to simplifying the maintenance of these documents is to break the illustrations apart; that is, to separate the graphics from the text. We will, once more, use SVG fragments to simplify the workflow. In this particular case, the SVG fragment is very simple. The 'tref' element can be used. As previously mentioned in the paper, the 'tref' element has an attribute of type URI reference that points to an element who's character data will be used. In the case of a parts manual, maintaining the parts information in an outside XML file can be quite useful. Since the illustrations are often project based (specific aircraft, or a certain car model), all parts information is maintainable in external XML files. If a certain part becomes obsolete and is replaced by another one, the change can easily be made in the XML file that contains the parts data, and instantaneously, all relevant illustrations are updated.

parts.PNG

Therefore, by using the SVG 'tref' element, such as this:

 <text font-size="1.2em"><tref xlink:href="partRef.svg#ringClamp"></text> 
		

it is easy to separate the graphical content from the text content.

Benefits of using SVG fragments in a parts illustration application:

Reusing deployed symbols

The next example demonstrates the type of application that can be built using Web-deployed symbols. For the purpose of this presentation, the application has been scaled down in size and complexity. More and more systems integrators) are developing Web Applications for their clients. The applications are often visual representations of closed systems (hydro lines, water system etc...). In most cases, the applications have to represent the current status of the system. It is common to have multiple field stations which monitor these systems. In order to have everyone in field stations monitoring the same information, one logical approach is to share Web deployed symbols.

The following application is a visual representation of an emergency dispatch call system for highly populated cities. The Web application for a specific city is not entirely different from the Web application for another city. The layout and data will be different, but the concept is very similar. For that reason, it is a good practice to build the application with a "live symbols" library. In the case of a medical/securtiy type of workflow, there is a common set of standardized symbols that must be used. Since the symbols are shared, if one symbol is modified or updated, everyone using the application will get the latest visual representation.

In areas such as electrical, aerospace and medical, just to name a few, there is increasing collaboration between governmental agencies. Governments enforce guidelines for their agencies. In regulated industries, collaboration between different groups is sometimes difficult. A specific symbol for one agency may have a different meaning within another agency. The color schemes are sometimes different, it could be as simple as the colors yellow and blue having a different meaning in a North American agency than in a European agency. When dealing with mission critical information, it is crucial that it gets interpreted correctly. It is possible, in my opinion, to ease the collaboration between different groups by carefully using URI references and deployed SVG fragments. It would be interesting to request a symbol that is compliant to a certain style guideline simply by means of a query string on a URI reference. This is certainly possible with the appropriate SVG elements and the right SVG authoring tools. The method used to create this application consisted of using Corel Smart Graphics Studio to deploy a library of SVG assets onto the Web for other processes to consume. The application is using the query string of a URI reference to identify which symbols it should use, via the 'use' element, to generate the visual representation according to the specified guideline. With an application such as Smart Graphics Studio, it is easy to create Web-deployed SVG assets like the ones shown in this application. It is also quite easy to create Web-deployed assets which consume other Web-deployed assets. The simplified application demonstrates that this has a huge potential and is, in my opinion, the start of a new era.

query.PNG

Benefits of using SVG fragments in an emergency dispatch call system:

6. Conclusion

SVG 1.0/1.1 offers a rich set of features that provide solutions to real world problems. For example, the availability of features such as non-local URI references on the 'tref' and 'use' elements, in conjunctions with SVG tools such as the Corel SVG Viewer and Corel Smart Graphics Studio allows enterprises the opportunity to develop well-structured SVG files and powerful Web applications. The paper only focused on two SVG elements, but as enumerated in section 4, there are several others that could certainly be of use if investigated thoroughly.

When carefully designing documents or entire applications with SVG fragments in mind, content developers will gain these benefits:

The SVG tools (viewers and authoring applications), to take advantage of such features are making their debut on the marketplace. I believe that the quality of such features will improve and make the creation of cost-effective SVG Web Applications even easier. The SVG files of today are not the ones of tomorrow. SVG assets will be componentized and therefore easier to share, deploy and re-use. The SVG files are evolving -- they are becoming SVG fragements.

Bibliography

[Applicability of CGM versus SVG for technical graphics]
Applicability of CGM versus SVG for technical graphics at http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm
[CGM Open]
CGM Open Website at http://www.cgmopen.org
[Engineering the Web's Foundational Technologies]
Engineering the Web's Foundational Technologies at http://www.w3.org/2003/Talks/0305-sb-techplenintro/slide6-0.html
[SVG 1.1]
SVG 1.1 at http://www.w3.org/TR/SVG11
[SVG Implementations]
SVG Implementations and product table at http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8
[SVG Viewers]
SVG Viewers at http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8#viewer
[SVG Fragment Identifiers]
SVG Fragment Identifiers at http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
[URI references]
URI references at http://www.ietf.org/rfc/rfc2396.txt
[WebCGM]
WebCGM 1.0 Second Release at http://www.w3.org/TR/REC-WebCGM

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