Here's my understanding of the general idea (let me know if I got something wrong!). Say you have a bunch of computers with different software and hardware. You come up with a cool new image format called "PJEG". To get the images to show up on all the computers, you typically do the following:
* Publish a PJEG spec
* Define a .pjeg extension and let everyone know that means it's
a PJEG file
* Write a PJEG encoder/viewer for each kind of computer
* Distribute these programs to the computers
* Configure the computers to open .pjeg files using the programs
you distributed
* Modify other programs (image editors, web browsers) so they
can recognize, encode and view PJEG files as well
* etc...
This approach doesn't scale very well. I think the alternative Alan is suggesting is that you'd include an interpretable description of the file format in the file itself in a sort of meta-format. Once you have an interpreter for these meta-format descriptions, all you'd have to do is:
* Include an interpretable PJEG encoder/viewer with every PJEG file
And that's all! Any program able to read the meta-format could use this file without any extra software. This obviates file type metadata and reduces the amount of distribution you need to do, making the whole thing way more scalable. The practical problems with this solution (larger file size, slow encoding and decoding) can be solved in various ways:
* The larger file size can be mitigated by format negotiation
(if I already know about the format, you don't have to tell
me about it)
* Optimized encoders and decoders can be written to replace the
slower interpreted ones included with the file
Having the interpreted format description makes it easier to validate the optimized version, too (you can generate a bunch of random examples and make sure they decode/encode the same way). And this doesn't have to just be for files, you can use the same technique for arbitrary "data types" in your program as well.