3 ms·

XML wasn't really ever made to be high performance though. It was made to be easy to read for humans and relatively easy to generate. At those two things it i

XML wasn't really ever made to be high performance though. It was made to be easy to read for humans and relatively easy to generate. At those two things it is awesome. If you are sticking binary data in XML and passing it over the wire to someone you are probably 'doing it wrong'. :) There are obviously much fast formats for that type of thing, but they have their own drawbacks which are significant. Protocol Buffers are crazy fast but aren't self describing or human readable. JSON is really just a different representation of XML on many levels and certainly doesn't deal with binary data any more elegantly. (base64 here we come!) If you have binary data and plenty of CPU on both ends, then gzipping XML gets you pretty close to the native size actually and can be a good solution. You keep the human readability and the compression can be done on the transport layer if it is HTTP. If you don't have much CPU and want easy parsing, it is very easy to write a binary format for XML. I've done this for products that are sending down data to cell phones (including images). The native format is XML, because it is easy to author in templates and easy to debug, but with an extra parameter it gets thrown into a denser and very fast to parse format for the other end to deal with. This costs a bit of CPU on the server, but that generally isn't the problem. Anyways, I would agree that the main author's points are pretty ridiculous. They either point to him not really understanding XML or never really considering the pros and cons of the alternatives. XML is great for what it is, and it has its drawbacks, but as a universal transport it is pretty rad.

tentonova 17y ago
There are obviously much fast formats for that type of thing, but they have their own drawbacks which are significant. Protocol Buffers are crazy fast but aren't self describing or human readable. Why does that matter? The fact that they aren't self-describing more or less requires that you use a published message definition, which solves one of the major problems of XML schemas -- nobody actually uses them, and many that do use them incorrectly. XML is great for what it is, and it has its drawbacks, but as a universal transport it is pretty rad. Having wasted far too much of my life on parsing XML documents, I simply can not agree. XML as a universal transport just sucks compared to the modern alternatives.
- nicpottier 17y ago
  Are you pitting XML against Protocol Buffers? Because they are completely different things. Being self describing is a big deal.. it makes interchange far far easier and obvious. As does being human readable, debugging a web API in a browser or via curl is a serious plus. Having just spent the past two days reverse engineering an API that used protocol buffers, I can tell you I would have much rather done it against XML. :) As for parsing, I guess I don't get what the big deal is. I've long since given up on SAX parsers and occasionally use pull parsers, but for the majority of applications using a DOM parser gives you a very OO friendly approach to turning that XML into your objects, and it is dead simple. Sine the generated Protocol Buffer objects are immutable and can't be used as base classes, I suspect the amount of code to turn a 'message' to your domain objects and vice versa is very similar between protocol buffers and a DOM impl. At least it has been in my experience, neither is hard.
  - prodigal_erik 17y ago
    I've never seen value in self-describing or human readable messages. You need some kind of relatively unique identifier for the format of a given message and any optional payload, but beyond that, if a receiver doesn't have any code that knows what to do with a given message, what's the point of being able to deserialize it? And I think debugging an API without making tools is a waste of effort, for the same reason that you use curl rather than typing "POST..." into netcat.
  - tentonova 17y ago
    Having just spent the past two days reverse engineering an API that used protocol buffers, I can tell you I would have much rather done it against XML. Why didn't you have the descriptor files? Optimizing for ease of external reverse engineering seems rather counter to the authoring organization's actual goals. If you want third parties to be able to interoperate, give them the descriptors you use. As for parsing, I guess I don't get what the big deal is. Writing lots of code to read and parse data types as text, especially when no schema is available, is time consuming. Protobuf is necessarily validated. The input types are known-correct, conversion to the domain model is direct and straight-forward, and it's exceptionally easy to generate code or otherwise automatically deserialize to native representations.
