I've worked with Will on a large XML based system. I'll try to briefly describe our workflow. Our company created reference books. Those books ended up both a

I've worked with Will on a large XML based system. I'll try to briefly describe our workflow. Our company created reference books. Those books ended up both as printed books and as HTML in a web application service people could subscribe too. Various people would create the content, some in WYSIWIG editors, others editing raw html to tag content to give it structure, and tools that fall somewhat in between. XML tags and annotations can do things like indicate where the title is, sub headings, links to other books or content. etc etc. This annotation structure not only lets us transform the xml into HTML that resembles the physical book via CSS, but also lets us search the content with awareness of what the content is. Simple example, if a search term appears in a title give it more weight. When a book is done the XML goes off to a printer to become a book, AND into our XML database. A nice feature of which is a lot of our content is in the DB as XML, you ask for a book page and the DB returns the HTML for the page, backend just forwards that HTML to the browser which displays it. ZERO parsing/transformation anywhere once the DB sends it! Just fling the payload at the browser. Super cool at times. Anyway we all work with these formats differently, some of us never touch the json and xml, some of us only tweak values in config files. Those of us who work with it like that, the only differences between XML and JSON are "how nice are the serialization apis and how fast are they? how big is the payload?" But when working WITH the format directly there can be more meaningful differences. And the tools that actually exist for the things you are doing may push you towards one format or the other, even if in principle it wouldn't have really mattered. note: I keep mixing tenses here but this was all in the past, we got bought, don't do any of this anymore!