Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Schema bundling formalised

json-schema.org

Post reply on HN
Print view View original

161–170 of 188 posts

Re: JSON Schema bundling formalised

#161

Post by matja »

HelloNurse wrote: post #145
matja wrote: post #73

Earlier quoted context omitted.

If every JSON library actively chooses not to implement the JSON spec, that sounds like an issue with JSON to me.

More precisely, an issue with different literal types instead of one like in XML. In XML, every attribute or text fragment is a string, to be POSSIBLY parsed as a string, integer, date etc. according to what applications choose to do (usually according to an explicit schema). In JSON, YAML, etc. there are at least integers, strings and floating point numbers, introducing arbitrary representation choices (1, 1.0, "1",…

Separate types is fine, but JSON doesn't specify a minimum range or precision of the number type that a implementation must have, so the number type is unreliable (and string has to be used instead). To handle any number, a JSON library needs to use an arbitrary-precision number type, which no common one does because of the huge performance hit.

So, no better than XML really :D

Re: JSON Schema bundling formalised

#162

Post by oaiey »

diroussel wrote: post #147
radomir_cernoch wrote: post #131

Earlier quoted context omitted.

In can't agree more. In Java, there's the JAXB ”parser“ which translates an XML schema into (mostly) straightforward classes. Correct initial setup is the only hard part.

The key difference is that there are no options when you parse json. You just parse it and get some lists and maps back. In XML you have to decide if you want DTD or schema enabled (which could provide default values, and could be a security risk) and where abs how you resolve the DTDs from etc. Do you resolve references? And many option options. So JSON benefits not just from a simpler structure, but also from less…

You do not pull schemas dynamically. Schemalocation beyond editors is a pure theory thing. It is not default, it cannot be fast. Any serious developer has the schemas as files in their code when checking the data for compliance.

Basically, in a static typed language you decide for schema checking or not - like for Json -, serializing in structures or access in an API - like for Json.

It is just that JavaScript maps json directly in their dynamic object, array and native types. For xml that is an mismatch. For static languages both are an mismatch.

Re: JSON Schema bundling formalised

#163

Post by oaiey »

no_wizard wrote: post #121
easrng wrote: post #83

Earlier quoted context omitted.

It's easy in JS too, just use a DOMParser

That is not a JavaScript API, that’s a DOM only API, meaning it’s not reproduced in the language spec. This is important because it won’t work in Node, for example, without a 3rd party library or someone implementing it in Node core. JSON however is supported in the language spec

And DOM API is an example of bad API design. Compare that to a modern XML API (like .NET System.Xml.XDocument) and you never want to see Dom again

Re: JSON Schema bundling formalised

#164

Post by xg15 »

akie wrote: post #3

I might be exceptionally dense, but it's hard for me to see practical applications for something like this. In the end, if you implement this in your application, you will have a mechanism to say "this input document is invalid". AND THEN WHAT? Your only option is to discard it. I'd rather live by the old maxim "be liberal in what you accept, and strict in what you produce". But perhaps I'm overlooking an important u…

I mean, I think there are use-cases where a schema would bring real improvement:

- Error messages: A validator doesn't just have to tell you that a document is invalid, it can also tell you why it is invalid and what you have to do to fix it.

- Better editors or viewers: If e.g. an IDE knows that your JSON is "really" a record or a graph or a table, it could show some specialized UI and make it easier to view or edit those documents.

- Smarter auto-formatting: A schema-aware pretty-printer could format JSON in a way that's better readable than just putting every field on one line.

- Documentation generation: e.g. Swagger does this well: You pass it a schema file and it generates a polished HTML documentation, complete with examples and interactive web client.

- Code generation: You could auto-generate parsers, serialisers or data structures that are specialized for a particular schema. This would probably be most useful for low-level languages or other languages where working with generic JSON is inconvenient.

- More efficient storage: A data store that "knows" that all documents conform to a particular schema could optomize by storing/querying only the schema's data structures and not a generic JSON DOM. (Though to be fair, it's not clear how large the performance improvements from this would be, especially compared to a DB that learns similar information from the usage patterns and data that is actually stored)

That's a lot of "could"s though. So far, I haven't seen a lot of those use-cases realized. What also frequently baffles me is that use-cases almost seem like an afterthought in schema design. Most specs and blog posts (like this one) read as if a schema doesn't really need any justification and actual uses are just a nice bonus.

Instead of an overengeneered spec, I'd prefer an actual software suite which realizes some of the above use-cases - and then brings a well-designed schema language with it.

I believe Swagger/OpenAPI started this way, which might be how they gained traction at all. But judging from the OP, they seem to be taken over by the astronauts again...

Re: JSON Schema bundling formalised

#165

