Show HN: Business.txt - Standard Proposal • Hacker News Board

Re: Show HN: Business.txt - Standard Proposal

#111

Post by icebraining » Tue, Aug 28, 2012, 9:05 AM UTC

fusiongyro wrote: post #106

pbreit wrote: post #105

Earlier quoted context omitted.

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. txt: 1, XML: 0

> 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…

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.

Re: Show HN: Business.txt - Standard Proposal

#112

Post by pbhjpbhj » Tue, Aug 28, 2012, 1:07 PM UTC

fesja wrote: post #61

RKearney wrote: post #55

Earlier quoted context omitted.

But then how will fesja be able to tell everyone "Hey, I created a web standard! /flex" You're right. No research was done. Author just threw information that he thought was important into a text file and called it a day. RFC 5785 says to put the file into the .well-known folder, the author only thought about United States addresses when making this, and as you stated the problem has already been addressed.

I don't know what's the correct word for this, and even if it will arrive somewhere. The only thing I know is that there is a problem local businesses and website providers have. And there isn't an efficient solution yet. I've propose a solution so we can discuss it and see if it makes sense. That's where we are now. About going international, I'm from Spain, so of course I will be the first one interested in having…

How are microformats not an efficient solution?

Looks like you made a worse version of hcard, http://microformats.org/wiki/hcard.

Adding a frontend to keep a hcard updated would be what makes this more accessible for business workers/managers.

I've used this on one site for several (six??) years or so, examples at http://microformats.org/wiki/hcard-examples-in-wild-reviewed.

Re: Show HN: Business.txt - Standard Proposal

#113

Post by fesja » Tue, Aug 28, 2012, 2:08 PM UTC

pbhjpbhj wrote: post #112

fesja wrote: post #61

Earlier quoted context omitted.

I don't know what's the correct word for this, and even if it will arrive somewhere. The only thing I know is that there is a problem local businesses and website providers have. And there isn't an efficient solution yet. I've propose a solution so we can discuss it and see if it makes sense. That's where we are now. About going international, I'm from Spain, so of course I will be the first one interested in having…

How are microformats not an efficient solution? Looks like you made a worse version of hcard, http://microformats.org/wiki/hcard . Adding a frontend to keep a hcard updated would be what makes this more accessible for business workers/managers. I've used this on one site for several (six??) years or so, examples at http://microformats.org/wiki/hcard-examples-in-wild-reviewed .

If i have to make a plugin out of the vCard RFC (http://www.ietf.org/rfc/rfc6350.txt), i kill myself before ;)

Re: Show HN: Business.txt - Standard Proposal

#114

Post by fusiongyro » Tue, Aug 28, 2012, 3:00 PM UTC

icebraining wrote: post #111

fusiongyro wrote: post #106

Earlier quoted context omitted.

> 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…

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, wh…

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.

Re: Show HN: Business.txt - Standard Proposal

#115

Post by icebraining » Tue, Aug 28, 2012, 4:09 PM UTC

fusiongyro wrote: post #114

icebraining wrote: post #111

Earlier quoted context omitted.

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, wh…

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 s…

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/

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)