Re: [xml-dev] Four fine text-based data formats ... liberate yourselffro

[Michael Kay <mike@saxonica.com>]

>
> 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?

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.

But I think the sad thing about this discussion is the suggestion that 
there are applications with no need for mixed content. Surely everyone 
needs mixed content? We have applications that ignore the need for mixed 
content, filing that requirement under "too difficult", and we have 
applications that only handle the parts of the problem that don't 
involve mixed content, leaving the mixed content requirement to be 
tackled at another level. For me, when I first encountered XML, the 
promise was that all applications would be able to handle narrative 
information and factual information equally well and in combination: 
because that's what users need. A standard for geographical information 
that can't cope with rich text is surely a nonsense. If we're walking 
away from that aspiration, I think it's a great shame.

Michael Kay
Saxonica