Uniform eXchange Format (UXF) – plain text human readable typed storage format

Instead of:

    uxf 1
    =Database server:str ports:list connection_max:int enabled:bool
    =DateTime when:datetime tz:str
    =Owner name:str dob:DateTime
    =Hosts name:str
    [
      (Owner <Tom Preston-Werner> (DateTime 1979-05-27T07:32:00 <-08:00>))
      (Database <192.168.1.1> [8000 8001 8002] 5000 yes)
      (Hosts
        <alpha>
        <omega>)
    ]

    type Database {
      server: str,
      ports: list,
      connection_max: int,
      enabled: bool,
    }
    type DateTime {
      when: datetime,
      tz: str,
    }
    type Owner {
      name: str,
      dob: DateTime,
    }
    type Hosts {
      name: str,
    }

    [
      Owner('Tom Preston-Werner', DateTime('1979-05-27T07:32:00', '-08:00')),
      Database('192.168.1.1', [8000, 8001, 8002], 5000, yes),
      [
        Hosts('alpha'),
        Hosts('omega'),
      ],
    ]

What's the point of a plain-text format that is not human-friendly? Especially for type definitions, do you expect people to write this or do you want them to compile their schema from a different human-readable format into your human readable-format (and why)?

1. It supports data tables with named and typed columns. 2. It supports types in the header that can be referenced elsewhere. 3. It supports lists of stuff as well as types and nesting. 4. It uses a format header to easily declare what format to decode/encode.

Unlike lists of JSON objects, the data can be represented more compactly. I've done something similar when I encode tables as an array of header names, then each row is also an array, where index is used to match the name.

It would be fairly easy to make a binary version of this if you needed more compact representation, and make a lossless conversion between text and binary.

Why would you want a format like this? Many use cases. Every DB wire protocol essentially re-creates something like this, but often poorly. Writing multiple tables that include headers and types as well as data to disk is frequently useful.

The problem with xml schema is XML is really really complex when you add in transforms and namespaces and everything else that XML can include.

The only thing I might suggest is to be able to add meta-data about a specific type, or create specialized type based on type+meta-data (like max length, etc). This could also help with the issue of timestamps (local, second resolution, offset).

https://en.wikipedia.org/wiki/Recfiles

https://www.gnu.org/software/recutils/

Wouldn’t it be better to use true for true and false for false?

Maybe for communication between trusted parties? Then I would use a binary format.

If human readability was the point, then doing something different than expected is a really bad idea:

* "no" and "yes" as boolean values may save some bytes, but the tradeoff isn't worth it (and if filesize matters, use a binary format to begin with). * Using angle braces except of double quotes to fence strings makes the format look noisy and means you have to remember two kinds of escapes if you want to use < and > in the value. * The format isn't object oriented in any way. You can simulate that by putting maps into maps, of course, but no one will have fun reading or writing that in a text editor.

Type information is for parsers, not humans. JSON this this right, Protobuf does this right. UXF is just a compromise combining (only) the disadvantages of the two.

UXF is self contained, that's great, but in 99.9% of the cases where you need a DX format, sender and receiver already know the schema, so that definition block just adds bloat.

You can happily mix lists, maps and tables of primitive or compound types. And since stuff is typed instead of named, order matters and you end up addressing everything through positional parameters. That's going to be fun when using a text editor to write down something like a list of GPS coordinates (you are likely to confuse latitude and longitude).

I feel the spec warranted more discussion about why strings <look like this> instead of the way more common "like this", i.e. why angle brackets are used to quote strings. Probably to make it easier to embed quotes, but I'm not sure. It was rather surprising at least, although I guess you get used to it if you read a lot of raw files.

https://github.com/tlocke/zish

Any comments / criticisms gratefully received.