[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What is wrong with SVG?
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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|