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

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 13:58 03/03/00 -0800, Don Park wrote:
>Here is an example:
>
><path d="M -9156.6833 4804.3804 l 7.8300 2.4368 2.4277 -0.1274 1.3000 0.1870
>h 0.0069
>  l  0.8736 -1.2764 0.3692 -0.5917 0.0397 -0.0057 0.0221 -0.0328
>0.6615 -0.0927
>  0.0664 0.0141 0.1335 -0.0199 3.8513 0.8465 2.0401 1.2276 0.5585 -0.2380
>  0.0045 0.0011 1.8395 0.4616 0.9720 -0.1560 0.0404 -0.0409 0.3983 -0.0297
>  ... [387 lines similar to above]
>
>Is this proper use of XML?  Why on earth would anyone stuff this
>much data into a single attribute?  Why not use child elements
>instead of M for moveto in a monster attribute?  Why bother with
>short non-intuitive attribute name like 'd' when its size of its
>value can be so big?  How am I supposed to parametize SVG graphics
>if everything is hardwired?
>
>I suspect there are some logical explanations for this, so I would
>like to hear from some of the SVG WG members on this and issues
>raised by others on this thread.  I am looking forward to being
>slammed hard with some compelling arguments.

I am not a member of the SVG-WG so can't speak for them, but I have some
sympathy for their problems, which I had to tackle in designing CML. I
expect the problems to include:
	- bandwidth
	- processing
	- in-memory storage

The format has been devised to reduce the number of characters transmitted.
Personally I don't buy this - I think that a little extra whitespace
wouldn't harm the compression. Nor do you save time in processing. However
*if* the file is read into a *generic* DOM it will easily be overwhelmed by
a large number of nodes. Thus:
	<coord><x>12.3</x><y>23.4</y></coord>, repeated several thousand times 
will be very slow to read into a DOM and eat up the RAM megabytes quite
rapidly. 

For a similar reason I have two formats in CML:
	<atom><float builtin="charge">3.0</float></atom> repeated, say, 100* for
"small" molecules
and a float array of the form:
	<floatArray builtin="charge">3.0 4.0 3.0 ...</floatArray>
for a large molecule (1000+ atoms). Software will probably use SAX for the
latter and build its own non-tree data model internally in a pseudoDOM.

I would prefer something parsable, and I'd also prefer it in content rather
than attributes (because content is more flexible to work with). *If* the
current format is considered the best one, then I think it critical that
the WG urge the implementation of extensions functions for parsing it, so
that we can use XSLT without having to write our own.

	P.


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