[grndn]

The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc).

I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another. Followed shortly by a standard for JSON namespaces so you can mix different schemas, a standard for binary JSON, a standard for JSON-encryption, and so on.

"Those who cannot remember the past are condemned to repeat it."

[coldnebo]

Flashback to the early days of XML: "oh god, why would anyone use something as bloated and slow as CORBA to define an interface! Look how simple XML is, and it's human readable!!"

CORBA is laughing its head off: "Who's bloated and overly complex now, eh?"

XML: "Well at least I developed an appreciation of the problem domain... Unlike those arrogant JSON kids"

CORBA: "You were the same way at their age."

XML: "Sure was, gramps!"

(Both chuckle)

[ultimape]

I've been actively staying away from CORBA myself.

Back in college, we tried our hand at using Ice http://www.zeroc.com/iceVsCorba.html and it seemed to do the trick.

Still, it does assume that both parties have access to the template generated by ice - thus going back to the issues surrounding needing a sort of schema.

That being said, there does seem to be options for interacting using json: http://ice2rest.make-it-app.com/ and as of 3.3.1 it apparently supports Google's Protocol Buffers for flexibility.

[crdoconnor]

>The problems that XML and XSLT address have not gone away. It saddens me when the XML-hating JSON community starts reinventing solutions that have all the same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren, etc).

JSON schema:

Validing schemas is not as nearly important for JSON as it is for XML. JSON's relative simplicity the problem of "almost-but-not-quite" valid encoding mostly goes away.

As a result, not many people use JSON schema.

Even when I work with XML I very rarely come across code that performed actual XML validation. Most people would just wing it and hope nothing broke. That's the first dirty secret of XML validation.

The second dirty secret is that if you are consuming an API that provides invalid XML (a common occurrence), you just deal with it and try to make it work. XML validity be damned.

Collection+JSON:

Literally never heard of this. Don't need it either. Once the JSON is deserialized you can use the language's own tools (and a combination of lists/arrays + maps). So what's the point? I don't miss XPath or XQuery.

Siren:

An solution attempting to solve a non-problem copied from a solution from the XML world that didn't solve a problem either.

[Arwill]

Its a generational thing. Programmers grown up on JavaScript will prefer JSON. Its not a unique phenomenon. My guess is the noSQL was born out of fact that many young programmers simply don't know how to write SQL, if they don't know/want to use SQL and rely on ORM mapping alone, then they can as well do away with SQL databases too.

[marcuskaz]

> Its a generational thing. Programmers grown up on JavaScript will prefer JSON

Not really, JSON is a simpler format with better parsing built-in for most languages. It is easier to use for programmers and performs better across the network.

This is as true today as it was true 7-years ago when I wrote this article: https://mkaz.com/2007/03/02/goodbye-xml-hello-json/

[bkeroack]

And YAML is a better JSON with comments and no need to balance braces.

[matwood]

if they don't know/want to use SQL and rely on ORM mapping alone, then they can as well do away with SQL databases too.

Until that whole leaky abstraction problem kicks in.

[tree_of_item]

The idea behind doing away with the SQL database is to remove the leaky abstraction of an ORM, by making the object model the true shape of the data and not a wrapper over SQL.

[krig]

In my experience, the people forcing schemas and bloat on JSON are the same people who forced schemas and bloat on XML.

[crdoconnor]

Fortunately they're usually ignored.

[Mikhail_Edoshin]

So the problems are real, it's just that XML and XSLT (and now JSON schema et al.) solve them badly (to your taste)?

[carsongross]

I took a KI(RF)SS stab at a JSON schema description language, attempting to avoid the insanity of the XML world but still provide a bit of structure for JSON, a while back:

http://jschema.org/

Haven't touched it in a few years, but I think the core idea is sound: as much schema as can be packed into 15 additional productions beyond the original 15 in the JSON spec.

I wrote a typeloader for Gosu based on it:

http://vimeo.com/29348322

[skrebbel]

I once braindumped a similar idea on https://github.com/eteeselink/relax-json (inspired by RELAX NG, one of the few great things to come out of the XML world).

A core difference between it and your JSchema is that it, itself, is not JSON - just like XML, I don't think JSON makes for a good format to write down schema definitions. In fact, I don't think JSON is very human friendly at all[0], which is OK for a data interchange format, occasionally read by humans but hardly ever written by hand.

I did not further develop RELAX JSON, however, when I realized that TypeScript interface definitions[1] are a great JSON schema language:

    enum Color { Yellow, Brown }; 

    interface Banana {
        color: Color;
        length: number;
    }

    interface FruitBasket {
        bananas: Array<Banana>;
        apples:  Array<{color: Color; radius: number}>?;
    }

It's best to use interfaces and not classes, because interfaces allow for optional fields (with the `?` suffix), which is pretty common in APIs and wherever JSON is used.

I will write a validate-JSON-with-TypeScript-type-definitions checker as soon as I find a need for it. Open to ideas here, guys! (or alternatives)

[0] Compare gruntfiles to webpack configs (tl;dr: they're JSON and JS-that-returns-an-object, respectively. the latter allows code, comments, unquoted keys, etc etc).

[1] http://www.typescriptlang.org/Handbook#interfaces

[mtrn]

> I would not be surprised if someone soon announces a "JSON Transformation" tool that can convert one JSON schema to another.

I'm not exactly guilty of that, but I do have some use cases, where one json document needs to be mapped to another one.

In a weak moment, I actually sketched a simple protocol for using javascript to express these "transformations": https://gist.github.com/miku/620aecc5ad782f261e3b

[hyp0]

There have been several JSON transformation tools, but they haven't taken off. (EDIT in general, not just for transformation,) when a task gets too complex for JSON, it's easier to switch to XML. Thus: XML protects JSON.

But I agree there is some pressure on JSON. And if someone can come up with a way to do schema and transformation that isn't complex, it will be adopted like crazy.

Counter-point: (1) all the cool kids use dynamic typing these days, and don't need schema (schema is a form of typing). (2) transformation is easy in fp (which the cool kids are also using), and don't need a separate transformation tool.

[crdoconnor]

>There have been several JSON transformation tools, but they haven't taken off. When a task gets too complex for JSON, it's easier to switch to XML. Thus: XML protects JSON.

Uh, no. In general if you're sensible enough to use JSON as a data interchange format, you're probably sensible enough to use a real programming language to do transformation.

[coldnebo]

There is a lot of confusion between typing systems, metatyping systems (that can implement arbitrary type systems) and the transport representation of such systems.

I agree with your counterpoints, but the cool kids are still having issues with transport representation of arbitrary types. Sure (eg Ruby) can use Kernel dump and load to marshall arbitrary types, but what happens when the other end doesn't have the type loaded or available?

Ouch, maybe we should invite Java Enterprise Beans to the party to comment on the semantics of distributed types?

JSON is currently deceptively simple precisely because its wire representation (with simple types) is equivalent to its type definition which can be directly evaled in js to produce a memory instantiation. But none of that holds in the general case... Try for example marshalling a JSON object with a tree structure.

Maybe we end up going in Alan Kay's direction, where we stop trying to send representations across the wire and just send code... But that too was tried in the past. It has other limitations.

It's complicated.

[crdoconnor]

>JSON is currently deceptively simple precisely because its wire representation (with simple types) is equivalent to its type definition which can be directly evaled in js to produce a memory instantiation.

It's not deceptively simple. It's just simple. The fact that it can be evaluated in JS is incidental to its use as a general purpose format for serializing data structures.

>Try for example marshalling a JSON object with a tree structure.

I've done this lots of times. I don't see any issue with it.

[coldnebo]

The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler.

Here's a very simple example of marshaling comparing Marshal dump and load in Ruby using YAML, vs. custom JSON marshalers: http://www.skorks.com/2010/04/serializing-and-deserializing-...

Note that the post shows a tree structure in YAML because Marshall gives it to you for free (synonymous with Java serialize behavior). But the post punts on implementing the same tree in JSON, probably because it's messy and complicated.

Nothing about that looks simple to me. For example, the JSON class label "A" has to be interpreted by something to actually instantiate an A Object. YAML is a bit better-- it at least defines that there is a Ruby class instance being marshaled -- but it doesn't help you if that class doesn't exist the same on client and server.

Pretty soon this leads to madness in production systems where the server evolves "A" (v2) among a sea of separately evolving clients "A" (v1, v1.1, v1.2). Then versioned class annotations get introduced, followed by attempts to differentiate between serializable and non-serializable fields, deep and shallow serialization, etc. etc. Pretty soon, your JSON marshaling isn't so simple anymore.

[crdoconnor]

>The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler.

Which makes perfect sense. If you cut everything down to bool, null, number, string, list and map you can represent anything and you get to remain language agnostic.

Dates can be encoded as strings and so can most of the other more 'awkward' types. This is additional work, but it's not that complicated and not a lot is gained anyhow by putting this stuff in the spec.

You really can't get more complicated than this anyhow, without introducing nasty security vulnerabilities.

[coldnebo]

> you can represent anything

If you represent something, you need to interpret it later... i.e. both client and server need the same interpretation in order to avoid errors.

> Dates can be encoded as strings and so can most of the other more 'awkward' types.

You say 'encoding', I say 'serialization'.

> It's not that complicated

It isn't as long as you use the same platform for encoding and decoding.

Maybe our experiences are different. I remember one time I had to unencrypt a string in Ruby that had been encrypted in Java. I thought, this will be simple, it's a standard AES encryption, I'll just stuff the string into the corresponding Ruby object and decrypt! I mean, both of these objects were implemented according to the same industry standard right? Boy was that a learning experience. :) Framing, padding and seeding was not implemented the same way -- it was left as a platform implementation detail that only someone trying to integrate across systems would ever notice.

[felixgallo]

As an example of the deceptive simplicity, could you please describe how many bytes are required to deserialize numbers represented in JSON? Note: answer is not 2,4, or 8.

[crdoconnor]

The JSON spec has no opinion on that and that's a good thing. It is up to you, your language and your parser to decide how large the largest JSON number should be.

Would it be simpler to enforce a global 32 bit or 64 bit limit on those numbers in the spec? I don't think so. Why should the limitations of embedded microcontrollers exchanging data apply to those of astronomical systems and vice versa?

[coldnebo]

I should have been more specific... it's not really about trees per se, it's more about custom types. (I was thinking of trees of custom types).

[ultimape]

I'm a fan of the techniques as described in : http://smile.amazon.com/Expert-Business-Objects-Books-Profes...

Basically, it uses the underlying runtime to serialize the entire object to the other machine. The theory being, if object oriented programming ties data to functions, why not ship both over the wire?

It works really well with the micro-services paradigm.

Not exactly a 100% solution, but it does solve the issues at least among the languages the runtime supports.

[skywhopper]

Ultimately, I think the problem is that everyone thinks we need to be able to do all the same things with structured, hierarchical data that we can do with normalized, relational data. And it's like going from 2-D to 3-D. Things don't get just twice as complicated, they get exponentially more complicated as the problem-space and schema complexity grows.

Thus any toolset that tries to address relationships, schemas, searching, and grouping in an XML/JSON type data format is going to be exponentially more complicated than RDBMSes and SQL.

[boronine]

I'd just like to plug Teleport [0] into the list of reinvented JSON-based solutions. It's in active development :)

[0] http://teleport-json.org

[crdoconnor]

That actually looks pretty nice.

[lowmagnet]

The only use of XSL in my past was to take XMLthat's already in the right structure and simply iterate via apply templates. XSL excels this sort of simple template work.

So does mustache, with a bit less resistance/overhead.

So does Polymer if you make your xml tags into web components and apply them. It also has all of the benefits of Polymer's isolation.

I think xsl was and is a good idea. I just think that other things have come along that are easier to get into.

[benihana]

>XML-hating JSON community

What are you even talking about? It seems like you think that XML and JSON are two mutually exclusive technologies and that if one is bad, the other is good. Or that if one is used, the other can't be? I don't understand why you even started talking about JSON; the article was about why XML and XSLT suck, not why JSON is superior to them.

I'm not really sure what point you're making. JSON is meant to make passing data in JavaScript easier. It's a necessary tool for interactive, JavaScript-heavy web frontends. I'm not sure why there's so much condescension in your post for JSON and its tooling. I'm just a bit confused; it comes off like you have a personal stake in XML and you find any mention of JSON, even obliquely, as offensive.

There's no reason that XML and JSON can't both be tools we use when the situation calls for it. This kind of dogmatic defense or condemnation of technologies offhand doesn't really do the HN community or the programmers at large any good.

[general_failure]

> JSON is meant to make passing data in JavaScript easier.

No, its not.