OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Four fine text-based data formats ... liberate yourselffrom one (silo) data format

On Mon, Mar 25, 2013 at 5:13 PM, Michael Kay <mike@saxonica.com> wrote:

That doesn't surprise me because SVG also uses the same interminable point series attributes that KML does (I suspect KML borrowed the idea from SVG).  It's not quite as bad in SVG because there's usually much more to the SVG file than the point sets, but in KML files, that's in my experience generally the thing you really care about, and you almost wish it were in a fixed-width binary format instead.

So yeah, I can imagine a KML->SVG transform would be fairly painless (not that I've ever tried that myself), but I don't think that really rescues KML as a format.  I'll also say that I can't imagine it would be hard to generate SVG from bog-standard KML data coded in a binary or CSV-like format.  Again without the need for e.g. mixed content, attributes, etc, XML really just gets in the way.

This seems confused. KML and SVG both use microsyntax to represent arrays of coordinates. They don't use XML markup. So processing the coordinates involves almost exactly the same logic (a couple of calls on tokenize()) that you would have to use with a CSV-like format. It's true XML isn't helping much here, but in what sense does XML get in the way?

You say that seems confused.  I say all you said in response is a complete reiteration of my entire point.  If the part you care about is not in XML, and yet you have to deal with XML in order to get to the part you care about, is that not the very definition of "XML getting in the way"?

If KML were represented in JSON you would be able to represent the coordinates natively as arrays of numbers, saving you a couple of calls on tokenize(). But in my experience the overall complexity of the processing task wouldn't be reduced in the slightest - unless you are using an API like the DOM, in which case you have only yourself to blame.

Notice you brought up JSON in context of KML.  Not me.  This seems like a straw man.

Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS