Show HN: JSON.is
json.is
json.is
Fun fact: XML schema declarations are themselves XML documents, and there exists an XSD describing allowable XSDs. https://www.w3.org/2001/XMLSchema.xsd
Nobody contests XML's capability. It was unpleasant to write and read.
Despite JSON's shortcomings, the developer community found it on the whole more pleasant to work with.
It's the same argument that Lisp users make. The two are more expressive, more capable, more safe. It's also very dense and intimidating.
You can come up with all the justifications you'd like. It won't win the hearts of developers.
> I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
via https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
Double quotes everywhere are more annoying to read than end tags. If we're going to invent nonstandard formats, why not remove the redundant tag name in the XML end tag. Problem solved.
https://github.com/rendaw/luxem
A perhaps lightly more rigorous specification:
https://github.com/Rendaw/luxemj/blob/master/src/main/resour...
It allows optional quotes and comments, plus trailing "," and element type specifications. I think it's easier to read and hand-write, as well as write a parser/generator.
Comments wouldn't be usefull (mostly) for data sent on the wire --and JSON is quite good for that-- but for configuration files, they're indispensable. INI (like git's) is way better of a configuration format than JSON. Easier both to read and to write.
Python provides programmatic access to docstrings, for example, and it has many valid uses.
XML is ugly, but complicated JSON isn't much better IMO. It has an only slightly less human-unfriendly syntax: Why do I have to use double quotes on keys? Why are there no comments? Then come things like schemas, queries, and transformations: XSD, XPath, and XSLT are very powerful tools. Their implementation sucks, but it's arguably better than people coming up with their own half-documented solution whenever they need something XSD/XPath/XSLT provides.
The problem is usages that grow in their need for power over time, with high switching costs. Instead of choosing, they add pressure to XMLify the JSON ecosystem.
JSON's doom seems distant but inevitable, but it will instead be defeated by the rise of yet another format.
Here's the answer: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
Not sure if I agree with it or not, nevertheless that was the reasoning.
(Automatically fetching XSDs e.g. sounds nice in practice, until you realize that it means your server will make HTTP requests to user-supplied URLs, so most parsers come with an option to disable it, which may or may not break documents relying on it.)
It seems that this format, while a clever idea, is going to have a lot of problems in describing more complex json documents, which may have optional arguments, arguments that are mutually-exclusive, etc etc.
For example, in the package.json example alone, there are several properties that can be either a string or an object, but it would be hard to expose that in this system.
But maybe this isn't supposed to be documentation, in which case I'm just confused about the purpose of this.
Edit: If more information about the available properties were available at each level (i.e. from the top-level, here are all the possible props; from the "contributors" prop, here are the different possibilities) and this could be used to document one's own project-specific JSON, this could be very cool. But the best would be if it had a way to integrate with a proper schema validator.
Why would this be any harder to describe complex JSON documents? Optional arguments don't need to be described if they're not in your specific file – not by something like this anyways. That's what the regular documentation is for, and this could easily link to it too.
Mutually exclusive arguments can easily be linked-to, or, rather, if your file contains one of those arguments then the contextual info can link to any other mutually exclusive arguments.
Why couldn't the context info state that valid values include either a string or an object (of some type and that type linked to in the context info)?
I'm confused about your confusion! It seems like this is a really handy way to show documentation specific to a selected portion of a JSON object for a given format.
Is that what it's supposed to be?
Because what I was saying was lacking was any contextual help that tells you what you could add, vs what's already there.
If I were shown http://package.json.is as "contextual help" to help me author my package.json file, I would have no idea that I could add "author" or "contributor" fields. This only gives documentation for the stuff that is already there.
You could add every property to the original document, but that fails if you have mutually-exclusive properties, because the original document would not be valid.
You could try to add every possible property to the top-level comment, but then the top-level comment needs to be practically as long as the original documentation.
Documentation that is incomplete, and doesn't seem to have a reasonable way to make it complete, doesn't seem useful to me -- and in many ways seems worse than not having it, because the incompletion means I would never even realize I was missing useful documentation. I'd have to have the real documentation open on another page anyway, to make sure I'm not missing stuff.
But again, maybe I'm missing the use-case.
> Please check us out on a larger screen. :)
> Email yourself a reminder
WTF? You might not know this, but my phone is equipped with advanced pinch-and-zoom technology you may not have seen before.
Waiting for a good webpack.config.js one :)