I'm sorry, where is the article did you read the suggestion that the format should stop using XML? I can't find any such suggestion. Looking at the other comments here it looks like the author must have recommended ditching XML completely, but the actual article doesn't seem to bear that up. Has it been radically altered since being posted to HN? The disconnect between the pro-XML arguments here and the actual article's assumption of continuing to use XML is really quite jarring.
The nearest I can find is where it suggests breaking up the XML into smaller XML documents, but that's a whole heck of a long way away from being the same thing.
Im not even talking about the data model. The manifest would be replaced, all resources wouldn’t have usable URIs, you couldn’t deserialise a stream using sax easily, dtd and schema references that ship with it would be invalidated.
Those are all XML too. It’s not just markup.
It turns a bundle of files with strict relations into an unworkable stateful blob of loose links. Welcome to the world of corruption at the application layer.
I would hardly call a system such as the one proposed corruption.
Ok, so maybe this proposal might make the format a little harder to access programatically, but it's a pretty minor effect. You just need to extract the data from a SQLite DB instead of a zip file. You could even store a manifest in the DB as well.
I think the thing I object to about all the criticism here is that it's all about making things easy and simple and pure from a development point of view. The article proposes concrete end user benefits from a scheme like this, which to me seem pretty worthwhile. Surely the focus should be on the user experience first and then look at how to implement that?
Zipped XML actually allows us to parse and manipulate it easily with a strongly defined schema. SQLite can barely enforce any consistency.
As for XML it’s actually pretty marvellous. Most people don’t understand it which is where the problem is.