Wouldn’t it be better to use true for true and false for false?
Uniform eXchange Format (UXF) – plain text human readable typed storage format
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?
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#13That'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/
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#14> 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
#15no time zones on date/×? 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
#16Earlier 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?
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#171. 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
#18Earlier 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?
Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#19Re: Uniform eXchange Format (UXF) – plain text human readable typed storage format
#20> 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?
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/