Live data from Hacker News

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

github.com

1–10 of 62 posts

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

#2
Pretty cool I guess, although there sure are a lot of such formats now ... but I like the typed-ness.

I feel the spec warranted more discussion about why strings 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.

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

#4

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

Especially on the timestamps, I find some of the design choices a little bit bizarre. Choosing only a strict ISO8601 format: awesome! Choosing to excise critical parts (representing timezones and fractional seconds): very unfortunate.

Chesterson's Fence (https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_... is a very powerful design principle. They chose to put those elements into ISO 8601 for principled reasons: they come from pain. They embody responses to mistakes that I've made, and thousands of other engineers before me. Unless we fully understand the reason they were included, don't arbitrarily to do "I haven't used it, so it must be useless."

Other than that, it looks like a clean spec, but I'm not personally convinced that it has enough incremental value over JSON or YAML to replace them in the human-readable exchange format space. It can be a little more concise, but if I'm making something for humans, clarity (typically) has more value than conciseness. Are there other compelling values that I'm missing?

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

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

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

#7

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

Does seem a surprising omission. I’d expect offset support, and like more recent fancier draft stuff from https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e..., Internet Extended Date/Time Format, where you can specify a named time zone rather than just an offset.

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

#8
post #2

Pretty cool I guess, although there sure are a lot of such formats now ... but I like the typed-ness. I feel the spec warranted more discussion about why strings 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…

Maybe poor-man’s («») for (as you say) nesting strings.

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

#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/

Post reply on HN