
Show HN: JSON.is - zackbloom
http://json.is
======
brilee
There's this structured data format called XML, and typically you put a XML
schema definition at the top (example: <xs:schema
xmlns:xs="[http://maven.apache.org/xsd/settings-1.0.0.xsd">](http://maven.apache.org/xsd/settings-1.0.0.xsd">)
for a Maven config file). XML code editors then fetch the XML schema
declaration, which contains information like what fields are expected, whether
those fields are repeatable, whether they are required, and so on. Java
library using XML as configuration will typically have published an XSD.

Fun fact: XML schema declarations are themselves XML documents, and there
exists an XSD describing allowable XSDs.
[https://www.w3.org/2001/XMLSchema.xsd](https://www.w3.org/2001/XMLSchema.xsd)

~~~
throwaway284534
I'm confident that everyone knows about XML and that you're a worse troll than
I am.

Nobody contests XML's capability. It was unpleasant to write and read.

~~~
PeCaN
It's a troll post, but the point stands: JSON is reinventing XML.

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.

~~~
hannob
JSON has huge advantages from a security perspective. The feature-richness of
XML is also a richness of sources of security vulnerabilities.

~~~
creshal
Is it even possible to make a 100% standards conforming parser that is _not_
vulnerable to at least DoS attacks?

(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.)

------
SamBam
Is [http://package.json.is/](http://package.json.is/) really better
documentation for what package.json should look like than than regular-ol'
documentation,
[https://docs.npmjs.com/files/package.json](https://docs.npmjs.com/files/package.json)?

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.

~~~
aeorgnoieang
Yes, because it _could_ be available while looking at your actual config file
(JSON document), and showing you info specific to the element you're looking
at, instead of on a separate page and requiring searching for a relevant
element.

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.

~~~
SamBam
OP described the tool as this: "It's an editor for those JSON file formats
which shows contextual help as you edit the files."

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](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.

------
paulddraper
> Since package.json.is is primarily a code editor, it’s not really well-
> suited for small screens.

> 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.

------
jmhnilbog
I feel like an idiot, but I can't tell what this is and the "About" page isn't
helping me.

~~~
zackbloom
It's an editor for those JSON file formats which shows contextual help as you
edit the files, similar to an IDE. It works by parsing the javascript and
figuring out where your cursor is relative to the syntax of that particular
format.

~~~
jmhnilbog
I'm not seeing any of that.

~~~
Twirrim
Likewise. The landing page gave me no clue. I just now went back and clicked
on one of those documents, assuming that I'd get some kind of documentation
about the format. Turns out it opened a live document _editor_. I certainly
wouldn't have predicted that from the line "Open-source documentation for
common JSON formats."

------
killercup
Nice, but too bad this is not in JSON Schema (it's a custom bunch of html
strings in functions). I would love a more complete JSON Schema for
package.json (with custom stuff like browserify or babel config) as VSCode is
able to autocomplete JSON files from that.

~~~
alexatkeplar
Exactly - why invent some artisanal Turing-complete thing involving regular
expressions and tied to a single proglang when you could achieve the same in a
fully declarative, language-agnostic fashion by adding the "description" field
into JSON Schemas for the same source documents?

------
leppr
Nice presentation, and it would be even better if it could be integrated as a
plugin for text editors (vim/emacs/...).

Waiting for a good webpack.config.js one :)

~~~
Bromlife
Webpack config files are not JSON. They are full JavaScript.

~~~
leppr
I haven't used webpack enough to be certain but AFAIK, like grunt, the config
part is basically just JSON. Sure you can build your object dynamically, but
it isn't something like gulp where you use functions to configure your
project. In the end you're just exporting one big JSON-serializable object.

------
voiper1
That's very nice document-panel on the side! If we could get that in sublime
or vscode, that would be pretty cool!

------
erichurkman
Breaks for me using Safari: TypeError: null is not an object (evaluating
'style.overflow') — works on Chrome.

------
fizzbatter
This is cool! I would have loved something like this for Yaml recently as i
learned Rust's Cargo.yaml

~~~
steveklabnik
Cargo uses TOML, not YAML. (But yeah, this is really cool, and that would be
really cool!)

~~~
fizzbatter
Ah yes, forgot about that. You are correct

------
sotojuan
Would be helpful to add JSON API.

------
andyfleming
Is install.json something new or is it used by an existing platform/toolset?

~~~
zackbloom
It's used to build Eager Apps (and can be used by anything which needs to
install a library in a non-technical-person friendly way):
[https://eager.io/developer/docs/install-
json](https://eager.io/developer/docs/install-json)

~~~
andyfleming
Oh, nice! I sent you an invite on LinkedIn. Shoot me a message and let's
connect!

------
caub
I thought it would introspect each dependency too

~~~
zackbloom
That's a good idea! You can find the repo here:
[https://github.com/eagerio/json.is](https://github.com/eagerio/json.is), you
should open an issue.

------
dimgl
That contrast is abysmal. Please fix the contrast on the code samples.

~~~
zackbloom
The buttons aren't actually meant to be read. If you click them, you get to
the actual code page which has a much better contrast ratio:
[http://install.json.is/](http://install.json.is/)

