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

["Hundiak, Arthur" <ahundiak@ingr.com>]

The size of dom tree is a more convincing argument (to me) than the actual
file size.  

By size of the dom tree I mean all of the thousands of tiny little nodes you
get when you break stuff down to the <data x=1 y=2></data> level.

One trick I have used to keep the dom tree small is to store a path data as
an attribute but to use an xml string for the attributed value.  You load
the xml file and create a dom tree containing elements with path attributes.
Then, as you process the tree and come across a path attribute, you feed it
back the parser and make a new tree just for that path.  You can then
process this tree and (usually) delete it.  It not only saves memory space
but you don't need a custom parser either.

I am not trying to influence the svg spec.  I can take my grammers and
transform them to svg for viewing.  But it just seems that having the option
of putting a data element under the path element would sure make a lot of
people happy. And the DOM size problem could be worked around.

-----Original Message-----
From: Jon Ferraiolo [mailto:jferraio@Adobe.COM]
Sent: Wednesday, March 08, 2000 11:31 AM
To: Elliotte Rusty Harold
Cc: donpark@docuverse.com; xml-dev@xml.org; www-svg@w3.org
Subject: RE: What is wrong with SVG?


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/
***************************************************************************