[carsongross]

The baby that has been thrown out with the bathwater here is a schema/data description layer.

NOT, I repeat NOT, I repeat NOT for verification but rather for tools, so that people working in strongly typed languages can interact with JSON services in a reasonable manner.

Unfortunately the one option I see, JSON Schema, appears to have caught the XML/Java bug, and has gotten very complicated.

[SigmundA]

That because schemas are complicated, no matter which way you encode the data.

JSON is so nice and easy and simple until it needs all those things that made it into XML to get the job done.

I whole heartedly agree, there is nothing sweeter than giving another vendor our WSDL with schema when they ask how to work with our system. It eliminates huge effort and ambiguity in system interaction.

[DuncanIdaho]

Not sure if serious...

SOAP, WSDL and everything else XML and XML Schema related is overkill for simple interfaces. For complex interfaces it is just - well too complex.

If the time spent creating XML based web services that kinda but not really work (we're only talking interfaces here!) is spent documenting your JSON WS - you get quite a better experience.

Ant this is the reason why everybody has switched to JSON.

[SigmundA]

I am serious, document a JSON interface with what, English? Are you serious?

JSON has no way to describe in machine readable way what to expect, instead you have to read a document then go hand code the interface in your language of choice.

WSDL and SOAP is not complicated, and I have implemented my own SOAP stack. Then again everyone now days everyone thinks relational databases are complicated.

If you you have tools that implement it for you then there is no excuse.

[carsongross]

Well, I think there is a middle ground: non-recursive structs, lists, maps, and some judicious "primitives" and basically allowing only natural tree mappings would go a long way, IMO.

[alavrik]

I couldn't agree more!

Out of frustration with existing schema languages and tool support for them, I've been working on Piqi[1] which is concise, expressive and agnostic to data representation formats. It works for JSON, XML and Protocol Buffers.

[1] http://piqi.org

[ismarc]

I've been using Piqi on a side-project of mine and I must say, I'm horribly impressed (using piqi_rpc with erlang for a web service and javascript based client to retrieve/interact with the data). The only way it could be nicer is if there was the same sort of generator for javascript so I didn't end up having to check/enforce the format at all.

Didn't realize you hung out on HN, so many thanks and great job.

[alavrik]

ismarc, thank you for the comment! I really appreciate it -- I didn't know anyone else was using Piqi-RPC (other than myself).

I'd like to know more about your use case and the need for JavaScript generation. I'm open to new ideas. Could you please contact me at [e-mail] Thanks!

[andrewflnr]

That looks very cool. I'll look at it, and maybe steal a few ideas :). I've been working on a data language myself in my spare time, mostly concentrating on generative structures like conditionals and loops and a syntax-independent data model. But Piqi looks to be a lot more ambitious, not to mention mature.

[alavrik]

Thanks! Feel free to reuse as many ideas as you like :) It took me more than 2 years to get it there -- it is by far the toughest system I've ever designed.

[haberman]

Use protocol buffers! As easy to use as JSON in dynamic languages, gives you strongly-typed accessors in static languages.

[carsongross]

Yeah... no. I'm not a big code gen guy.

But the google people seem to love them, so I'm probably in the minority.

[haberman]

> Yeah... no. I'm not a big code gen guy.

Me either! Which is why I'm working on a high-performance Protocol Buffer library that does not do code generation: https://github.com/haberman/upb/wiki

[gaustin]

Excellent readme for that project. It details several issues of which I wasn't aware.

Thanks for that.

(edit: It wasn't the readme, it was the wiki page. Still, excellent documentation.)

[loup-vaillant]

>[…] so that people working in strongly typed languages can interact with JSON services in a reasonable manner

You mean languages that lacks algebraic data types? Because JSON encodes beautifully in ML and Haskell, and their type systems are quite static and quite strong.

[rorrr]

JSON-schema, if you really need it

http://tools.ietf.org/html/draft-zyp-json-schema-03

[roel_v]

I haven't been able to find any solid, broad implementations of anything that brings schemas to json - either this ietf standard or something else. Only some half-assed and not developed for years implementations for a single programming language. Are there implementation of the spec you link to?

[lost-theory]

It's not JSON-schema, but Rx is a schema validation tool for JSON/YAML/etc. that works with many languages:

http://rx.codesimply.com/

[roel_v]

Yes, this is one of the half-assed, half-dead efforts I was referring to. Last commit Jan 2010, and even that one touched only some files, previous commits are all from 2008. It only supports a few languages - no C++, no Java, no .Net. The website itself says on the first page "relying on any implementation in production would be a bad idea". Plus, Rx doesn't offer the same functionality XML Schema does, from what I can find (only does type checking, no element order/count, default values etc).