Im happy to say that my own JSON parser (https://github.com/ryanbalsdon/cerial) passed a lot more of these tests than I expected! It isn’t a general parser though (requires a pre-defined schema) so is probably cheating.
Parsing JSON is a Minefield
151–160 of 257 posts
Re: Parsing JSON is a Minefield
#152Earlier quoted context omitted.
>> I don't hear people wanting a human readable text representation of their audio, video or images. This is, in fact, a huge concern for people who think about accessibility.
Indeed! Facebook spends a ridiculous amount of resources creating text summaries of what's in user-provided images. Check out the alt="" tags next time you're scrolling through your feed. Every single image has one.
I just checked what you're talking about. Creepiness aside, that's kinda awesome.
Re: Parsing JSON is a Minefield
#153This is interesting and important in one way: anything poorly specified will eventually cause a problem for someone, somewhere. That being said, my first response was to complete the title, ". . . yet it remains useful and nearly trouble-free in practice." There's a lot of, "You know what I mean!" in the JSON definition, but in most cases, we really do know what Crockford means.
> anything poorly specified I thought JSON was specified quite clearly. http://json.org/ There are no limits of the loopy things (the number of consecutive digits in numbers), but I don't consider that a weakness of the standard. Most of the tests that I see do pass completely invalid JSON. http://seriot.ch/json/pruned_results.png
So, 9223372036854775807 is a valid number per the json.org spec, but good luck getting a typical JSON decoder to process that number. A couple I tried returned it as 9.2233720368548e+18, which is not the same number.
Re: Parsing JSON is a Minefield
#154Try RSS.
Having built a system years ago, to try an parse tens of thousands of feeds, there's a huge amount of 'fuzzy logic' required to put it all in order.
Despite the spec.
Re: Parsing JSON is a Minefield
#155Earlier quoted context omitted.
I like TeX for producing documents. But I'd take XML over TeX if I had to parse the markup myself, outside of the TeX toolchain. Any nontrivial TeX document is built out of a pile of macros, so you need to implement a TeX-compatible macro expander to parse it. And at least with XML there are solid libraries, while the state of TeX-parsing libraries outside of TeX itself is pretty poor. I think Haskell is the only lan…
It doesn't need to be Tex-compatible. My point was just that the syntax is lighter weight and might be preferable for some applications.
RTF is essentially the same syntax, sans the option to define your own markup. Only barely human readable when produced by a word processor, though, but generated TeX is awful as well.
Re: Parsing JSON is a Minefield
#156Earlier quoted context omitted.
You use p-lists instead so that {"foo":"bar"} becomes ( :foo "bar")
Won't you inherit all the encoding trouble this article goes on about? As well as the problems with integer precision? And get a bunch of new ones with special characters in keys... I'm sure you _could_ specify a nice sexpr format. I'm not sure the specification would be simple though. And just saying "use sexprs" leaves you with all the problems you have when you say "use json".
To put it another way, the biggest problems with JSON aren't with the representation but with the semantics. S-expressions have no inherent semantics beyond those provided by the structure. Take this S-expression:
((:foo ("bar" 1))
{ "foo": [ "bar", 1 ] }
ETA: I just realized I pretty much repeated what an earlier comment said re: semantics. Sorry for the redundancy.
Re: Parsing JSON is a Minefield
#157While this is true of JSON, it's also true of any other non-trivial serialization and/or encoding format. The main lessons to learn here are that: 1) implementation matters 2) "simple" specs never really are It's definitely important to have documents like this one that explore the edge cases and the differences between implementations, but you can replace "JSON" in the introductory paragraph with any other serializa…
No, this is not true of many reasonable formats. You don't have to make an obtusely nontrivial format to encode the data JSON does.
I notice that in a topic where it'd be so easy and even necessary to rattle off a few names/examples, you've chosen not to do it.
Re: Parsing JSON is a Minefield
#158This is interesting and important in one way: anything poorly specified will eventually cause a problem for someone, somewhere. That being said, my first response was to complete the title, ". . . yet it remains useful and nearly trouble-free in practice." There's a lot of, "You know what I mean!" in the JSON definition, but in most cases, we really do know what Crockford means.
[deleted]
Re: Parsing JSON is a Minefield
#159Earlier quoted context omitted.
>> I don't hear people wanting a human readable text representation of their audio, video or images. This is, in fact, a huge concern for people who think about accessibility.
Ok but what I'm talking about is a little more specific. Talking about "human readability" of JSON and XML is a little bit like talking about human readability of JPEG or MP3. Chasing after it creates a lot of problems. Formats like JSON and XML often carry lots of textual information so it's tempting to want them to be like "just like text but with some extra stuff" but that creates its own problems. So it would be…
What you're proposing sounds like cbor and/or messagepack (which are virtually identical in their design), or argdata[1].
I agree it's a pretty solid spot in the design space.
Re: Parsing JSON is a Minefield
#160Earlier quoted context omitted.
No, this is not true of many reasonable formats. You don't have to make an obtusely nontrivial format to encode the data JSON does.
Most of the things they test are true of any text-based format, and many of them are true of any serialisation format. E.g. 100000 opening brackets. You could do the same in XML for example and I expect many parsers would fail.
Maybe the difference is that nobody ever thought that XML was easy to parse.