Re: SVG and proper XML design

Hi, Chris-

Chris Lilley wrote:
> 
> 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 
> 
<snip/>
> 
> are easy generation from XSLT, easy parsing, re-use by pointing of coordinates.

Another upside of more discrete syntax would be for animation, both 
declarative and scripted.  The author would have finer control over 
individual path segments.

Right now, one has to parse out the whole path, which is not trivial, 
even with regex.  It also can be a problem if the UA has normalized the 
path statement, altering what the author expects to find.

I'm not convinced that this is an either-or situation.  I too would like 
to see a discrete path syntax as a longhand alternative for the existing 
syntax.  I'm curious if implementors would see this as a burden.


> 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).
<snip/>
> 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.

Actually, the EXI (Efficient XML Interchange) have also requested 
something like this, when I spoke to them in Boston in January.  They 
claim their schema-based compression would benefit from more atomic path 
structure.  So, this seems to be a topic worth discussing, at least in 
for some later version of the spec.

Regards-
-Doug

Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482

Received on Thursday, 12 April 2007 14:31:14 UTC