Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Four fine text-based data formats ... liberate yourselffro
 > > 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 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|
|||||||||
