Re: SVG requires a parser in a parser?

At 05:50 PM 7/22/99 +0200, Rainer Prosi wrote:
>
>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>

In designing CSS-styled XML grammars, you have four ways that you can
package data within the grammar:
(1) As character data instead of start and end tags (your method above)
(2) As child elements
(3) As attributes
(4) As CSS properties
No matter what approach you take, it is inevitable that someone is going to
disagree with your decision.

Regarding path data, the SVG WG looked at many possible formulations before
coming up with our current approach. We ruled out the approach you have
suggested above because we wanted only text to be expressed as character
data. I believe a key reason for this was that we thought it was important
that searching for the string "10" should find <text>10</text> but not
<M>10 10</M>.

A major design goal with SVG was small file sizes. We paid close attention
to feedback from implementors of PGML and VML in formulating path data
syntax. If you know VML, then you'll recognize that SVG borrowed a lot of
its approach to path data from VML. 

I think the approach to path data is unlikely to change much at this stage.

>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" (...)/>.

Oops. Bug in the spec. The example should be as you suggest above.

Jon Ferraiolo
Adobe Systems Incorporated
SVG Spec editor

Received on Thursday, 22 July 1999 12:24:44 UTC