In addition to geometric shapes, SVG has advanced graphical text capabilities. In SVG 1.1, there are several elements specifically designed for the presentation of text. At the most basic level, there is the <text> element, which can have child <tspan> elements that can be positioned and styled independently of the other text content, like this:

Then there are more advanced options, like rotated text
or the <textPath> element

The future of SVG text support holds still more. In the next version of the SVG specification, SVG Tiny 1.2, there are even more useful text features, like the <textArea> element that automatically wraps text to a shape (rectangles on for mobile devices, but any shape at all in future versions of the specification). There is also the new ability to make any text editable by simply including an attribute to the text element. And there are great features from SVG 1.1 (the current version) that are not yet widely implemented, such as SVG Fonts, which let you embed a font into an SVG file so the reader sees the page the way the author intended it, and the <tref> element that lets you directly quote text without duplicating it. All these features will give more control to authors and give a better experience to users.

But is that enough?

The Study of Meaning

Semantics is the study of meaning; a cluster of dots in the shape of a word doesn’t mean anything to a machine, but real words and sentences can be connected to concepts, and that is why this is important in a graphical format like SVG. All of these text features really are text, not just images of text. They can be searched for, copied, indexed by search engines, and understood by screen readers. Screen readers are a kind of assistive technology that reads pages out loud for people with vision problems. It’s not just for people; machines like it, too. It has semantic value, and this moves us toward the Semantic Web. There is also the <switch> element, which is an excellent way to provide different text content, such as your own translations, depending on the user’s computer systemLanguage. Obviously, this adds meaning by disambiguating different possible translations that a computer-based translation might not catch (because people are smart, and computers are merely fast). And it’s not just the visible text that provides meaning, but also the metadata (or “data about data”). SVG’s <title>, <desc>, <metadata> elements are not rendered onto the screen (although the Opera browser does provide a tooltip for the title text), but can be indexed by search engines, and the use of script or special browser capabilites (such as native browser support for RDF, a special kind of markup that describes the relationship between terms used in the metadata) can provide extended functionality. As you might expect, the <title> and <desc> elements are meant to be human-readable, while <metadata> elements more frequently contain computer code.

A Semantic Argument

But in a recent post to SVG-Dev, a representative from Adobe pointed out some possible shortcomings of SVG’s text capabilities compared to HTML or PDF. Adobe is using SVG in its new Mars project, which is an XML version of their popular printable document format. Now, I don’t find HTML to have very much semantic content either (see this very long post on semantics from a couple of years ago), but Adobe’s Leonard Rosenthol points out that computers (specifically screen readers) can’t distinguish between paragraphs and columns of text, and particularly not tabular content (where each cell in a table has a context in both a row and a column). I don’t think that paragraphs or columns are particularly semantic (and certainly aren’t universal even among written languages). They are largely cosmetic print conventions, and although of course that matters for printed formats, it’s not as important for accessibility or spoken-word understanding, nor for machine understanding; although admittedly paragraphs do represent some structure (I’m having flashbacks to composition class in high school here), most often columns are simply a convenience of text flow within a constrained area and carry no distinction from one another, and where they do, it is typically simple tabular data. Tables are another matter, though, because of the specific associations involved in cell position. There are other semantic orthographic properties of documents that matter more than print conventions, and which have sometimes been passed off as merely stylistic, such as emphatic text (represented by boldface, italics, or relative font sizes) that is indicated by tone in spoken language.Acronyms, abbreviations, definitions, and quotations all have HTML representations (although they are too rarely used), and there is no equivalent of those tags in SVG (by design); but that meaning is limited to a specific knowledge domain, that of generic textual reference. There are other specific domains that have highly structured tagsets just dripping with meaning, like Chemical Markup Language (CML), Linguistics Markup Language (LGML), Music Markup Language (MML), MicroArray and Gene Expression (MAGE — contrasted with the almost inevitable Bible Markup Language)… mapping, geography, mathematics, psychology, literature, sociology, physics, architecture… every area of human endeavor has a systematic structure that is (or will soon be) encoded in some kind of tagging scheme, whether that be in the form of XML, RDF, or some other format. But these semantics are largely lost on the Web.

