Intel AVX-512 A Big Win For... JSON Parsing Performance

[coder]

XML is a markup language!

You're reading more into the ML in its name than I think you should. That largely comes from its HTML & SGML heritage. The designers felt a need to stick with angle brackets and attributes, as well as a similar name.

At any point you intersperse and embed tags within tags in a run of text.

Indeed, you can use it as a markup language. Its support for mixed content (i.e. elements containing both text + elements) is quite powerful.

Comments by convention are easy in JSON, just add
"//": "The value of the // key is an uninterpreted comment, like this"
to any object.

Of course, either the app or the parser needs to be written to ignore them.

For an authoring format, such a method is deficient because you can't use them to disable a chunk of JSON, in the same way as one might comment out a chunk of C code.

[ssokolow]

Of course, either the app or the parser needs to be written to ignore them.

True but, given the way people usually parse JSON, that's a common automatic side-effect of keeping it forward-compatible with fields added in future versions.

Heck, every JSON parser I've used has had "ignore unexpected fields" as the default mode of operation.

[coder]

True but, given the way people usually parse JSON, that's a common automatic side-effect of keeping it forward-compatible with fields added in future versions.

I understand, which is why I worded it the way I did. However, it does impact one's ability to do general transformations, reductions, filtering, and other sorts of operations. For instance, using generic tools analogous to how one might use XQuery or XSLT on a XML document.

It's not hard to think up scenarios where comments could get in the way.

Another thought I had about this approach to comments is that you'd potentially be rather limited in where you could put one. For instance, you couldn't necessarily drop one in the middle of an array. While it's better than nothing, it's a really poor substitute for a generic, block comment mechanism. It seems to me they really erred by not including Javascript's comment syntax.

[ssokolow]

I understand, which is why I worded it the way I did. However, it does impact one's ability to do general transformations, reductions, filtering, and other sorts of operations. For instance, using generic tools analogous to how one might use XQuery or XSLT on a XML document.

It's not hard to think up scenarios where comments could get in the way.

Another thought I had about this approach to comments is that you'd potentially be rather limited in where you could put one. For instance, you couldn't necessarily drop one in the middle of an array. While it's better than nothing, it's a really poor substitute for a generic, block comment mechanism. It seems to me they really erred by not including Javascript's comment syntax.

No argument there. As I said, that's one of the reasons I use TOML for stuff meant to be hand-edited by humans.

[JustRob]

Just use RDF 😀 🪄🛎️

Versitile - https://en.wikipedia.org/wiki/Data_e..._data_exchange
Featurefull - https://www.dataversity.net/introduction-to-rdf-vs-xml/
Speedy - http://sansa-stack.net/sansa-parser-...ance-improved/

[ssokolow]

Just use RDF 😀 🪄🛎️

Versitile - https://en.wikipedia.org/wiki/Data_e..._data_exchange
Featurefull - https://www.dataversity.net/introduction-to-rdf-vs-xml/
Speedy - http://sansa-stack.net/sansa-parser-...ance-improved/

Boy. There's a name I haven't heard in a decade.

[Insert semantic web joke here]

[coder]

Just use RDF 😀 🪄🛎️

Versitile - https://en.wikipedia.org/wiki/Data_e..._data_exchange
Featurefull - https://www.dataversity.net/introduction-to-rdf-vs-xml/
Speedy - http://sansa-stack.net/sansa-parser-...ance-improved/

I'd forgotten that RDF even had a non-XML serialization.

I think it's a mistake to view it as a generic substitute for XML or JSON, though. In some cases, it's a better fit.

Boy. There's a name I haven't heard in a decade.

[Insert semantic web joke here]

These sorts of standards tend to get a lot of publicity and hype in the early days, but settle into a few niches where they're a good fit.

The grand vision of the semantic web was indeed too utopian ever to come to fruition.

[ssokolow]

These sorts of standards tend to get a lot of publicity and hype in the early days, but settle into a few niches where they're a good fit.

The grand vision of the semantic web was indeed too utopian ever to come to fruition.

*chuckle*

Reify all the things!

[uid313]

Having written an actual JSON parser/AST in Scala I can say this this violates the JSON Spec which disallows any form of comments and the creator of JSON stanard (Douglas Crockford) was very deliberate about this because he wanted to prevent companies creating proprietary extensions in the form of comments which is what happened with Microsoft with HTML in their rendering engines (I guess its not surprising that the parser you linked is from Microsoft's .net).

No JSON parser out there should be able to handle comments and if you need comments then JSON is the wrong format (typically this is with configuration files in which case you should use yaml/hconof/toml etc etc)

YAML is quite terrible, the specification is huge and the result is many implementations that are non-compliant. I've never heard of hconfof, is that a typo of hconfig? I've never heard about that either. TOML is alright, I like it.

[mdedetrich]

YAML is quite terrible, the specification is huge and the result is many implementations that are non-compliant. I've never heard of hconfof, is that a typo of hconfig? I've never heard about that either. TOML is alright, I like it.

Its used in Scala although its also been ported to rust https://github.com/lightbend/config