This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Infoset Thoughts

Stefan Tilkov,

This sounds suspiciously like attempting to invent some kind of meta-XML.

To make matters more complex it’s pretty obvious to us that we need to have support for multiple data serializations. At a minimum we think we have to support XML and JSON but following the old computer science rule that there are only three numbers “0, 1 and infinity” this means we will eventually have to support more.

It seems to me that the need for having to support both JSON and XML is not at all obvious, so this looks like starting from a false premise. But then again, Yaron Goland is an extremely smart guy, so maybe I’m missing something.

On August 10, 2006 7:30 PM, Yaron Y. Goland said:

In the case of Live our services have different consumers. We have two major targets though. One target are web page based experiences. Ideally we want our services to be directly consumed by the web page itself which makes JSON ideal. Speaking from recent experience consuming XML in Javascript is a nightmarish experience. JSON makes receiving and processing message content trivial. So we are certain we want to do JSON.

Our other target are server to server communication. Ideally we would use JSON there as well (that would be my preference) but the customer base (it is our belief, maybe we are wrong?) is very comfortable with XML (no matter how much it sucks) so we feel we have to provide a XML interface as well.

There are other interfaces to our services I also expect to see show up, for example, ATOM and RSS. Even though those are largely XML based they have their own effective data models that we have to map into. XML is just their serialization format. But the real action is at the data model level.

So very quickly we find ourselves with business reasons for having to support multiple different infosets/data models. So this forces us to come up with something that works across all of the choices. I don’t imagine our system is universal and I don’t imagine it will hold up forever (E.g. eventually the cost of tunneling and such will make us re-evaluate) but given our belief that we can’t just force a single format (e.g. JSON) on everyone we have to do something.

It’s worth pointing out, though, that if you look at the infoset I described it looks more than a little like JSON. That isn’t an accident.