Thanks for that, though I suspect developers aren't the only user-community for documents ;-)

If I can paraphrase your statement about files: they solve a technical problem in computer space, but don't reflect how people want to and/or need to access information.

I'm reminded somewhat of mainframe DASD storage, which has a few characteristics:

- A largely flat directory structure. There can be directory equivalents, but to a limited depth (1 or 3 maximum IIRC, possibly depending on OS release).

- Structured files. That is, the concept of a "flat file" or a "binary file" doesn't exist (or is rarely used), rather files are specifically structured, into records (~= lines or rows) and fields (~= individual values), with a record type indicator as the first few bytes of each record. A file could contain (and most often did) multiple different record types, as a hierarchical data file.

- Specific programmes to read each file type.

(At one point I worked in writing code to read data files, including IBM mainframe files. That was many moons ago and much of the work was not on IBM mainframes themselves, though some was. I've suppressed much of the trauma....)

These days we tend to use an RDMBS database structured as rectangular tables with columns and rows (also invented at IBM, and available on mainframes, though not often part of my previous life).

Funny thing: SQL was originally pitched as a query language that could be taught to secretaries and administrative staff to directly run queries against databases. Either admin staff were much more brilliant then, or that was an ambitious vision....

Or ... we have various structured data formats that aren't rectangular: XML, JSON, HTML itself, amongst others. These have a structure and can be picked apart, though they're still fairly complex.

What I've seen over a career of 30+ years is that the vision of some single universal data format keeps getting pitched ... and keeps not materialising. Because Reasons a specific application has its own needs, and/or the "standard" is so complex that it is never implemented the same way twice. Data interchange always needs to be specifically structured and engineered.

For mostly-textual information, which is where I think of tagged systems being most appropriate, the internal structure of documents is ... fairly loose. Metadata + bag of bits, mostly ASCII / Unicode. But that still leaves us with the problem of sorting out what's where and how to access it.

I'd argue that most present filesystems are inadequate to the task of and by themselves, though they might be extended. An interesting and fairly simple example is the maildir format for storing email. It lives on a standard filesystem, and its naming convention is opaque (email message IDs). The file structure itself, based off RFC 822/2822, includes a set of defined and structured fields (headers) providing metadata. A special access program, a mail reader, provides access to the mailbox(es), though other tools can provide more programmatic process. Principle organisation is by data, though other metadata aspects can be used.

As a rough proxy of what a document store might look like ... this isn't a completely bad start, and it might offer guidance to how a more generalised document-oriented filesystem might be structured.