First up, serializations don’t matter unless you are trying to read them like a story — or you’re doing bulk transfers that are likely to get interrupted. Or you have speed issues.

I have an in-memory model that I want to express in some serialization. I create a tool that takes my model and creates the serialization I want from my model. You might want to see the serialization and think that this is the model, but it isn’t because the model is abstract. If you struggle to grasp this, I’m told this is normal, then fine, but don’t argue about serialization X being better than serialization Y. That doesn’t make sense.

It doesn’t make sense because it isn’t qualified in any way: these make sense:

  • X is a better serialization for transfer than Y because it supports line-by-line transfer
  • X is a better serialization for representing information encoded in acyclic graphs than Y because it supports acyclic graphs
  • X is a better serialization for human reading than Y because it is relatively human readable

Most serializations are deliberately compact and support complexity beyond the understanding of people who are not directly familiar with the serialization specification because serialization are designed to carry content from many different sources that contain many different structures.

If it is the case that you want a human readable version, look for that. It’s worth mentioning that  what counts as “human readable” varies in my experience from human to human, so any strong claim in this respect is built on rather shaky foundations. That said, in the absolute majority of cases, you’re not interested in a concrete manifestation of a model, but the abstract model — what is represented and more pertinently “why”. So perhaps looking for the human readable version isn’t where you need to start…

A final — and for me the most curious  — statement people often utter is:

  • Serialization X is more developer-friendly than Y

This is only the case where developers don’t have access to a proper parser for a serialization. It can also be the case that developers are more familiar with, or prefer a serialization, but these are soft benefits; developers tend to like APIs that deliver the goods irrespective of serializations, rather than rubbish data from APIs that come in their favourite flavour.

It can also be the case that the data itself is badly documented, but the serialization can hardly be blamed for that.


Posted in Uncategorized
One comment on “Serializations
  1. One can replace “serialization” with any of “(data) format”, “(formal) language”, and “encoding”. This may help to understand the buzz and discussion about serializations. Its much more difficult and important to talk about mental models although in the end this is what everybody cares about.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s