32

I was looking for JSON schema standards and their corresponding php implementations. Expecting some open source out there and I was surprised, to find only one php implementation. I was about using this technology (JSON) and the schema lib to parse my incoming browser requests.

This natural parse/validate activity seems natural in XML and make me wonder why this is not the case in JSON.

I end up with a doubt situation. Should I pursue my JSON structure data exchange or switch to XML? I first chose JSON for its simplicity and less verbose syntax compared to XML, but if I have to redevelop all existing standard in the world these arguments becomes lighter. I also chose JSON hoping to limit the size of communications between my web server and my mobile apps. Playing with comet apps, XMPP seems to be implemented and used by big names like Google, Facebook, for their real time chat chat text or video based messages.

So the actual questions are:

  1. Is JSON for the poor web server developer that wants to know what happen on its traffic, and focus on over simplicity (do not be mistaken, here, I include myself)?
  2. Does IETF draft for JSON schema is a serious work, since only few implementation exist on the server side (PHP)?
  3. Am I missing something, or maybe, the best communication pattern is to send data in xml to the server and expect a json response (many json schema implementation exist in javascript)?
  4. Or did I only faced the actual proof, that this concern has not been well served by the developer community because web developer using JSON do not test deeply their incoming request data?

Please help me understand, I am missing some experience here?

jassa
  • 20,051
  • 4
  • 26
  • 24
Alain
  • 1,450
  • 3
  • 20
  • 37
  • It looks like other people answered your actual questions, but I wanted to point out that if you only found a single implementation you missed a few. e.g. here's one in Java: https://github.com/fge/json-schema-validator, and there were a couple I saw implemented in JavaScript too. – Eric Jun 19 '12 at 17:49

4 Answers4

12

This natural parse/validate activity seems natural in XML and make me wonder why this is not the case in JSON.

Remember what made JSON famous: web applications with a very rich user interface written in JavaScript. JSON was perfect for that because data from the server mapped directly on JavaScript objects; hit a GET URL with Ajax and get back an object, no need for parsing or anything else.

Those rich interfaces made JavaScript a very popular language and JSON obviously rode along and it's popularity made it become the best candidate to overthrow "the angle bracket".

But XML has a long history behind it. It's a mature technology with lots of accompanying specifications. JSON is just catching up to those.

Although the draft specification expired in May 2011, the JSON Schema supporters think they have reached a pretty close to final version of the spec. So who knows what the future has in hold for JSON Schema.

I was surprised, to find only one php implementation [...] Does IETF draft for JSON schema is a serious work, since only few implementation exist on the server side (PHP) ?

Does this PHP implementation validate JSON as per the last version of the JSON Schema draft? If yes, is there a need for other implementations? Do you need lots of implementations to certify a specification is serious? That's just as saying that XSLT 2.0 is not serious because Microsoft didn't bother to implement it.

As for your last question, incoming data needs to be validated. You don't take a user request and throw it to the server and "hope it sticks". You validate it; and JSON Schema is not the only way to validate JSON data, so don't assume that web developers using JSON do not deeply test their incoming request data.

In conclusion, what I'm trying to say is that JSON can't fully replace XML, or the other way around. So use each technology where appropriate.

Community
  • 1
  • 1
Bogdan
  • 23,890
  • 3
  • 69
  • 61
  • My apologizes if I offended IETF JSON defenders. My thought came from a naive analysis on my actual research: Third draft, expired since a while, and limited commitment from industrie's implementation. My intentions are purely to understand, why nobody seems to have implemented more widely this thing on the server side (php). The real question is: Am I trying to over validate my data ? If not, since you mention it, what would be your prefered lib out there that does a good job about validating json input ? Finally thanks for the related SO question (I missed it). – Alain Mar 25 '12 at 18:52
  • 2
    @Alain: I understand you are intrigued by the low adoption of this technology and the fact that there's really [only one PHP implementation worth mentioning](http://sourceforge.net/projects/jsonschemaphpv/) (which itself is not active) but these things sometimes happen. **I think JSON's popularity propelled it into being used in all sorts of situations while best practices didn't have time to follow along.**. As for validation, remember that JSON is not a native format for most languages. That means that JSON is converted to a native object... – Bogdan Mar 25 '12 at 20:57
  • 1
    ... You get your first validation on the conversion if that fails. If conversion passes, then the language is better suited to validate a native object instead of a representation of it. A schema is indeed very usefull as it steps in the validation process very early, but missing a schema is not a show stopper for doing JSON validation. – Bogdan Mar 25 '12 at 20:57