SVG has taken pains to avoid including specific semantics in the specification, in order to remain a neutral presenatation format. The only semantics are derived from the graphical geometry, which nevertheless can be extended to related domains like mapping and geography (and possibly feng shui). But it would be ideal if the underlying structure carried all the rich semantics of the graphical data being presented, if a circle were identified as an atom, or a rectangle were a flowchart box, if your computer knew what we know when we look at something, or even explaining it to us when we don’t know what we’re looking at. These are true problems that need a solution. How can we add semantic properties to SVG, to the Web in general?

Technical Solutions

RDF

I’ve already mentioned RDF. This is one way to add extra information to the geometric presentation. Let’s use molecules as an example (see source):

The code would look something like this… I say something like this because A) this is only a snippet and B) I’m no RDF guru and I’m sure I got something wrong:

<svg>
<line x1='840' y1='170' x2='600' y2='170'>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="http://www.example.org/bond">
<m:atom_link rdf:resource="http://www.example.org/carbon-oxygen" />
</rdf:Description>
</rdf:RDF>
</metadata>
</line>

<g fill='gray'>
<metadata>
<rdf:RDF>
<rdf:Description rdf:about="http://www.example.org/carbon">
<m:bonds_to>
<m:oxgen rdf:about="http://www.example.org/oxgen" />
</m:bonds_to>
</rdf:Description>
</rdf:RDF>
</metadata>
<circle cx='400' cy='170' r='20'/>
<circle cx='400' cy='230' r='20'/>
<circle cx='600' cy='170' r='20'/>
<circle cx='600' cy='230' r='20'/>
<circle cx='500' cy='200' r='100' fill='url(#carbon_fill)'/>
</g>
</svg>

The <metadata> element as a child element is obviously associated with its parent, thus “tagging” it. There is no established method for placing the <metadata> element to best associate collections of elements, but setting it as a child of a <g> (group) element containing all the relevant children seems a likely choice. This allows us to say that circle is a carbon atom, and that line is a molecular bond. On the downside, RDF is a bit verbose, and it isn’t ideal to tag text.

Text content in RDF (or any given XML format) is not visible. This is because SVG dictates that content inside unknown elements (that is, elements not defined in the SVG specification) is not rendered, even if it is also the child of a <text> element.

Microformats

Microformats may be a good option here. While most people associate the class attribute with CSS styling, both the HTML and SVG specifications list one of its roles as “general purpose processing by user agents.” I haven’t seen any microformats user agents (browsers or other programs) that specifically support SVG, but it shouldn’t be hard. The basic syntax and functionality would be the same. Basically, you might say something like <text class=”acronym”>SVG<title>St. Vincent and the Grenadines</title></text>.

A minor problem with this is that SVG Tiny 1.1 doesn’t have the class attribute, but this should work fine with SVG Full, and SVG Tiny 1.2 does include the class attribute specifically for uses other than styling (e.g. micoformats). A potential negative with microformats itself is that since it is such a loose ontology, I’m not sure it will scale up to complex contexts, and I think that it will be subject to the same semantic drift that natural languages suffer (where one word takes on a new meaning, like “decimate”); in fact, since there will be no immediate feedback, as is present in spoken language, I think the drift will be accellerated. This makes for stale semantics down the line, but it will probably suffice for the short term (and who knows how long the content will last anyway?).

XBL2

Finally, there is a new technology being published by the W3C, one originating with Mozilla, called the eXtensible Binding Language (XBL2). Among other things, it allows an author to create templates that attach a presentation format, like HTML or SVG, to any arbitrary XML. So you could take your Chemical Markup, or Genealogy Markup, or whatever, and create XBL SVG templates for it. Whenever there is a element that matches one of your templates, the appropriate SVG (or whatever) markup is created and tied to the target element, preserving the original semantics while providing an appropriate visualization. Since this is a new technology, the obvious drawback to this approach is that there aren’t yet browsers that support it. Also, it may not be appropriate for mobile devices. But I think this will be the rich option available within the next couple of years.

Conclusions

SVG has inherent accessibility features, and specific built-in geometric semantics. With a little work, semantically rich documents and applications can be built using SVG in combination with the appropriate ontology and a semantic tagging mechanism.