JSON Schema compared with XML Schema and their future
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.
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.