7

You ask many different things in your question and I am not certain I have correctly captured what you are really looking for but here are some thoughts:

While you can represent data both in JSON and XML they are quite different. I am not going to even try being accurate here, but hope to give you the right idea:

  • JSON is a lightweight way to (de)serialize and pass key/value and lists of values around. It's light, it's easy, convenient and some would argue more readable than XML. Serialization/deserialization is easily done in all languages.

  • XML is an extensible markup language that not only represents data but also specifies rules (or protocols if you like) about them.

This does not only have to do with just providing a schema. Since you mention XMPP which chooses XML to represent its protocols, consider the following example:

Let's say that in some XML-based representation designed to exchange music information where an <album> element is defined.

<album>The Contino Sessions</album>

Clients developed to parse this XML will know how to interpret the tag. Now, Foo Bar might come later and build upon the protocol extending it as such:

<album foobar:genre="Electronica">The Contino Sessions</album>

Old clients knowing nothing about the foobar namespace will continue working as usual ignoring the foobar:genre. Those enhanced to understand the foobar will parse the genre annotation. This illustrates by example how XML is not simply a data representation. Try thinking how you would do the same with JSON. You will find you can't with the same costraints. This is why it is very unlikely for instance that an XMPP implementation can be done in JSON.

That said, XML carries its own burdens. It's hard to build good XML parsers. It's even hard to use XML for simple serialization. Human readability is an euphemism for headache when it comes to figuring out long documents etc.

In short:

  • When you merely pass data around JSON is fine and easy.

  • When you develop a protocol which will be extended in different ways by third-parties XML is the way.

  • Conversions back and forth are a BAD idea. You cannot merely convert XML to JSON.

ggozad
  • 13,105
  • 3
  • 40
  • 49
  • So, where I find many clients for my data, I should use xml to protect them and myself of our respective extensions. Well proposed. Thanks for the elaborated response, it clarify slowly my thoughts. Am I still puzzled about why there is no such thing as a bunch of JSON schema lib. **No matter who I am speaking to, (client, server, ...), should I not always validate what comes in ? Does my requirement is too excessive or does developer teams do not bother testing for corrupted (hacked) data between their own server and client ?** – Alain Mar 25 '12 at 18:25
  • 1
    You guess right that a lot of web apps perform no validation. Of course this is a bad practice and of course you should avoid it. On the other hand not having schema support for JSON does not stop you from validating. I don't think for any practical applications this is a problem for JSON. – ggozad Mar 25 '12 at 18:42
  • The way to implement the example you mention above in json would simply be `{"album": { "name":"The Contino Sessions"}}"`, and extend it via `{"album": { "name":"The Contino Sessions", "genre":"foobar"}}"` – speedplane May 07 '20 at 19:43
5

There are many alternatives to data exchange and we're looking at 2 popular technology here. XML is generally larger than JSON but XML is more flexible and can do more things. Like COKE and Diet Coke in terms of Sugar.

if you have services serving XML then why not create an adapter to serialize the XML to JSON and serve both. We just want to avoid the redevelopment stuff by adding another layer.

Have a read. http://www.thomasfrank.se/xml_to_json.html

HTTP Compression can also help keep XML files small across the wire.

My say. for complex data i'll use XML, for simple ones I'll use JSON. I'll use both.

how about the future? I'll say I don't know.

Cheers!

DAEMYO
  • 989
  • 8
  • 12
  • I read your article and the others. Let me try to describe what I understand and please confirm my assumptions. + Playing with an xml response from my server will be painful, so to simplify the developer's job, you convert the equivalent xml into a JSON object, which becomes a convenient object to manipulate in the browser's environment ? Ok, that is a plus. – Alain Mar 25 '12 at 18:01
  • + However, the main point is about validation. A server, or a client, must validate different qualities against any received data. I cannot process any data, if I have not been testing it against my assertions, for my server and my client's browser safety and sanity. So, why is it still absent in the JSON world ? – Alain Mar 25 '12 at 18:05
  • Data validation: for instance, is this data structure balanced, is there missing attributes, are some data out of boundaries, has my data been corrupted by some hacker in the process or a bug I never corrected. I strongly believe (and this might be arguable, so please feel free to comment), I cannot process any data if I have not been testing it against these (and more) assertions, for my server and my client's browser safety and sanity. – Alain Mar 25 '12 at 18:07
2

I found this useful Google groups #json-schema and JSON Schema: specifying and validating JSON data structures.

Milindu Sanoj Kumarage
  • 2,714
  • 2
  • 31
  • 54