SVG requires a parser in a parser?

Hello SVGers!

I read the SVG spec for the first time now and was surprised about the
implementation of paths.

using a construct of
<path d="M 10 10 L40 0" style="fill:none; stroke:black; stroke-width:100">
     <data d="L 20 20"/>
     <data d="L 0 20"/>
     <data d="L 20 0"/>
     <data d="z"/>
</path>

is more inconvenient too validate and parse than e.g:
<path closed="true" fill="none" stroke="black" strokeWidth="100">
     <M>10 10</M>
     <L>40 0</L>
     <L>20 20</L>
     <L>0 20</L>
     <L>20 0</L>
</path>

The number of bytes used is also only insignificantly higher and all entities
can be accessed and validated by generic XML parsers without having to parse
attributes again.
The same holds for this construct:
<image x="100" y="100" style="width: 100px; height: 100px" (...)/>

which IMO deserves a
<image x="100" y="100" width="100" height="100" (...)/>.

What are the reasons for the syntax as chosen by the SVG group?



Rainer Prosi
Heidelberger Druckmaschinen AG

Received on Thursday, 22 July 1999 11:50:15 UTC