Live data from Hacker News

ECMA-404: The JSON Data Interchange Format [pdf]

ecma-international.org

141–150 of 199 posts

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#141

"So for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E"" eww, UTF-16 surrogate pairs. Die, die, die, you scourge. (Yes, I've been working with the win32 api lately, which was designed for UCS2/UTF-16). when has 16 bit anything been a good idea, really. TCP port ranges, looking at you too.

Char can be anything not " or \.

You don't have to escape unicode. If you want to just use Unicode and encode as UTF-8 then go nuts.

This is valid JSON:

{ "äöü": "大家好", "clef": "𝄞" }

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#142
post #84

Earlier quoted context omitted.

> Developing nations have a tendency to not use the latest and greatest. Attention developing nations: Chromium and Firefox are completely foss. No excuse, unless you don't have an internet connection. In which case, what do you need a web browser for?

I'm not sure about this but a lot of software might have been written specifically for IE6 and IE6 only, which might not translate well to Chrome/Firefox, and could cost businesses a lot of money, more money than they deem its worth. There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money. This is based on my experience at UPS which used a single machine using IE6 and some form…

Don't they have another browser around for dealing with the rest of the world though? It's not like many modern sites are going to render correctly on IE6 these days...

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#143

Hilarious! ECMA-404. My neighbor's address is 404 West Whatever Street and I can't look at their mailbox without wondering if mail is correctly delivered there...

HAHAHAHA! I was scanning the comments hoping that I'd be the first to drop the 404 joke :D

I swear the moment I glanced at the title I thought it was an error message that someone accidentally posted.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#144

Earlier quoted context omitted.

"Pro-evil"? Wow. Is it so hard for people to realise the problem is the potential interpretation of "evil" is very open ended?

I suspect that quite a few people wanted to use it for projects that had a high likelihood of being considered "evil" by some people, so while the licensing restriction is ridiculous, I wonder if it didn't actually serve its intended purpose? (I'm thinking DoD/intel stuff primarily).

As Richelieu said "Give me six lines written by the most honourable of men, and I will find an excuse in them to hang him."

I pay US taxes and the US government kills people around the world. They also subsidise farmers which puts others around the world at a disadvantage contributing to poorer economic circumstances for them. The US incarcerates a large number of people. If the project benefited me or anyone else paying US taxes, then hasn't it benefited the US government, and hence evil?

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#145

Earlier quoted context omitted.

I'm not sure about this but a lot of software might have been written specifically for IE6 and IE6 only, which might not translate well to Chrome/Firefox, and could cost businesses a lot of money, more money than they deem its worth. There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money. This is based on my experience at UPS which used a single machine using IE6 and some form…

Don't they have another browser around for dealing with the rest of the world though? It's not like many modern sites are going to render correctly on IE6 these days...

But all their apps work with IE6, and who cares about people trying to view Facebook while working?

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#146

JSON is a great way to make your data accessible to deep packet scanning systems. Define all your protocols with JSON!

You may as well make this argument against human speech. We need secure transport, not gibberish protocols.

Not really even a close metaphor, since human speech isn't a internet standard I could build devices against and sell to customers as compliant.

Considering that DPI devices are already sold to parse json-desribed protocols dynamically, I think you are a bit uninformed about my statement. It is not hypothetical.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#147
post #109

Earlier quoted context omitted.

because that is what json is for

no, that's not what json for. JSON is for exchange data between machines. We already have data interchange formats for humans, we call those 'languages'.

json.org:

> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#148

Several comments mention the "Software shall be used for Good, not Evil" licensing issue in the JSON code from json.org. The original json.js file from json.org had this copyright and license: Copyright (c) 2005 JSON.org Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, includi…

I actually enjoyed going to my boss at TIM Group (financial services software, in the City of London) and asking him whether he was comfortable asserting in our open-source audit that we did Good rather than Evil. He thought for a moment - and knowing him, he really did think about it - and then opined that he was, indeed, comfortable that we were doing Good. We proceeded to use JSON happily for years.

That is the best Good vs. Evil story of all!

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#149
post #40

Earlier quoted context omitted.

This sucks, because it limits the usability of JSON. It should interfere with its being a serialization and interchange format, but for configuration files anything without comments is useless.

https://plus.google.com/118095276221607585885/posts/RK8qyGVa...

That's the syntax equivalent of removing guardrails from a dangerous mountain pass to scare drivers into slowing down.

This is probably going to sound like asking someone to catch sunlight in a teacup, but wouldn't it have been more productive to stress the importance of syntax adherence and consistency rather than remove it altogether? There's really nothing stopping someone from abusing the rest of JSON for silly things so leaving comments out seems a bit redundant.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#150
post #93

Earlier quoted context omitted.

That's an ugly workaround, not a solution. It helps breed half-baked "solutions" like the "pipe through jsmin" Crockford himself suggests. Ultimately, it makes JSON unsuitable for configuration files (there are other reasons for that, to be fair, like over-verboseness)

Not necessarily. If you're naming your keys nicely, and using an easily-understandable structure, for simple config files, you shouldn't really need comments.

"simple config files" implies an optimist. Good for you, sir.
Post reply on HN