Hacker News new | past | comments | ask | show | jobs | submit login

If that was the case we might run into naming collisions if there are multiple cities with the same street names. It would be best if we namespace it to the city as well. So we would have something like { "street": "Church Street", "length": "5", "city": "Church City" } all of course packaged in JSON.



Well-structured data like this is better encapsulated in XML:

    <?xml version="1.0" encoding="UTF-8"?>
        <address street="Church Street">
    	<specifiers>
    	    <key length=""/>
        	<value type="uint32" scale="nanolightseconds">5</value>
    		<city>
        	    <![CDATA[ 
            		<?xml version="1.0" encoding="ISO-8859-15"?>
                    <name>Church City</name> 
    	        ]]>
    	    </city>
    	</specifiers>
    </address>
Isn't that much more legible and understandable?

(I hate XML. So much. This shouldn't be a valid document in any language.)



Just think, there were even multiple versions of JSONx so someone somewhere had to be using it.


It's part of a bigger product (WebSphere), so hopefully it's just being dragged along and not still under development.


While I get your point, the XML document includes so much more information than the JSON example. Encoding, version, data types, 'scale', response length, etc.

Please try not to make any false equivalences :)


That's a great idea and will help making addresses more solid. I would suggest we also add some more levels like the country the city is in?


Wonderful idea, and we could even go so far as standardizing how we write it so that we don't need to worry about putting it into JSON and makes it more memorable for humans. Something like:

Length Street

City

Country


To the extent that a single address might be home to more than one person, shouldn't we pre-pend the name of the specified person to the address?


This is getting too complicated.

We need some sort of code attached to each address that can represent an area, so addresses can be organized quickly.

I vote for a 5 digit code, at least in the U.S.


that might be insufficient for densely populated areas, perhaps an additional optional 4 digits?


I like it, but how about we add 2 more digits that don't get printed in human readable format on the mail but are used in barcodes to sort/deliver it?


Arguably, if it is just for sorting/delivery we could simply use the last two digits of the "length" portion of the address. That would enable any delivery service to sort the mail within the city block and still have a human readable equivalent in case the barcode becomes unreadable.


I should let this lie as an explained joke is never funny, but I just can't.

USPS - Delivery Point: (1) A single mailbox or other place to which mail is delivered. A street address does not necessarily represent a single delivery point because a street address such as one for an apartment building may have several delivery points. (2) A specific set of digits between 00 and 99 assigned to every address that is combined with the ZIP+4 code to provide a unique identifier for every delivery address. The DP is encoded within the POSTNET or Intelligent Mail barcode.

https://about.usps.com/publications/pub32/pub32_terms.htm


Interesting, the last/only time I had to write code to determine delivery points was very early in my career (IBM mainframe COBOL) when postnet barcodes were a new thing and it was always just the last two digits of the street address. I see in the current CASS technical guide that a record type H may have multiple delivery point. Learn something new every day. Thanks.

Edit. As an aside, I think current Microsoft word still calculates it that way when you "bookmark" and address and insert a barcode field. At least it doesn't seem to be sending a query out to the USPS.


Needs more UUIDs so we can get Microsoft on board.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: