Comment by grndn

11 years ago

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

31 comments

grndn

Reply
coldnebo  11 years ago

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  11 years ago

    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  11 years ago

>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  11 years ago

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.

  • matwood  11 years ago

    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  11 years ago

      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.

carsongross  11 years ago

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  11 years ago

    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  11 years ago

> 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  11 years ago

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  11 years ago

    >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  11 years ago

    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  11 years ago

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

      6 replies →

    • ultimape  11 years ago

      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  11 years ago

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.

lowmagnet  11 years ago

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  11 years ago

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