Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Business.txt - Standard Proposal

github.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Show HN: Business.txt - Standard Proposal

#101

Post by wedtm »

egypturnash wrote: post #77
pilif wrote: post #60

Earlier quoted context omitted.

The robot will very likely hit my frontpage anyways, so I'd rather have them look (and not find) for a meta tag there than to produce an additional 404 error which will, depending on the content of said page, waste a considerable amount of bandwidth. Besides, my frontpage is either heavily fragment- or just page-cached anyways - especially for anonymous user - so it can be served directly from RAM for all intents and…

> an additional 404 error which will, depending on the content of said page, waste a considerable amount of bandwidth. Because your 404 should be one of the heaviest pages on your site, full of graphics and surprises. Why not make a full-featured game specifically for your 404s?

thebest404pageever.com

Re: Show HN: Business.txt - Standard Proposal

#102

Post by px1999 »

TillE wrote: post #78
andos wrote: post #51

Earlier quoted context omitted.

Falsehoods programmers believe about addresses [1][2] is long-overdue. “There is a current, established format for international addresses” is probably one of them. [1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... [2] http://infiniteundo.com/post/25326999628/falsehoods-programm...

Line 1, Line 2, Line 3, Country should cover just about all cases. Ask yourself if you really need to break out the specific components of the address. In this case you don't. As long as the user knows the correct local format, it's fine.

The txt file isn't just about the user though, it's to aid in indexing useful information from the site, so having some sort of breakdown into nested administrative divisions is something that makes sense (after all, I don't just say "I'm looking for a steakhouse in the USA" when I'm trying to decide where to have dinner). Of course, administrative divisions introduce their own problems and work against the whole human readable / human writeable nature of what they're trying to achieve.

On the flipside, even Line 1, 2, 3, country isn't sufficient for all addresses. If you have an addressee, additional delivery information (eg a department), need to include a rural route identifier (eg for Canada), or need to store/use bilingual addresses (again for Canada) then you need more than 3 lines. If you want to talk edge cases, having a country code means that places like the Haskell Free Library and Opera House (http://en.wikipedia.org/wiki/Haskell_Free_Library_and_Opera_...) can't be correctly addressed.

Hell, even the Falsehoods programmers believe about time doesn't come close to capturing the intracacies of lunar/lunisolar calendars (eg those with 13 months in a year, or a variable number of months in a year etc).

I guess that my point is that you need to find the balance of utility and complexity. If you need to be able to store every format of everything you wind up with either a hugely complex schema, or a single field that contains everything (and may even not capture everything completely), but that's not useful for anything except end-user display when the user is able to parse (or make a good guess at) the data.

Unfortunately there isn't a single winning approach - so unless you draw an arbitrary line your specification can't encompass every edge case while maintaining simplicity and achieving what it's set out to.

Re: Show HN: Business.txt - Standard Proposal

#103

Post by alttag »

jewel wrote: post #79
quadhome wrote: post #50

Earlier quoted context omitted.

You'd rather a robot hit your frontpage— and by association, your application- than hit your 404 static page? Instead of generating errors from 404s (a lot of noise), try generating errors from the same repeated 404s.

We reduce the noise by only looking at 404s with referrers.

That will cause you to miss some behavior if internal URLs ever change that users bookmarked or remember.

As an example, a TV station site I follow had a /fullepisodes/ basename page which wasn't updating in sync with their show pages, apparently pulling from a different data store. After about six months of declining updates to that page, they eventually re-vamped it with a more-correct data source. I like to think it happened because I and others kept browsing directly to the easily memorable URL

Re: Show HN: Business.txt - Standard Proposal

#104

Post by facorreia »

andos wrote: post #51
facorreia wrote: post #40

The schema is rather US-centric. For instance, many countries don't have "states". They may have other divisions, in the 0..N level range, with other names. It would be better to research and use a current, established format for international addresses.

Falsehoods programmers believe about addresses [1][2] is long-overdue. “There is a current, established format for international addresses” is probably one of them. [1] http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... [2] http://infiniteundo.com/post/25326999628/falsehoods-programm...

Right. What I really meant is, "a format that is not US-centric".

Re: Show HN: Business.txt - Standard Proposal

#105

Post by pbreit »

fusiongyro wrote: post #84
alttab wrote: post #43

Earlier quoted context omitted.

What world do you live in where XML is easier? 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_da…

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.

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

Re: Show HN: Business.txt - Standard Proposal

#106

Post by fusiongyro »

pbreit wrote: post #105
fusiongyro wrote: post #84

Earlier quoted context omitted.

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.

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

Re: Show HN: Business.txt - Standard Proposal

#107

Post by ricardobeat »

pilif wrote: post #60
quadhome wrote: post #50

Earlier quoted context omitted.

You'd rather a robot hit your frontpage— and by association, your application- than hit your 404 static page? Instead of generating errors from 404s (a lot of noise), try generating errors from the same repeated 404s.

The robot will very likely hit my frontpage anyways, so I'd rather have them look (and not find) for a meta tag there than to produce an additional 404 error which will, depending on the content of said page, waste a considerable amount of bandwidth. Besides, my frontpage is either heavily fragment- or just page-cached anyways - especially for anonymous user - so it can be served directly from RAM for all intents and…

Cheaper than a hit to a static text file? It's cached in RAM too.

Re: Show HN: Business.txt - Standard Proposal

#110

Post by icebraining »

egypturnash wrote: post #77
pilif wrote: post #60

Earlier quoted context omitted.

The robot will very likely hit my frontpage anyways, so I'd rather have them look (and not find) for a meta tag there than to produce an additional 404 error which will, depending on the content of said page, waste a considerable amount of bandwidth. Besides, my frontpage is either heavily fragment- or just page-cached anyways - especially for anonymous user - so it can be served directly from RAM for all intents and…

> an additional 404 error which will, depending on the content of said page, waste a considerable amount of bandwidth. Because your 404 should be one of the heaviest pages on your site, full of graphics and surprises. Why not make a full-featured game specifically for your 404s?

Crawlers don't (usually) download graphics, much less from 404 pages. They aren't regular browsers.
Post reply on HN