Laying the foundations for the data model
________________________________________________________________________________


Note: this article is part of the "Building a graphical multi-user spreadsheet
editor in Zig" series. Read all the articles here.

The design process was: uses -> data model -> file format and encoding (where
each arrow means "determine"). So let's get started!


-- [001] Uses ------------------------------------------------------------------

What are the legitimate uses for spreadsheets? Are there any? Does mixing data
and computing logic even make sense? To be honest, I'm pretty sure that using
them for anything other than specific, one-time tasks is a bad idea. Still, I do
believe spreadsheets are a rather unique computing engine.

Then, what am I reaching for when I fire up a spreadsheet editor?
* being able to build the computing logic in small steps, each cell doing a
  little part of the job and displaying its value at any time (which is perfect
  for instant feedback and debug)
* using formula patterns to define whole areas of cells at once
* using conditionnal formatting to draw my attention to specific cells

The data model should target this use.


-- [002] Data model ------------------------------------------------------------

A spreadsheet file is a set of definitions and metadata (such as sheet names).

Each definition is:
* an application area (possibly only one cell), including sheet identifier,
* an optionnal content: a formula or a literal (bool, float, integer or string),
* an optionnal conditionnal emphasis rule, and
* an optionnal format if content is a float or an integer (percent/currency/
  datetime/hex/binary...).


-- [003] File format and encoding ----------------------------------------------

I want grid to be a good UNIX citizen, that interoperates well with other tools.
I have command-line scriptability and .csv-awareness in mind, but the most
important point is the use of a textual file format.

Plain text unties the data from the tool. It allows the use of any text editor
or UNIX tool (grep, sed, piping...). It allows version control. Plain text is
power for everyone.

The encoding of data as text should:
* be designed according to the data model
* be stable and clearly documented (to not break other tools that might use it)
* be easy to parse and emit (and especially make it easy to discard malicious
  data when parsing)
* have a good readability/compactness ratio (more verbosity for easy parsing
  should be preferred over compactness)
* aim to produce small changes in encoded data given small changes in data, so
  that only meaningful changes appear in version control systems

The details of the encoding are not ready yet.