4 ms·

I don't see the grandparent as pointing out a flaw in XML so much as pointing out that this isn't something that JSON can't be made to do. The only thing stopp

by j_baker 16y ago

I don't see the grandparent as pointing out a flaw in XML so much as pointing out that this isn't something that JSON can't be made to do. The only thing stopping you from having a "JSON schema" is that such a thing hasn't been blessed by a standards committee. There's nothing stopping you from writing a library that will validate JSON based on a JSON schema of some type.

roel_v 16y ago
Sure, and you can write JSON editors and namespace extensions and query languages and libraries with extensions for those query languages and then you find out that the JSON schema language isn't very good; so you make a new one and editors for that new schema language, and then you write a language to translate one JSON document into another one, with a schema for that new language of course, in all 5 of the flavors of schema languages. And then we're 10 years into the future and we're seeing this exact same article again, except with s/JSON/some simple JSON replacement/g and we're back to square one. JSON has its uses, it's quite nifty in its ease of use for doing ajax stuff, but imo the point of the article was to point out that xml vs json is a nonsense comparison much like 'sql' vs 'nosql' databases.
- sqrt17 16y ago
  You mean, like they did with DTDs, RelaxNG, and XSD (and probably half a dozen ill-conceived solution that died a well-deserved death)? Different XSD implementations do have slightly different ideas on interpreting the schema. (e.g., if your data has a bunch of A tags, then a B tag, then another bunch of A tags, do you include two occurs:unlimited statements for the A's or just one?) By the way, Javascript works just fine as a "query" language for JSON. Not as good as XPath or XQuery work for XML, but definitely better than any XML DOM manipulation in Java or another language would.
  - roel_v 16y ago
    Yes those are what I meant - my point was that this whole evolution needn't be repeated with JSON. Let's keep JSON for the things it's good at, and keep it simple, and keep XML for the things it's good, with all the complicated things we have for it now anyway.

by j_baker 16y ago

roel_v 16y ago

Sure, and you can write JSON editors and namespace extensions and query languages and libraries with extensions for those query languages and then you find out that the JSON schema language isn't very good; so you make a new one and editors for that new schema language, and then you write a language to translate one JSON document into another one, with a schema for that new language of course, in all 5 of the flavors of schema languages. And then we're 10 years into the future and we're seeing this exact same article again, except with s/JSON/some simple JSON replacement/g and we're back to square one. JSON has its uses, it's quite nifty in its ease of use for doing ajax stuff, but imo the point of the article was to point out that xml vs json is a nonsense comparison much like 'sql' vs 'nosql' databases.

sqrt17 16y ago
You mean, like they did with DTDs, RelaxNG, and XSD (and probably half a dozen ill-conceived solution that died a well-deserved death)? Different XSD implementations do have slightly different ideas on interpreting the schema. (e.g., if your data has a bunch of A tags, then a B tag, then another bunch of A tags, do you include two occurs:unlimited statements for the A's or just one?) By the way, Javascript works just fine as a "query" language for JSON. Not as good as XPath or XQuery work for XML, but definitely better than any XML DOM manipulation in Java or another language would.
- roel_v 16y ago
  Yes those are what I meant - my point was that this whole evolution needn't be repeated with JSON. Let's keep JSON for the things it's good at, and keep it simple, and keep XML for the things it's good, with all the complicated things we have for it now anyway.