Wouldn't it be easier if this were XML instead of plain text? I assume the goal is that software can easily interpret the data.
Have you ever written a SAX parser? XML parsing is not "easier". Screw the libraries that "do it for you". You still have to understand the tiered data structure, attributes vs content, namespaces,.... the list goes on. Understanding the schema and all that jazz is WAY more difficult than key: value.
edit: Parsing is just as easy. Here is a one-liner in ruby:
business_data = IO.readlines("business.txt").each_with_object({}) {|l, memo| k, v = l.split(':'); memo[k.strip] = v.strip }
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.
txt: 1, XML: 0
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.
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.
> 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.
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/
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.
Also, we are following the same pattern as the robots.txt file.
I'm not so sure about the proposal itself, though. For local, small businesses, how much can we assume about technical ability? If they have to pay the people who did their website to keep it up to date, how can we be sure they'll use it?
If you want to have a feed of some kind that is machine-readable then you need to have a spec that is unambiguous. Using JSON or XML helps. Having a clear understanding of what could be in each field, including currencies, timezones, etc, is required.