Re: SVG and proper XML design

On Tuesday, April 10, 2007, 1:58:05 AM, Bill wrote:

BD> Quick summary:

BD>   The fact that the "d" data attribute in the "path" tag requires some
BD> unnecessarily compressed string syntax does completely violate good
BD> XML grammar design.

Skipping straight to your final paragraph - yes, it has been discussed before. It was a conscious decision to design SVG like this; the obvious alternative of an element-heavy syntax for path data was considered.

However, thanks for writing up the issue so clearly and carefully.

The benefits of an element-based syntax such as 

<path>
 <command action="move" type="absolute">
   <acoord x="23" y="-58"/>
 </command>
 <command action="line" type="relative">
    <rcoord x="20" y="40"/>
  </command>
   <command action="line" type="absolute">
    <acoord x="-60" y="50" id="point01"/>
  </command>
  <command action="closepath"/>
<path>

are easy generation from XSLT, easy parsing, re-use by pointing of coordinates.

The downsides are a substantial increase in content size, even when compressed, and a huge increase in the number of DOM nodes when parsed (and thus, memory footprint, in most implementations).

If SVG was a theoretical construct, not expected to be actually used on the web without being first transformed into something else, then an element based path would be an excellent idea.

If the aim is to actually use it directly, then (considering path data is by far the largest component of most graphics) little things like a 50 times increase in transmitted size and a 400 fold increase in memory footprint do start to become important.

This is true even when compression techniques like gzip or xmill are used. Despite the repeating strings in the above example, it is still larger when compressed than the current path element, compressed or not.

So your point is well made, except for your "unecessarily compressed" and "meaningless savings in space". In real world usage, these are far from meaningless and far from unnecessary.

There is also a question of granularity to consider. Most text based markup languages (docbook, html, etc) only provide granularity down to the level of components that are expected to be styled differently or interacted with differently. As an example, no-one is shocked to see:

<p>This is an example, albeit <em>somewhat</em> contrived,
of Chris making a point to Bill by way of some simple
markup. he hopes.</p>

Woefull use of long-string syntax! The individual sentences are not indicated, far less verbs, nouns, prepositions. There is no markup to indicate syllables or stress patterns when spoken. The "he" is not linked to "Chris" to resolve the Chris or Bill ambiguity.  Plus its a mixed content model.

In other words the granularity is at the paragraph level, with occasional phrase-level elements.

In SVG, the granularity is at the graphical object level (path, basic shape, etc). An element represents one shape.

BD>   I believe that SVG would be much more widely adopted if it were
BD> easier to implement. For the longest time, I was discouraged by the
BD> lack of implementations of SVG parsers and renderers-- which is why I
BD> started to write my own.

What language are you writing in? There are SVG path syntax parsers available in various languages. Are you generating, or consuming, or rendering SVG?

BD>  But as I got more involved, I discovered that
BD> SVG is not as easy to handle as other XML languages, and required a
BD> lot of extra unnecessary work.

Extra work, agreed. unnecessary work, no.
 


-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Tuesday, 10 April 2007 14:37:08 UTC