3 ms·

If I'm reading you right, you're saying that XML only provides a guarantee because of an abstract agreement between parsers? Nonsense. XML has a specification f

If I'm reading you right, you're saying that XML only provides a guarantee because of an abstract agreement between parsers? Nonsense. XML has a specification for what constitutes a well-formed document and an XML Schema defines rules that assure validity. XML may be verbose and the libraries may be a pain to work with (though there are some well-written ones out there) and there may be other flaws you want to bring up, but this is not a defensible point.

Groxx 16y ago
XML spec: http://www.w3.org/TR/REC-xml/#sec-conformance http://www.w3.org/TR/REC-xml/#sec-conformance >Conforming XML processors fall into two classes: validating and non-validating. Yup, that's a guarantee alright. A guarantee consisting of the people who wrote the parser agreeing to write DTD-parsing code. Or not. Depends on your parser. It has a specification for validation because a specification for validating it has been written, based on agreement of the specification and implementation by the parsers, not because XML has some inherent, magical validatability quality. edit: this is all on top of that a spec is just a spec until someone implements it. Plenty of specs have been chucked because others did something else, or have attributes which nobody implements (how many email forms accept the full RFC-compliant email set?). A spec is an abstract agreement.
- dfox 16y ago
  I have never seen anything that implements validating XML parser as intended by specification and is actually used in production code. Half of XML consumers I've seen in production implement namespaces in various broken ways (like depend on exact values of prefixes)
- vilya 16y ago
  Well-formedness is a separate issue from validation. All XML parsers are required by the spec to reject documents that aren't well formed. You can think of it as the lexical analysis rules for XML, whereas validation is the parsing (if that helps).
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.

Groxx 16y ago

XML spec: http://www.w3.org/TR/REC-xml/#sec-conformance http://www.w3.org/TR/REC-xml/#sec-conformance >Conforming XML processors fall into two classes: validating and non-validating. Yup, that's a guarantee alright. A guarantee consisting of the people who wrote the parser agreeing to write DTD-parsing code. Or not. Depends on your parser. It has a specification for validation because a specification for validating it has been written, based on agreement of the specification and implementation by the parsers, not because XML has some inherent, magical validatability quality. edit: this is all on top of that a spec is just a spec until someone implements it. Plenty of specs have been chucked because others did something else, or have attributes which nobody implements (how many email forms accept the full RFC-compliant email set?). A spec is an abstract agreement.

dfox 16y ago
I have never seen anything that implements validating XML parser as intended by specification and is actually used in production code. Half of XML consumers I've seen in production implement namespaces in various broken ways (like depend on exact values of prefixes)
vilya 16y ago
Well-formedness is a separate issue from validation. All XML parsers are required by the spec to reject documents that aren't well formed. You can think of it as the lexical analysis rules for XML, whereas validation is the parsing (if that helps).

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.