6 ms·

It's significantly harder to write a compliant and performant parser for XML, even if one might be able to make it as fast. But, after parsing, the application

It's significantly harder to write a compliant and performant parser for XML, even if one might be able to make it as fast. But, after parsing, the application developer still has to transform XML data into something usable to their program. This is much easier with JSON since it's information model (map/list/scalar) matches the information model of most modern programming languages. XML is a poor choice for most serialization since it has the wrong information model. It's designed for extensible document markup and most application data packages aren’t documents that require markup.

zdw 13y ago
I'd argue the opposite, simply because XML has many well defined schema formats and XPath. If you end up having versions of data formats, or are dealing with data from an unknown source, XML is far superior, and allows for easier interchange of data. The correct way to load an XML document is as follows, IMO: * Open it * Run it through the schema to validate it's structure * Manipulate/access it via XPath, with the ability to assume correct structure as defined by the schema. Compare to JSON, where the process is * Open it * Attempt to access it, even though it's structure may deviate from the expected * Die or try to rollback work when an assumption about the data structure isn't met. Thus, most JSON code either trusts the input data implicitly, or is a mess of "is this where it should be?"/independently re-developed schema equivalent every time. I am aware of attempts to create JSON schema languages - unfortunately these are neither in common use, nor well defined enough to be standards, and they're more verbose and less expressive than XML's RelaxNG compact syntax. JSON is fundamentally a dump of a data structure, not a document format. It isn't designed for long term data storage, or for inter-compatibility, despite being used those ways. Thus, it's great if you control both ends and your data structures don't change, as is the case with most web programming. It frequently falls down outside that realm. Now, the above ignores runtime performance concerns. I'd argue (again) that outside of web apps, the load/store into a data structure is done rarely, or can be done in the background or in parallel if there's a lot of data concerned. Also, we're probably talking about less than an order of magnitude in the vast majority of cases.
- TazeTSchnitzel 13y ago
  I don't know about you, but I don't find it difficult to just put sanity checks when reading data in case it isn't as expected. And hey, you need to validate user data anyway, schema or no.
- lmm 13y ago
  The thing is it's almost impossible to express all the constraints on your input in schema. You certainly can't encode "userId must match a user that exists in the database" as part of a schema. So with XML you end up having two validation processes - the schema and then the part of your code that checks that the input datum really is valid. And then when the time comes to add another check you realize that code is a much more expressive way to write your constraints, and it's always possible for input to be rejected at the code stage, so you might as well just add your check there. So the schema level ends up being a useless extra complication.
  - zdw 13y ago
    I don't think you get what schemas are for. Schemas don't validate the content - they validate the structure and variable types. It doesn't magically make the data valid. It lets you make assumptions about how that data is structured. The advantage of a schema is that one schema can be used in multiple languages. Someone's Lua based embedded system can run the same schema as a Go program on a 32 CPU box. You can give someone a well written schema, tell them "make your data like this, and run the validator when you open and save your XML". In this way, it's a free, one line (in most languages) structure sanity check.
    - lmm 13y ago
      >I don't think you get what schemas are for. Schemas don't validate the content - they validate the structure and variable types. It doesn't magically make the data valid. It lets you make assumptions about how that data is structured. In a typed language the very first stage of deserialization, the "turn this from a string into objects in my language" step, will do that for you "for free". In an untyped language I guess it could be helpful, but again: it's almost always easier to write these sort of checks in a general purpose programming language than in XML schema. >The advantage of a schema is that one schema can be used in multiple languages. Someone's Lua based embedded system can run the same schema as a Go program on a 32 CPU box. If that's what you want there are more robust and performant approaches, e.g. thrift. >You can give someone a well written schema, tell them "make your data like this, and run the validator when you open and save your XML". In this way, it's a free, one line (in most languages) structure sanity check. Right, but that doesn't tell them what they think it means. It doesn't make the request valid.