Post by deepakarora3 »

Not at all to be critical of JSON schema, but my experience has been that for most use cases it is an overkill. As simple as it may be, it still is relatively complex. As someone mentioned in a prior post, if the validation fails then what? Even though the JSON schema document is human readable, just by looking at the JSON schema document, its not intuitive to visualize where the particular path resides in the actual document. And one would need tools written on top of JSON schema to be able to do operations like merge one JSON document into another while validating at the same time. To make things simple, I had created JDocs. What this allows is to write the JSON schema in exactly the same structure as the JSON data document, just that the value field contains the validation specifications. Of course it does not have all the advanced features of JSON Schema (like some properties and cross referencing abilities), but then as I said, it meets our requirements in a real straightforward and simple way and opens up multiple possibilities in manipulating JSON data. You can read about it here. I would welcome feedback and apologies if you feel it is off track. Thanks.

https://github.com/americanexpress/unify-jdocs

Re: JSON Schema bundling formalised

#166

Post by staticassertion »

oaiey wrote: post #103
staticassertion wrote: post #88

Earlier quoted context omitted.

Maybe someone can chime in but parsing XML seems very much more difficult than parsing JSON.

Parsing XML is just grammar like JSON is ... that is not more or less difficult. JavaScript just has a built-in JSON Parser (which translate JSON into JavaScript object). As a consequence, JSON in JavaScript is super easy. Using XML is medium-hard. In .NET using XML or JSON is easy (not super easy). In C++ using XML or JSON is medium-hard. Do not know the state of the art for Go, Rust, Java, ... As a consequence, JSO…

> Parsing XML is just grammar like JSON is ... that is not more or less difficult.

My understanding is that that's not the case. XML parsers are Pull or SAX based and it's weird as fuck.

You can abstract that out, but parser complexity isn't something to sneeze out. For one thing, parsing XML is notoriously dangerous - tons of vulns both at a design and memory management level.

Re: JSON Schema bundling formalised

#167

Post by shados »

jbverschoor wrote: post #110
shados wrote: post #94

Earlier quoted context omitted.

They like to produce complexity, else they get bored while writing the code. But they don't like OTHER developer's complexity.

Yeah they (including younger me) loved abstractions and complexity I wrote or I read about. But it’s complex and difficult to grasp, so it’s not fun when you have to get into someone else’s mind, or even to get back into your own thinking after period of a sense of that project/architecture

Most new software devs go through that phase. A few decades ago, it was about the Gang of 4 design patterns. We were all reading that book and then looking for every possible place we could implement those patterns, even when they made absolutely no sense.

I'm so sorry for the teams I worked with in those days. The worse is I felt the folks around me were worse devs for not doing the same. It's so embarassing in hindsight.

Re: JSON Schema bundling formalised

#168

Post by ether_at_cpan »

deepakarora3 wrote: post #165

Not at all to be critical of JSON schema, but my experience has been that for most use cases it is an overkill. As simple as it may be, it still is relatively complex. As someone mentioned in a prior post, if the validation fails then what? Even though the JSON schema document is human readable, just by looking at the JSON schema document, its not intuitive to visualize where the particular path resides in the actual…

> ...if the validation fails then what? Even though the JSON schema document is human readable, just by looking at the JSON schema document, its not intuitive to visualize where the particular path resides in the actual document.

The JSON Schema specification actually does say that errors should indicate both the location within the data that the error occurred, and the path in the schema itself. So if you are having difficulty deciphering validation errors, that's a failure of your particular implementation failing to follow the spec, not the spec itself.

Re: JSON Schema bundling formalised

#169

Post by kiliancs »

kords wrote: post #151
shados wrote: post #96

Earlier quoted context omitted.

This. Back in the XML days, I had to spend way to long reading XSLT and WSDL specs just to do basic things. JSON Schema takes 15 minutes to learn and it's a heck of a lot better than writing my own validator.

I remember I was enjoying XSLT; I used it to create templates and, in the end, valid XHTML pages. I thought that's the future.

At some point I made a news-articles site and I took that approach rather than databases: the owner would write XML files for each article that would be pretty simple: e.g. with tags like `title`, `image` (left, right, hero)`, some asides and some basic formatting for the body of the article, and XSLT, templates and CSS would make it a proper page. All the magic happened in the browser. I still think that's pretty cool.

Re: JSON Schema bundling formalised

#170

Post by theteapot »

relequestual wrote: post #111
theteapot wrote: post #49

> "There are several libraries which offer bundling solutions, however they all have caveats, and I haven't seen any to date which are fully JSON Schema aware." But what's wrong with just stuffing the schemas in a flat array or object exactly?

Expectation of a single schema by existing tooling.

That's pretty vague.
Post reply on HN