Quote:
Originally Posted by Enki
And just one mans simplification: XML is a language for writing other data storage languages, so just because something used XML doesn't mean it is compatible with something else's XML out of he box.
|
That's a better and more precise way of describing it, thanks.
The QT container/codec issue was the first that popped to mind as a common analogy.
Quote:
|
XML does have lots of nice tools though, and more all the time, which allow users to address the compatibility issues with a minimum of extra work. XSLT is a good example in this case, without the XML you would need to write a binary translation engine from scratch---Yuck!
|
Hear, hear. I use a custom XML schema for all of my research data. When I first decided on it five years ago, I was told I was nuts - it was too cumbersome, too verbose, the files were too big, it was too slow to work with...
But now I have a suite of XSLTs that can transform the one file format into visualizations (UML, using GraphViz and the dot format), compute fairly complex metrics, and even formats for consumption by other tools in industry and academia.
Are they lightning fast? Not always. I had to do some serious work to get one of them down to practical speeds. (Initially the transformation for one 20MB file took over 9 hrs on my MBP... I got it down to under 5 min with some algorithmic changes.)
But useful? Flexible? Hell yeah.
Banana, one warning: XSLT is a functional programming language first and foremost, not procedural. It is a little... different. Trying to make it act like a procedural language is *possible*, but it's not simple or recommended. It's better to go with the flow and get into the functional mindset, rather than try and beat it to match procedural experience.