Painting by Numbers with SVG

Last week XML-Deviant commented on the warm welcome that the Simple
Vector Graphics (SVG) specification was receiving from the developer community.
This week we take a closer look at the technical details of SVG.

Now that we had a nice "In praise of SVG" thread, I think it
is now time for a bit of roasting to see if any loose parts
fall[s] off. If SVG is so great, I think it deserves some more
peer review.

As a starting point, Park picked out the SVG "path" element. The path
element defines the shape of an object using instructions similar
to those of a pen plotter, e.g., move here, draw, move here, etc. Here's
an example taken from the spec:

<path d="M 100 100 L 140 100 L 120 140 z"/>

(See the specification for
more details.) Park wondered whether this was a proper use of XML, and invited
the Working Group members to address his concerns:

Why on earth would anyone stuff this
much data into a single attribute? Why not use child elements
instead of M for moveto in a monster attribute? Why bother with
[a] short non-intuitive attribute name like 'd' when its size of its
value can be so big? How am I supposed to parametize SVG graphics
if everything is hardwired?

There has been some discussion [on XML-DEV] concerning
SVG's <path> element and why the SVG working group decided to pack a whole
bunch of information into the 'd' attribute rather than have separate
elements for each path command, such as a <moveto> element. In the spirit
of fostering communication, I'll attempt to address some of [these] questions.

Ferraiolo explained that the overriding
concern lay with the potential size of SVG files. A verbose XML syntax not only increases
the size of a file, but also imposes additional memory overheads when constructing a DOM tree.

The SVG working group thus had a couple of existing languages to
study and present to users for feedback. Typically, PGML files would be
twice as big as the corresponding VML files. Plain and simple, this size
increase was determined to be unacceptable. Thus, SVG's approach to path
data has turned out to be more like VML than PGML.

Ferraiolo's replies, and the resulting discussion, serve as an interesting datapoint in the eternal
"elements versus attributes" debate.

Few contributors were convinced that the size savings earned by using attributes over elements were significant. However "Didier's Labs" confirmed that a verbose syntax did cause overheads in the resulting DOM:

...my conclusion, up to now, is that for sophisticated SVG applications
like interactive technical manuals, the size of the DOM is very very
important. To have more elements would prevent more sophisticated
applications.

So what might be useful for XSL (since XSL seems to have been mentioned
quite often in this thread) is a specification of some XPath extension
functions for SVG, to break apart an SVG path and produce a node list
more easily accessed by XSLT.

This is an important issue. A relatively lightweight DOM is essential
to allow SVG to be manipulated within a browser. Server-side generation
of SVG graphics, however, will probably make extensive use of XSLT transformations.

Misguided attempts at accessibility
are patronizing as well as wasteful. Accessibility of SVG documents to
blind users will come either from accessible interfaces provided by
"mainstream" SVG display tools (in which case the internal representation
is completely irrelevant) or from specialized SVG-interpreting tools
(which can be assumed to fully parse the SVG and probably build a DOM out
of it; there's no reason to make SVG hack-parse friendly on their
account).

Is this requirement really "an SVG document should display its textual
content if loaded into a browser that supports only HTML"?

The last point is important and, if true, may provide the explanation
for several SVG design decisions. Path data may have been pushed into attributes
to avoid it being displayed on non-SVG aware browsers. We could be seeing
"legacy" browser implementations affecting the development of future web
standards. A definite cause for concern.

The syntax for the SVG path data is not XML. This means that an SVG implementation
must also include a "path data parser" to extract the relevant information. In essence
the SVG specification is two languages, XML and "path data."

We have attempted to put a few utility methods into the SVG DOM in order to
make it more convenient for scriptwriters to do their job. The ones that
are in the spec now are the ones people in the working group could think of
in anticipation and in advance of actually writing useful scripts. If
anyone has suggestions for utility methods in the SVG DOM, please send them
in.

However, Ferraiolo qualified the invitation, observing that:

...the utility methods most likely to go in are ones where the underlying
algorithms are already required in order to implement features in the spec...
As people have been pointing out, there is already plenty to implement.

There appears to be an interesting trade-off here. To reduce file sizes
to an acceptable level, path data in SVG is expressed in a custom syntax
(which in reality could be either attribute or element based). The downside
is that additional implementation is required to support this syntax. Don
Park commented on the trend towards "micro-parsing":

While I can certainly live with SVG as it stands now, I am concerned
over what I think is an increasing trend toward micro-parsing, which might
be [a] necessary evil in some XML applications, but detracts from [the] usefulness
of XML, DOM, and SAX. I think it started with CSS, which infected XML via
HTML, and lately SVG.

Stepping back from the details of SVG, its interesting to observe this
discussion in light of recent criticism of the W3C. Here, we've seen
the SVG specification editor making frank statements about key design decisions
within a public forum. The response was excellent. While not everyone agreed
with the decisions made, it at least became clear why they were made. There are benefits to be gained from this. Len Bullard commented on the practical value of open forums:

...the XML-DEV archive and list very often serves
as a source for practical design examples to groups not privileged
to share the contents of the closed W3C sources. Support for
XML-DEV is one means by which OASIS contributes to open forums
and open software development among ALL XML developers.

While XML-DEV is far from representing the entire XML community, its clearly an important resource, utilized by more than just its immediate membership.