TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

69 pointsby begoonover 2 years ago

15 comments

remramover 2 years ago
This seems unnecessarily terse. If you want types, why not make it look like one of the existing popular languages with types? (Rust&#x2F;TypeScript&#x2F;protobuf)<p>Instead of:<p><pre><code> 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 &lt;Tom Preston-Werner&gt; (DateTime 1979-05-27T07:32:00 &lt;-08:00&gt;)) (Database &lt;192.168.1.1&gt; [8000 8001 8002] 5000 yes) (Hosts &lt;alpha&gt; &lt;omega&gt;) ] </code></pre> Why not:<p><pre><code> 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(&#x27;Tom Preston-Werner&#x27;, DateTime(&#x27;1979-05-27T07:32:00&#x27;, &#x27;-08:00&#x27;)), Database(&#x27;192.168.1.1&#x27;, [8000, 8001, 8002], 5000, yes), [ Hosts(&#x27;alpha&#x27;), Hosts(&#x27;omega&#x27;), ], ] </code></pre> Evidence shows that people like that kind of format, for &quot;plain text human readable&quot; purposes. They are also used to it. It&#x27;s only 20% longer, and you can also go with a Haskell-style syntax if you dislike braces.<p>What&#x27;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)?
评论 #33206361 未加载
评论 #33212854 未加载
评论 #33207184 未加载
kardianosover 2 years ago
This format does a lot of things correctly conceptually, in my opinion.<p>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&#x2F;encode.<p>Unlike lists of JSON objects, the data can be represented more compactly. I&#x27;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.<p>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.<p>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.<p>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.<p>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).
评论 #33205713 未加载
OJFordover 2 years ago
That&#x27;s human-readable is it? Personally I find the TOML example far easier to read, it doesn&#x27;t seem to be spelt out what the &#x27;advantage&#x27; is in translating to UXF; I think maybe that it supports custom types? A comparison to Recfiles (which do) would be nice then.<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Recfiles" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Recfiles</a><p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;recutils&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;recutils&#x2F;</a>
评论 #33203704 未加载
评论 #33216616 未加载
coffeeblackover 2 years ago
&gt; Use no for false and yes for true.<p>Wouldn’t it be better to use true for true and false for false?
评论 #33203671 未加载
评论 #33208169 未加载
derekzhouzhenover 2 years ago
I fail to see why should I prefer this over JSON. Dynamically typed languages prefer plain hash tables. Static typed languages need to parse and validate input data anyway, so the lack of type of JSON is not a hindrance.<p>Maybe for communication between trusted parties? Then I would use a binary format.
littleblueplantover 2 years ago
I really fail to see the point of this format.<p>If human readability was the point, then doing something different than expected is a really bad idea:<p>* &quot;no&quot; and &quot;yes&quot; as boolean values may save some bytes, but the tradeoff isn&#x27;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 &lt; and &gt; in the value. * The format isn&#x27;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.<p>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.<p>UXF is self contained, that&#x27;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.<p>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&#x27;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).
jackricover 2 years ago
I&#x27;m not going to write this by hand. So what&#x27;s the advantage over schema&#x27;d XML?
unwindover 2 years ago
Pretty cool I guess, although there sure are a lot of such formats now ... but I like the typed-ness.<p>I feel the spec warranted more discussion about why strings &lt;look like this&gt; instead of the way more common &quot;like this&quot;, i.e. why angle brackets are used to quote strings. <i>Probably</i> to make it easier to embed quotes, but I&#x27;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.
评论 #33206991 未加载
评论 #33203409 未加载
efitzover 2 years ago
Can we just add a version indicator, an ISO8601 datetime type and some kind of constraint (regex or BNF) for existing types to JSON and call it done?
评论 #33207048 未加载
tlockeover 2 years ago
Likewise, I had a go at trying to improve on JSON and this is my attempt:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;tlocke&#x2F;zish" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tlocke&#x2F;zish</a><p>Any comments &#x2F; criticisms gratefully received.
评论 #33205772 未加载
neycmrtnover 2 years ago
Arghhh.. this name collides with our tool UMLet&#x27;s &quot;UML XML Format&quot; extension &quot;.uxf&quot;, in ubiquitous use since 2001! :)
评论 #33206242 未加载
auroralimonover 2 years ago
no time zones on date&#x2F;&amp;times? they should be added.
评论 #33203345 未加载
评论 #33203055 未加载
评论 #33203358 未加载
评论 #33207156 未加载
compressedgasover 2 years ago
Slightly reminded me of Carousel the format that PDFs are written in.
hikapaover 2 years ago
smart, although the use of &gt;&lt; for strings makes it stand out compared to less noisy formats like yaml imo also, doesn&#x27;t some of the custom typed map syntax overlap with an untyped map one? thanks
mwcremerover 2 years ago
Obligatory: <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>