4 ms·

If they're using a front-end tool, you're committing to making additional software--you might as well have the front-end generate the file. What's the gain of u

If they're using a front-end tool, you're committing to making additional software--you might as well have the front-end generate the file. What's the gain of using one file format over another if it's the structured output of your program? > You're right that encoding needs to be solved, but the solution is to just make UTF-8 mandatory and be done with it. There's no real reason to support every encoding under the sun nowadays. I agree--but that's the kind of decision that needs to be made and documented up-front. And you'll still have issues, because users will be creating text files on their home computers, and who knows what their home computer's encoding is set to? It's not guaranteed to be Unicode. You'll either wind up bloating your spider by guessing encodings, or you'll have made the format more strict. > If the user is not technically able to make sure he saves the file in the right format, he can just use a tool. It's not like XML doesn't require tools anyway. If I wait long enough, my point makes itself. > Bloating the file format is a poor solution to that problem. You don't have to love XML to be able to admit that it sometimes is the right solution. By not using it, you're admitting you'll deal with all these problems yourself instead. It may be that you can handle them with less effort than using the solution XML provides, but you'll be making everyone else go to that same effort as well, which isn't the case with XML. At the end of the day, this is the fifth proposal to solve this problem and it's obviously the worst of the lot. The real world will go on using microformats, RDF and Google's AI.

icebraining 14y ago
What's the gain of using one file format over another if it's the structured output of your program? You just need to use the program if you can't save the file as UTF-8; everyone else doesn't need to. Also, even if it was mandatory to use a tool, it's still way better to use a simpler, easy to parse format than the bloated mess that is XML. http://harmful.cat-v.org/software/xml/ http://harmful.cat-v.org/software/xml/ And you'll still have issues, because users will be creating text files on their home computers, and who knows what their home computer's encoding is set to? It's not guaranteed to be Unicode. You'll either wind up bloating your spider by guessing encodings, or you'll have made the format more strict. It should be strict. Supporting multiple encodings is a bad solution in any case. If I wait long enough, my point makes itself. I'm not sure I follow you. Even if this format always required a tool - which it doesn't, only if you can't choose "UTF-8" when saving in your text editor - how would that make XML a better choice? You don't have to love XML to be able to admit that it sometimes is the right solution. There may be cases where XML is the right solution. I don't believe this is one. Even if this format is not right either, there are still less bad solutions. By not using it, you're admitting you'll deal with all these problems yourself instead. Which is often a trade worth being made. It may be that you can handle them with less effort than using the solution XML provides, but you'll be making everyone else go to that same effort as well, which isn't the case with XML. What effort does this solution impose that XML doesn't? At the end of the day, this is the fifth proposal to solve this problem and it's obviously the worst of the lot. The real world will go on using microformats, RDF and Google's AI. Certainly, no disagreements there! I'm a fan of both microformats, since they have the big advantage of not duplicating effort and data, and of RDF - I publish mine as Turtle[1], which by the way happens to not support multiple encodings either, it's all UTF-8, thankfully. [1]: http://en.wikipedia.org/wiki/Turtle_(syntax) http://en.wikipedia.org/wiki/Turtle_(syntax)

icebraining 14y ago

What's the gain of using one file format over another if it's the structured output of your program? You just need to use the program if you can't save the file as UTF-8; everyone else doesn't need to. Also, even if it was mandatory to use a tool, it's still way better to use a simpler, easy to parse format than the bloated mess that is XML. http://harmful.cat-v.org/software/xml/ http://harmful.cat-v.org/software/xml/ And you'll still have issues, because users will be creating text files on their home computers, and who knows what their home computer's encoding is set to? It's not guaranteed to be Unicode. You'll either wind up bloating your spider by guessing encodings, or you'll have made the format more strict. It should be strict. Supporting multiple encodings is a bad solution in any case. If I wait long enough, my point makes itself. I'm not sure I follow you. Even if this format always required a tool - which it doesn't, only if you can't choose "UTF-8" when saving in your text editor - how would that make XML a better choice? You don't have to love XML to be able to admit that it sometimes is the right solution. There may be cases where XML is the right solution. I don't believe this is one. Even if this format is not right either, there are still less bad solutions. By not using it, you're admitting you'll deal with all these problems yourself instead. Which is often a trade worth being made. It may be that you can handle them with less effort than using the solution XML provides, but you'll be making everyone else go to that same effort as well, which isn't the case with XML. What effort does this solution impose that XML doesn't? At the end of the day, this is the fifth proposal to solve this problem and it's obviously the worst of the lot. The real world will go on using microformats, RDF and Google's AI. Certainly, no disagreements there! I'm a fan of both microformats, since they have the big advantage of not duplicating effort and data, and of RDF - I publish mine as Turtle[1], which by the way happens to not support multiple encodings either, it's all UTF-8, thankfully. [1]: http://en.wikipedia.org/wiki/Turtle_(syntax) http://en.wikipedia.org/wiki/Turtle_(syntax)