File formats
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Consideration of lazy errors—error messages that are vague suggestions of possible causes that the computer could have determined for itself—leads to an important system requirement: standardisation of file formats. Although many file formats are already defined, new file formats should adhere to a common internal structure (e.g. XML or JSON for file formats that are largely text-based). The application should provide a schema for each type that it uses within its package, allowing the procesesing of file contents be provided by the operating system instead of the application. The importance of this is twofold: simply developer workload by not needing to create and manage ad-hoc text and binary files, and to centralise the error handling for such files. Centralised error handling means that format validation is no longer the application’s responsibility and thus it can be implemented once and correctly; this will prevent vague and meaningless errors coming from applications that don’t check their file types properly.