How does your parser handle malformed entries? How do you handle text encoding? What are the valid attributes, what constitutes valid text?
XML is unsexy, but it's only complex because it addresses these issues up front. A clever one-liner doesn't make these issues go away, it just postpones them to an inopportune time later.
The original post doesn't address these issues, and I'm not sure it is ever designed to. If someone wanted to create a globally accessed, multi-language, all-encoding supported fully validated business information XML-RPC protocol they certainly wouldn't have arrived at "business.txt".
The main problem it was trying to solve is to prevent business owners from having to update their information everywhere it ends up - not to ensure proper encoding (99% of applications would be happy with UTF-8) and formatting. In almost all use cases simply copying what was there and plopping it into a string would be fine.
Which brings me back to my point about XML. A lot of the time, XML produces complexity that simply isn't necessary. Following the 80/20 rule, designing it for your specific use case will be multitudes faster and work fine for your target audience, no need to build an enterprise system and standard global protocol out of the gate.
If the entry is malformed the parser skips it...no harm. Text encoding handled like any other text file. Attribute and content validity issue exists with XML, too.
> If the entry is malformed the parser skips it...no harm.
How is the poor non-technical person who made the file to know there was a problem? Run it through some kind of validator? Or just wait a couple days and see if Google has picked up the file properly? The former is what you get with XML, the latter is what you get with DNS (and which necessitates tools such as DNS Report). If you dislike the complexity of the first option, you must be saying you prefer the second, which is ludicrous.
> Text encoding handled like any other text file.
So not, in other words. Or we can implicitly include HTTP in our non-specification, and now our user has to be sure the server is going to issue the file with the correct encoding header. Which again is not something our poor benighted user is going to have the chops to do.
> Attribute and content validity issue exists with XML, too
I didn't say XML magically makes these problems go away. I said XML forces you to deal with them up front rather than later on.
> txt: 1, XML: 0
You've done nothing but push food around on your plate and dodge responsibility for technical problems you created. If this constitutes "proof" of anything but an inability to see long-term consequences of short-term "let's throw some code at it" thinking, we're all doomed.
How is the poor non-technical person who made the file to know there was a problem? Run it through some kind of validator? Or just wait a couple days and see if Google has picked up the file properly? The former is what you get with XML, the latter is what you get with DNS (and which necessitates tools such as DNS Report). If you dislike the complexity of the first option, you must be saying you prefer the second, which is ludicrous.
Why wouldn't the user run the parser himself, probably using some kind of frontend (web, possibly)?
Going from "the parser skips it" to "you need to wait for Google to index the file" doesn't make sense unless you for some reason assume that Google owns the one single parser in existence and, unlike with all the structured formats they support, they don't offer an online tool for showing how it'll read the data.
So not, in other words. Or we can implicitly include HTTP in our non-specification, and now our user has to be sure the server is going to issue the file with the correct encoding header. Which again is not something our poor benighted user is going to have the chops to do.
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.
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.
Bloating the file format is a poor solution to that problem.
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.
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.
XML is unsexy, but it's only complex because it addresses these issues up front. A clever one-liner doesn't make these issues go away, it just postpones them to an inopportune time later.