xml-dev - RE: What is wrong with SVG?

[Jon Ferraiolo <jferraio@Adobe.COM>]

Elliote,
This is exactly the approach used by PGML, which was a joint submission
from Adobe, IBM, Sun and Netscape in April 1998. I am well familiar with
the syntax you show below as I was one of the principal authors of PGML. 

The SVG working group instead chose a path syntax more like VML, which was
a joint submission from Microsoft, Visio, Macromedia, HP and Autodesk in
May 1998. (VML ships with IE5.) The main reasons for adopting a path syntax
more like VML was file size and DOM size issues. The feedback we got from
web content creators that file size was a critical issue, and if file sizes
were too larger, SVG was a non-starter.

There has been lots of email disagreeing with the tradeoffs and decisions
made with SVG's path syntax. There were conflicting goals in making
decisions. The path data syntax in the current spec gives maximum
importance to file size compression as we decided that goal had very high
priority.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

At 08:16 AM 3/8/00 -0500, Elliotte Rusty Harold wrote:
>At 7:02 PM -0800 3/7/00, Jon Ferraiolo wrote:
>>
>>
>>I am not sure whether there was a whole ton of deep thought on this issue.
>>As I remember, the "wisdom" was based on theories that:
>>
>>1) By having character data only in <desc>, <title> and <text>, then really
>>dumb screen readers for the visually impaired which only vocalized
>>character data would tend to provide a more suitable aural rendering of an
>>SVG document, versus one attempted to vocalize all of the moveto, lineto,
>>curveto and coordinate data in a 'path' element
>>
>>2) Similarly, web search engines which attempt to index generic XML files
>>would be able to index SVG files more efficiently. Again, they wouldn't
>>have to learn to skip over character data within SVG's 'path' element.
>>
>>3) It just seemed cleaner to have the consistent rule that the only aspects
>>of SVG that are represented as character data are things that actually make
>>sense to read (when looking at source code) or vocalize.
>
>These goals could all be met by the following syntax while still 
>making things more easily manipulable by XSLT:
>
><moveto x="3" y="7"/>
><lineto x="23" y="54"/>
><curveto x="34" y="-76/>
>
>and so on. The idea is to use empty elements, each of which has 
>contains exactly one coordinate. What's wrong with that?
>
>
>+-----------------------+------------------------+-------------------+
>| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
>+-----------------------+------------------------+-------------------+
>|                  The XML Bible (IDG Books, 1999)                   |
>|              http://metalab.unc.edu/xml/books/bible/               |
>|   http://www.amazon.com/exec/obidos/ISBN=0764532367/cafeaulaitA/   |
>+----------------------------------+---------------------------------+
>|  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ |
>|  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
>+----------------------------------+---------------------------------+
> 

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************