- From: Daniel Veillard <Daniel.Veillard@w3.org>
- Date: Tue, 7 Mar 2000 10:23:08 +0100
- To: Tim Bray <tbray@textuality.com>
- Cc: Jon Ferraiolo <jferraio@adobe.com>, "Arnold, Curt" <Curt.Arnold@hyprotech.com>, "'xml-dev@xml.org'" <xml-dev@xml.org>, "'www-svg@w3.org'" <www-svg@w3.org>
On Mon, Mar 06, 2000 at 03:30:10PM -0800, Tim Bray wrote: > At 03:11 PM 3/6/00 -0800, Jon Ferraiolo wrote: > >At 03:30 PM 3/6/00 -0700, you wrote: > >>Jon, Thanks for the reply to xml-dev. Could you address any reasons why: > >> <path d="M 100 100 L 200 200"/> > >>Could not be represented as: > >> <path><d>M 100 100 L 200 200</d></path> > >>at least as an alternative format. > > Actually, the attribute format does have one advantage. XML 1.0 contains > (IMHO) a design error whereby attribute values are "normalized", i.e the > white space is condensed, line breaks are pulled out, and so on. This > would allow you to write > > <path d=" > M > 100 > 100 > L > 200 > 200 > "> > > and still have it show up in the app with just single space characters. > > Sigh. -Tim It also mean it is a bit more expensive CPU wise to handle data in attributes versus data in elements. Especially with a validating parser you have to check wether the attribute is declared CDATA or not for it's processing. This mean at least some kind of Dtd lookup. Of course specialized (or non validating) parser don't have that extra step to do but they still need to do the main normalization work. Daniel -- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe
Received on Tuesday, 7 March 2000 04:24:11 UTC