|
I disagree.
back to my imaginary file format analogy.
Let's say I come up with a "standard" that's either a txt file, or an rtf, or html, or xml file, or doc file, and I put it in a zip file and change the file name.
This would be a very easy format to convert to (put anything in a zip file and change the name), but would be a pain in the ass to convert from, and would essentially be useless. You'd never know for sure whether or not you were getting the correct semantic data (which might or might not be stored in an xml version, or might be in html meta data, or might also just be in the first few lines of a text file), and your conversion would be riddled with if statements, essentially just being the sum total all of the separate conversion programs that convert from any other file format.
There's no sense in bothering to convert files into ONE file format if it's not actually ONE file format.
Likewise, it's inherently not possible for me to write a good converter that would convert from a file type that potentially stored the same semantic data in multiple places. I'd have no way to programatically know which one was correct, when data was found in more than one spot. A file type with such a nature, as far as I'm concerned, throws away information.
Maybe epub isn't as bad as my example, but as far as I can tell it does "support" dtbook, xhtml, and xml content in varying confusing ways, as well as having the ability to store the same semantic data in multiple places.
so... I'm not just going to choose whatever's easiest to convert to. My priority is to store all the information in the way that's best for getting the information out, not in. If it's difficult to get information in, then that inherently demonstrates the faulty nature of the format I'm trying to convert from, not a fault of the format I'm converting to.
|