AKAImBatman's Journal: The Intelligent File Format

Today's systems have hundreds of file formats they must support. Wouldn't it be great if we could reduce all the file formats in existence down to a single file format that could be supported across all systems?

My latest three-part article addresses this concept: The Intelligent File Format

If such a concept could be made into a standard, pressure could be put onto Microsoft and other large companies to support the format or lose massive government business. (See the recent pushes for the Open Document Format for a very real example of how this can work.)

I'd love to hear your thoughts and opinions.

Image File Format

[Shadow Wrought]

When I saw "Intelligent File Format" my first thought was IFF- Amiga's Image File Format. Guess that kinda proves the point, no?

Re:Image File Format

[AKAImBatman]

Indeed. I was actually a bit worried that the "generic" IFF [wikipedia.org] format would be the first thing that everyone would think of, but decided that it was really an obscure piece of knowledge at this point. It hadn't occurred to me that the ILBM [wikipedia.org] subset would pop into people's heads as well.

Too bad I'd written nearly the entire article by the time I realized the similarities in both name and function. Oh well. ;-)

So...

[nacturation]

Didn't RTFA (of course), but it sounds like you're suggesting a binary version of XML?
 

Re:So...

[AKAImBatman]

I suggest you read the article then. This is far more comprehensive than the Interchange File Format [wikipedia.org].

moof

[Bill Dog]

You could do this for the major types of information the bytes of files represent to us. An example, expressed in I guess MS COM-like terms:

Say every driver that wrapped a file format had to support the following interface:

InformationType ::getTypeCategory()

A video file's driver would return the GUID for TYPE_VIDEO.

Then you'd know you could successfully call:

IVideo ::getVideoInterface()

IFrameIterator IVideo::getFrameIterator()

Re:moof

[AKAImBatman]

You've got the basic idea. :-)

The key is that a spreadsheet knows what spreadsheet information is and really only needs access to it. Similarly, a video player only needs the next frame of animation. It doesn't care about how it's compressed or how it's stored. With some types of files (e.g. Images), returning the standard Java object would pretty much make all the interfaces 100% compatible with each other. The more complex situations (such as spreadsheets with different features) would merely require that

Re:moof

[Bill Dog]

Someone could examine MS's API for accessing an Excel document's data through COM, for an idea of the kinds of things a common ISpreadsheet interface should contend with. But ISpreadsheet would be vastly different, not just larger and more complicated, than IVideo. So how could you "pretty much make all the interfaces 100% compatible with each other"? I.e. they're completely different interpretations of a file's byte sequence. You don't have an is-a relationship there. There is no/can be no lowest-common-de

Re:moof

[AKAImBatman]

You're stuck on the idea of one program to all file formats. I'm not saying that at all. I'm saying that there are common categories of programs that are forced to deal with different formats. There's no "one" graphics format because each format has certain advantages over other formats. (e.g. JPG is excellent for photographs, but poor for drawings.) Yet these different formats each produce the same data: An array of pixels. The problem is that it's quite difficult to write support in your program for all t

Re:moof

[Bill Dog]

We're saying the same thing -- categories of file types can be handled the same way for that category. I thought you originally were suggesting that all categories could be handled the same way.