elblanco 17y ago
> ... but as a universal transport it is pretty rad I think that's the key point that everybody misses. XML was really just intended to solve the data interoperability and transport problems, not to function as a datastore. It just so happens that once you've made some XML, or received some from somebody, you may as well just deal with it as is rather than XSLT it into your local apps proprietary format (and as it also turns out, it's fairly easy for people to write by hand and debug in simple cases).
haberman 17y ago
> Protocol Buffers are crazy fast but aren't self describing or human readable. Protocol Buffers have a text format that is equivalent to the binary format. Also, XML isn't that much more self-describing than Protocol Buffers. Sure, you can read the tag names in XML, but what is the set of all allowed tag names? What does the stuff inside the tag names actually mean? You have to communicate that stuff somehow, out-of-band, in a spec of some sort. In Protocol Buffer land, a .proto file is just part of that spec.
- nicpottier 17y ago
  They have a text format if someone chooses to share it with you. Saying that protocol buffers have a text format makes about as much sense as saying XML has a binary format. Both are true, but it misses the point. You can get pedantic about needing a spec for everything, but the web isn't really built that way. Do you really track down the full docs for every API you interact with? Say you are just pulling down some information from tumblr via their API or the like? Probably not.. you just throw it in a browser a few times, pull out the fields you need and get on with it. XML lets you do that, quickly and easily and most of the time will work just fine forever more. XML is great for the same reasons HTML is great. It is fast and loose and lets you so easily introspect APIs that you can get your work done quickly.
  - haberman 17y ago
    There are times when the text format for protocol buffers can be very useful. For example, you could use the text version during development if you wanted human-readability. If I was pulling some information from Tumblr, I would at least read the introductory API docs at http://www.tumblr.com/docs/api http://www.tumblr.com/docs/api (if you didn't do that, how would you even know what URL to hit?). If they were using Protocol Buffers, they would publish their .proto file on that page. In fact that page reads very much like an informally-specified .proto file; it contains a list of all the parameters and what they all mean.

tentonova 17y ago

There are obviously much fast formats for that type of thing, but they have their own drawbacks which are significant. Protocol Buffers are crazy fast but aren't self describing or human readable. Why does that matter? The fact that they aren't self-describing more or less requires that you use a published message definition, which solves one of the major problems of XML schemas -- nobody actually uses them, and many that do use them incorrectly. XML is great for what it is, and it has its drawbacks, but as a universal transport it is pretty rad. Having wasted far too much of my life on parsing XML documents, I simply can not agree. XML as a universal transport just sucks compared to the modern alternatives.

nicpottier 17y ago
Are you pitting XML against Protocol Buffers? Because they are completely different things. Being self describing is a big deal.. it makes interchange far far easier and obvious. As does being human readable, debugging a web API in a browser or via curl is a serious plus. Having just spent the past two days reverse engineering an API that used protocol buffers, I can tell you I would have much rather done it against XML. :) As for parsing, I guess I don't get what the big deal is. I've long since given up on SAX parsers and occasionally use pull parsers, but for the majority of applications using a DOM parser gives you a very OO friendly approach to turning that XML into your objects, and it is dead simple. Sine the generated Protocol Buffer objects are immutable and can't be used as base classes, I suspect the amount of code to turn a 'message' to your domain objects and vice versa is very similar between protocol buffers and a DOM impl. At least it has been in my experience, neither is hard.
- prodigal_erik 17y ago
  I've never seen value in self-describing or human readable messages. You need some kind of relatively unique identifier for the format of a given message and any optional payload, but beyond that, if a receiver doesn't have any code that knows what to do with a given message, what's the point of being able to deserialize it? And I think debugging an API without making tools is a waste of effort, for the same reason that you use curl rather than typing "POST..." into netcat.
- tentonova 17y ago
  Having just spent the past two days reverse engineering an API that used protocol buffers, I can tell you I would have much rather done it against XML. Why didn't you have the descriptor files? Optimizing for ease of external reverse engineering seems rather counter to the authoring organization's actual goals. If you want third parties to be able to interoperate, give them the descriptors you use. As for parsing, I guess I don't get what the big deal is. Writing lots of code to read and parse data types as text, especially when no schema is available, is time consuming. Protobuf is necessarily validated. The input types are known-correct, conversion to the domain model is direct and straight-forward, and it's exceptionally easy to generate code or otherwise automatically deserialize to native representations.

elblanco 17y ago

> ... but as a universal transport it is pretty rad I think that's the key point that everybody misses. XML was really just intended to solve the data interoperability and transport problems, not to function as a datastore. It just so happens that once you've made some XML, or received some from somebody, you may as well just deal with it as is rather than XSLT it into your local apps proprietary format (and as it also turns out, it's fairly easy for people to write by hand and debug in simple cases).

haberman 17y ago

> Protocol Buffers are crazy fast but aren't self describing or human readable. Protocol Buffers have a text format that is equivalent to the binary format. Also, XML isn't that much more self-describing than Protocol Buffers. Sure, you can read the tag names in XML, but what is the set of all allowed tag names? What does the stuff inside the tag names actually mean? You have to communicate that stuff somehow, out-of-band, in a spec of some sort. In Protocol Buffer land, a .proto file is just part of that spec.

nicpottier 17y ago
They have a text format if someone chooses to share it with you. Saying that protocol buffers have a text format makes about as much sense as saying XML has a binary format. Both are true, but it misses the point. You can get pedantic about needing a spec for everything, but the web isn't really built that way. Do you really track down the full docs for every API you interact with? Say you are just pulling down some information from tumblr via their API or the like? Probably not.. you just throw it in a browser a few times, pull out the fields you need and get on with it. XML lets you do that, quickly and easily and most of the time will work just fine forever more. XML is great for the same reasons HTML is great. It is fast and loose and lets you so easily introspect APIs that you can get your work done quickly.
- haberman 17y ago
  There are times when the text format for protocol buffers can be very useful. For example, you could use the text version during development if you wanted human-readability. If I was pulling some information from Tumblr, I would at least read the introductory API docs at http://www.tumblr.com/docs/api http://www.tumblr.com/docs/api (if you didn't do that, how would you even know what URL to hit?). If they were using Protocol Buffers, they would publish their .proto file on that page. In fact that page reads very much like an informally-specified .proto file; it contains a list of all the parameters and what they all mean.