corresation 13y ago
It's designed for extensible document markup This is, and always has been, an absolutely terrible way of writing off XML. Do we judge every technology today based upon their purported original purpose? "The computer was designed to solve linear equations, therefore it is ill suited for any other purpose". Noisy nonsense. JSON only maps to the information model of JavaScript, and has no closer ties to any other language than XML does.
- TazeTSchnitzel 13y ago
  JSON maps to common structures in most languages. A JSON Array is comparable to a JS Array, a C/C++ array, a C++ list, a Python list, a PHP array, a C# List, etc. A JSON Object is comparable to a JS Object, a C++ map, a Python dict, a PHP array or object, a C# Dictionary, etc. By contrast, XML does not directly map to common data structures.
- clarkevans 13y ago
  XML has lots and lots of complexity needed so that you could read the "underlying text" (by stripping elements) and for processing notation extensions. For example, you have attributes for out-of-band information, and, this requires additional escaping and content normalization rules. Comparison has multiple definitions because white-space is significant; or not, depending on context. XML specification is ten times longer; it has dozens of sharp edges you have to memorize in order to use effectively. If you believe that XML's information model maps onto "any other language" just as well as JSON, please show me native mapping/object support in XML and, conversely which programming languages (besides XSLT) have mixed content and attributes.
  - corresation 13y ago
    If you believe that XML's information model maps onto "any other language" just as well as JSON, please show me native mapping/object support in XML and, conversely which programming languages (besides XSLT) have mixed content and attributes. You can serialize to/from XML in virtually any modern language. Not sure if you're seriously asking this, or what the limiter "native" is supposed to mean (beyond that JSON is JavaScript. But it isn't C#, and it isn't Python, and it isn't...). How they use attributes or elements is context specific. Every feature and pattern doesn't apply to every use. XML specification is ten times longer; it has dozens of sharp edges you have to memorize in order to use effectively. No, you actually don't. You create an XSD of a simple layout (trivial, monkey work). That is what you serialize from/to. The universe of possibilities in XML is, again, utterly and absolutely irrelevant. Seriously, JSON doesn't even have a DATE type. That is so fundamentally broken I don't even know where to start (Microsoft has their own mystical blend of date when they use JSON, for instance, incompatible with anything else).
TeeWEE 13y ago
I like json to, because its lean and mean. But with a schema you can built a connection from system A to system B without having to deal with the underlying XML. However protocolbuffers would be a better choice then. :p

zdw 13y ago

I'd argue the opposite, simply because XML has many well defined schema formats and XPath. If you end up having versions of data formats, or are dealing with data from an unknown source, XML is far superior, and allows for easier interchange of data. The correct way to load an XML document is as follows, IMO: * Open it * Run it through the schema to validate it's structure * Manipulate/access it via XPath, with the ability to assume correct structure as defined by the schema. Compare to JSON, where the process is * Open it * Attempt to access it, even though it's structure may deviate from the expected * Die or try to rollback work when an assumption about the data structure isn't met. Thus, most JSON code either trusts the input data implicitly, or is a mess of "is this where it should be?"/independently re-developed schema equivalent every time. I am aware of attempts to create JSON schema languages - unfortunately these are neither in common use, nor well defined enough to be standards, and they're more verbose and less expressive than XML's RelaxNG compact syntax. JSON is fundamentally a dump of a data structure, not a document format. It isn't designed for long term data storage, or for inter-compatibility, despite being used those ways. Thus, it's great if you control both ends and your data structures don't change, as is the case with most web programming. It frequently falls down outside that realm. Now, the above ignores runtime performance concerns. I'd argue (again) that outside of web apps, the load/store into a data structure is done rarely, or can be done in the background or in parallel if there's a lot of data concerned. Also, we're probably talking about less than an order of magnitude in the vast majority of cases.

TazeTSchnitzel 13y ago
I don't know about you, but I don't find it difficult to just put sanity checks when reading data in case it isn't as expected. And hey, you need to validate user data anyway, schema or no.
lmm 13y ago
The thing is it's almost impossible to express all the constraints on your input in schema. You certainly can't encode "userId must match a user that exists in the database" as part of a schema. So with XML you end up having two validation processes - the schema and then the part of your code that checks that the input datum really is valid. And then when the time comes to add another check you realize that code is a much more expressive way to write your constraints, and it's always possible for input to be rejected at the code stage, so you might as well just add your check there. So the schema level ends up being a useless extra complication.
- zdw 13y ago
  I don't think you get what schemas are for. Schemas don't validate the content - they validate the structure and variable types. It doesn't magically make the data valid. It lets you make assumptions about how that data is structured. The advantage of a schema is that one schema can be used in multiple languages. Someone's Lua based embedded system can run the same schema as a Go program on a 32 CPU box. You can give someone a well written schema, tell them "make your data like this, and run the validator when you open and save your XML". In this way, it's a free, one line (in most languages) structure sanity check.
  - lmm 13y ago
    >I don't think you get what schemas are for. Schemas don't validate the content - they validate the structure and variable types. It doesn't magically make the data valid. It lets you make assumptions about how that data is structured. In a typed language the very first stage of deserialization, the "turn this from a string into objects in my language" step, will do that for you "for free". In an untyped language I guess it could be helpful, but again: it's almost always easier to write these sort of checks in a general purpose programming language than in XML schema. >The advantage of a schema is that one schema can be used in multiple languages. Someone's Lua based embedded system can run the same schema as a Go program on a 32 CPU box. If that's what you want there are more robust and performant approaches, e.g. thrift. >You can give someone a well written schema, tell them "make your data like this, and run the validator when you open and save your XML". In this way, it's a free, one line (in most languages) structure sanity check. Right, but that doesn't tell them what they think it means. It doesn't make the request valid.

corresation 13y ago

It's designed for extensible document markup This is, and always has been, an absolutely terrible way of writing off XML. Do we judge every technology today based upon their purported original purpose? "The computer was designed to solve linear equations, therefore it is ill suited for any other purpose". Noisy nonsense. JSON only maps to the information model of JavaScript, and has no closer ties to any other language than XML does.

TazeTSchnitzel 13y ago
JSON maps to common structures in most languages. A JSON Array is comparable to a JS Array, a C/C++ array, a C++ list, a Python list, a PHP array, a C# List, etc. A JSON Object is comparable to a JS Object, a C++ map, a Python dict, a PHP array or object, a C# Dictionary, etc. By contrast, XML does not directly map to common data structures.
clarkevans 13y ago
XML has lots and lots of complexity needed so that you could read the "underlying text" (by stripping elements) and for processing notation extensions. For example, you have attributes for out-of-band information, and, this requires additional escaping and content normalization rules. Comparison has multiple definitions because white-space is significant; or not, depending on context. XML specification is ten times longer; it has dozens of sharp edges you have to memorize in order to use effectively. If you believe that XML's information model maps onto "any other language" just as well as JSON, please show me native mapping/object support in XML and, conversely which programming languages (besides XSLT) have mixed content and attributes.
- corresation 13y ago
  If you believe that XML's information model maps onto "any other language" just as well as JSON, please show me native mapping/object support in XML and, conversely which programming languages (besides XSLT) have mixed content and attributes. You can serialize to/from XML in virtually any modern language. Not sure if you're seriously asking this, or what the limiter "native" is supposed to mean (beyond that JSON is JavaScript. But it isn't C#, and it isn't Python, and it isn't...). How they use attributes or elements is context specific. Every feature and pattern doesn't apply to every use. XML specification is ten times longer; it has dozens of sharp edges you have to memorize in order to use effectively. No, you actually don't. You create an XSD of a simple layout (trivial, monkey work). That is what you serialize from/to. The universe of possibilities in XML is, again, utterly and absolutely irrelevant. Seriously, JSON doesn't even have a DATE type. That is so fundamentally broken I don't even know where to start (Microsoft has their own mystical blend of date when they use JSON, for instance, incompatible with anything else).

TeeWEE 13y ago

I like json to, because its lean and mean. But with a schema you can built a connection from system A to system B without having to deal with the underlying XML. However protocolbuffers would be a better choice then. :p