Hacker News Reader

Comment by bsaul | Hacker News Reader

Considering the amount of json around, wouldn't it be time to settle on a standard for :

- schema definition ( using something like typescript ? )

- data path ( similar to xpath )

- data transformation ( similar to xslt )

i'm pretty sure many people have done their things but i'm still waiting to see a tool like wsdl - based stub generators that would work on many json api.

ps : i know that things like jsonpath and wsdl2 exist, but i really feel like those technologies haven't caught widespread adoption.

View on HN

I agree and I believe that the way to accomplish this is to use Protocol Buffer schemas.

Protocol Buffers and JSON have an extremely similar data model. The parts of them that people actually use are effectively identical. The actual differences are minor things like:

- JSON can have arrays of arrays; with Protocol Buffers you need a message in between.

- Protocol Buffers can represent binary data directly; with JSON you have to base64 encode it into a string.

- Protocol Buffers are more specific about the size of integer types (int64 and int32 are different); this allows for more efficient in-memory representations but doesn't matter so much on-the-wire.

I think the two are a match made in heaven.

Yes, i also thought of protocol buffer right after sending that comment. Although i wonder : is there any way you could automatically generate a full service/model layer for, let's say angularjs or objective-c, based solely on protocol buffer "standard" ?

You're basically describing Piqi: http://piqi.org/

Thanks for the reference, I hadn't seen that. I really believe, though, that the solution to interoperability is to use protocol buffer schemas directly; not to introduce yet another schema language.

> schema definition ( using something like typescript ? )

There is a draft RFC called JSON Schema: core definitions and terminology (draft-zyp-json-schema-04).

> data path ( similar to xpath )

RFC 6901. (JavaScript Object Notation (JSON) Pointer)

if you need all these , you should use XML. Crockford said he is not interested in any JSON standard extension, at all. not even to put comments in it. That's what XML is for.

Dont use JSON if you should use XML.

I humbly disagree.

The reason i'm using JSON is for the fact that's it's fast to parse, compact, and lightweight, compared to XML. Now the reason for needing the xpath/xslt/xsd version of json is not principaly because it's a serialization format, but because it's a serialization format used in almost any modern web API. Experience shows that using JSON for web APIs is a good choice. Saying "you should've used XML" may have been relevant 5 years ago, but i think it's time to assume the fact that JSON is now so much used, that it needs the same kind of tools that xml has had almost from the start.

I massively disagree. IMHO JSON is more readable, just as powerful and more concise.

Nobody mentioned comments. Nothing the GP listed would in any more be an extension to JSON than HTML is to XML.

Crockford's refusal to extend JSON is genius IMO. Totally agree with you: if the task you're trying to accomplish sounds like a fit for XML, then please use XML. JSON is what it is, and not everything needs to be gradually extended into six mutually incompatible versions of increasing bloat.

http://geekandpoke.typepad.com/geekandpoke/2012/03/thank-god...

And don't use XML if you have requirement where you need to query, insert, modify data pretty often.

Something like SQLite work wells for purposes like these.

Reply on news.ycombinator.com