Live data from Hacker News

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

github.com

11–20 of 62 posts

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

#12

> Use no for false and yes for true. Wouldn’t it be better to use true for true and false for false?

Could you please elaborate? Why is true a better value than yes? Seems like an arbitrary choice to me. Does one choice have some advantages over the other?

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

#13
post #9

That's human-readable is it? Personally I find the TOML example far easier to read, it doesn't seem to be spelt out what the 'advantage' is in translating to UXF; I think maybe that it supports custom types? A comparison to Recfiles (which do) would be nice then. https://en.wikipedia.org/wiki/Recfiles https://www.gnu.org/software/recutils/

I think toml is optimized for reading/writing by humans, while this is primarily exchange format. So readability is not too much of an concern. Seems like a compromise between JSON and protobuf

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

#14
post #12

> Use no for false and yes for true. Wouldn’t it be better to use true for true and false for false?

Could you please elaborate? Why is true a better value than yes? Seems like an arbitrary choice to me. Does one choice have some advantages over the other?

What fraction of existing code uses languages with true/false vs yes/no? I’d imagine it should be “least surprising” for most users.

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

#15
post #6

no time zones on date/&times? they should be added.

No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.

What timezone do you assume the source datetime is in?

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

#16
post #15
post #6

Earlier quoted context omitted.

No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.

What timezone do you assume the source datetime is in?

UTC, of course: the only sensible timezone to store date and time in.

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

#17
This format does a lot of things correctly conceptually, in my opinion.

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).

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

#18
post #15
post #6

Earlier quoted context omitted.

No time zones ever. If I see a date and its X, I know that I only need to add y to get my timezone to know when this happened. but if anybody puts a timezone there, now I can't do it mentally.

What timezone do you assume the source datetime is in?

If you're most Americans, EST. If you're Apple, PST. If you're a technical person, UTC.

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

#20
post #12

> Use no for false and yes for true. Wouldn’t it be better to use true for true and false for false?

Could you please elaborate? Why is true a better value than yes? Seems like an arbitrary choice to me. Does one choice have some advantages over the other?

True/false is more widely used than yes/no in this context. The fact that the author felt the need to explain that yes/no maps to true/false indicates that they also believe this to be the case.

The only time I can remember seeing yes/no used in a format like this is YAML, and that caused problems[1].

[1]: https://hitchdev.com/strictyaml/why/implicit-typing-removed/

Post reply on HN