what a piece of shit...
JSON5 Data Interchange Format
71–80 of 157 posts
Re: JSON5 Data Interchange Format
#72Earlier quoted context omitted.
The XML Schema standard is terrible, and its mistakes and weaknesses were what drove James Clark and Murata Makoto to develop RELAX NG (REgular LAnguage for XML Next Generation). https://en.wikipedia.org/wiki/RELAX_NG RELAX NG has a clearly focused sound mathematical underpinning: regular expressions applied to trees, while XML Schema is an ad-hoc hot mess designed by committee. https://en.wikipedia.org/wiki/XML_sche…
Interesting. I have validation of our internal (overly) complex configuration files on my todo list, and I'll have a look at using that, thanks!
James Clark argues that it's useful to have multiple specialized schema definition languages, each for their own purpose, so putting one reference to one "official" schema in one "official" language inside the document doesn't make sense.
For example, you might want to perform one kind of quick simple input sanity checking validation that ensures the input won't crash your processor, to perform in real time on millions of XML documents you receive every minute.
Then you might also want another more elaborate schema with an anal retentive formal specification, including text syntax checking, data type validation, cross-reference checking, constraints between values, and documentation, for creating and editing the same document in a schema-driven editor.
https://github.com/michmech/xonomy
It's also a bad idea to interpret the URI of a schema as the URL from which you can download the schema definition. That introduce security and privacy and interoperability problems.
Internet Explorer used to try to download the schema definition every time you opened an XML document, which lets whoever controls that web site know you're looking at one of their documents, and what its url is in the referer field. It's like XML's answer to the 1x1 transparent GIF tracking cookie!
Unlike DTDs and XML Schema, RELAX NG doesn't presume that it's the only schema language in the world that you will ever need to use: there are other useful languages like Schematron, which do things that RELEX NG was designed not to do on purpose.
(There's a great Ven diagram comparing XSD, DTD, RELAX NG and Schematron's scope on that page.)
https://www.schematron.com/document/2755.html
>Schematron can be useful in conjunction with many grammar-based structure-validation languages: DTDs, XML Schemas, RELAX, TREX, etc. Indeed, Schematron is part of an ISO standard (DSDL: Document Schema Description Languages) designed to allow multiple, well-focussed XML validation languages to work together. You can even embed a Schematron schema inside an XML Schema element or inside a RELAX NG schema!
James Clark on RELAX NG and xml:id:
https://blog.jclark.com/2009/01/relax-ng-and-xmlid.html
>RELAX NG and xml:id
>One part of the vision underlying RELAX NG is that validation should not be monolithic: it is not necessary or desirable to have one schema language that can handle every possible kind of validation you might want to do; it is better instead to have multiple specialized languages, each of which does one kind validation, really well. Consistent with this vision, RELAX NG provides only grammar-based validation. There's no implicit claim that other kinds of validation aren't useful and important.
>One kind of validation that is clearly useful and important and that can't be done by grammars is checking of cross-references. One possibility is to use Schematron for this. The designers of RELAX NG anticipated that there would be a little schema language specialized to this, which would be created as part of the ISO DSDL effort (as part 6); this wouldn't be a million miles from the kind of thing that XSD provides with xs:key/xs:unique/xs:keyref. Unfortunately this hasn't happened yet.
[...]
Re: JSON5 Data Interchange Format
#73Killer feature: comments. Sure, for APIs comments are bad. However, for configuration things are so much better when you can document or temporarily remove things, without having hacks which pollute the data. Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter.
> Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter.
IMO the real value in trailing commas is that it's easier to produce simple JSON programmatically.
Re: JSON5 Data Interchange Format
#74I like that it has a new name. I've seen too many stupid libraries support their own superset while still calling it JSON (looking at you, Python and .NET ecosystem!)
It's a standard. If we change it, it needs a new name..
However, I am worried that this new standard is harder for languages and ecosystems to support consistently, because it requires a much more involved parser.
Then again, if YAML can do it.. (and that must be a parser created in the depths of hell).
Re: JSON5 Data Interchange Format
#75Earlier quoted context omitted.
But then you can't include single quotes into the string any more. Same problem again. The most practical solution for this problem I saw was in F#. You can use tripple-quoted strings. let a = """The diner is called "John's", but you can't let the string end with a double quote""" https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...
Rust has similar but it scales infinitely. They're called raw strings, "normal string can contain ' " r#" raw string can contain " ' "# r###" if for some reason you need to write "# "### Kinda like heredocs
Most (newer) programming languages have a concept of multi-line string literals.
Re: JSON5 Data Interchange Format
#76"JSON (JavaScript Object Notation) is a lightweight data-interchange format."
So says JSON.org for as long as anyone can remember.
Why is anyone caring about using single or double quotes, or wanting trailing commas? It solves no problems. It seems to me the only answer is it's for manually created JSON. That is, all of this is for people whose only exposure to JSON is doing some config in vscode. It adds nothing else.
Call it JSON-CONFIG and leave well enough alone.
Re: JSON5 Data Interchange Format
#77"JSON (JavaScript Object Notation) is a lightweight data-interchange format." So says JSON.org for as long as anyone can remember. Why is anyone caring about using single or double quotes, or wanting trailing commas? It solves no problems. It seems to me the only answer is it's for manually created JSON. That is, all of this is for people whose only exposure to JSON is doing some config in vscode. It adds nothing els…
Keep going, next sentence from JSON.org: "It is easy for humans to read and write. It is easy for machines to parse and generate. "
Non-quoted keys is easier to read and write by humans, trailing commas are easier for a machine to write, single quotes can make it easier for a human to read or write. Comments help humans read and write.
I remember when it was javascript object notation and that stuff was allowed because thats what javascript allows and felt simple and effective for both human and machine, then it became strict json, what a step backwards.
Re: JSON5 Data Interchange Format
#78Re: JSON5 Data Interchange Format
#79Earlier quoted context omitted.
You'd use escapes: "You can use both \" and ' to delimit a string"
That was their point, you inevitably have to escape one or the other, so just pick one
My only disagreement is that you imply that this is no better than plain old JSON – I think it's positively _worse_. It makes it difficult to remember which of the two quote marks to escape, without checking the beginning of the string to see what quote marks were there (and this difficulty exists not only for humans but for machines, which introduces more complexity in parsers).
The benefit of JSON is that it's simple, opinionated, and pretty. Putting bells and whistles on it ruins the very ethos of JSON. If you want JSON++, use XML or Jsonnet or whatever.
Re: JSON5 Data Interchange Format
#80Earlier quoted context omitted.
The XML Schema standard is terrible, and its mistakes and weaknesses were what drove James Clark and Murata Makoto to develop RELAX NG (REgular LAnguage for XML Next Generation). https://en.wikipedia.org/wiki/RELAX_NG RELAX NG has a clearly focused sound mathematical underpinning: regular expressions applied to trees, while XML Schema is an ad-hoc hot mess designed by committee. https://en.wikipedia.org/wiki/XML_sche…
Interesting. I have validation of our internal (overly) complex configuration files on my todo list, and I'll have a look at using that, thanks!
Another nice thing about RELAX NG is that not only does it have an XML format, but it also has a nice clean, much simpler to read and write, "compact syntax", which is equivalent to the XML format, and can be translated back and forth without losing any information.
It's not all goofy and arbitrary and complex line noise like XML DTDs, and it's not all verbose and clumsy namespaced XML tags and attributes like XML Scheme documents.
It even supports inheritance, and grammar as well as element level annotations (useful for schema and meta processing tools and editors).
RELAX NG's Compact Syntax:
https://www.xml.com/pub/a/2002/06/19/rng-compact.html
RELAX NG Compact Syntax: Committee Specification 21 November 2002:
https://www.oasis-open.org/committees/relax-ng/compact-20021...
RELAX NG Compact Syntax Tutorial: