Hacker News Reader

Comment by enord | Hacker News Reader

It's not about human readability, it's about separating implementation from representation, so "readable without any software" is a good test for wether it's "readable with any sfotware".

If your document editor represents documents as a stack of edit-events (for undo/redo or whatever) and you document every nook and cranny of this "document format", standardize it as "binary event-sourced document format, .esd" then your binary spec will be very close to a full description of your document editor. Everyone who wants to use your format now has to reimplement your editor.

Anyone can leak implementation details into any format, and it is to some extent unavoidable, but if you can make it readable (or semi-readable), some thought has at least been put into the representation.

View on HN

>It's not about human readability, it's about separating implementation from representation

No, it's not. An sqlite-based document can have as many representations as an XML-based document -- nothing in its implementation prevents this.

>so "readable without any software" is a good test for wether it's "readable with any sfotware"

The OS, filesystem, shell, editor etc needed to read the XML file are still software.

As is the XML parser needed to do anything useful with it in the data realm.

>If your document editor represents documents as a stack of edit-events (for undo/redo or whatever) and you document every nook and cranny of this "document format", standardize it as "binary event-sourced document format, .esd" then your binary spec will be very close to a full description of your document editor. Everyone who wants to use your format now has to reimplement your editor.

You do understand that the XML file can also just be including a stack of edit-events, right?

This is totally orthogonal to the underlying storage (XML or sqlite or whatever).

> so "readable without any software" is a good test for wether it's "readable with any sfotware"

What an extraordinarily stupid notion. Your filesystem is not readable without a filesystem driver for the specific binary format used to represent it, so you cannot even read your text file without having something in your stack that understands a more structured data organization scheme.

> Your filesystem is not readable without a filesystem driver for the specific binary format used to represent it, so you cannot even read your text file without having something in your stack that understands a more structured data organization scheme.

This argument doesn't hold water, since file content doesn't depend on which filesystem it's on.

An archiver may choose to store data in some very particular way, like some specific tape driver. They're free to do that without corrupting the content of any files, since the files don't depend on the filesystem.

On the other hand, if an archiver chose to store, say, unzipped versions of their opendocument files, then they've corrupted the data: opendocument files are zips, unzipped data is not opendocument. The format does depend on the file content.

Yes, but that comes with the operating system that comes with the computer i bought and use in the house which comes with electricity from the electrical grid in the city that lies in an aerated valley (luckily!) on the third planet from the sun. I should have added a disclaimer i guess.

Just to point out... SQLite comes built it to pretty much every OS these days too. :)

Reply on news.ycombinator.com