That is a very interesting take!
Adding to that line of thinking: obviously we need the textual representation for reading - so we need something to translate it. That situation is kind of dual to programming languages and compilers - we use compilers to make the textual representation machine readable, here we need a decompiler to make the machine readable data textual.
But if you start from a programming language, it surely do have something to describe data structures. That would already be unambiguous. That is why JSON is useful.
So just use protobuf/thrift as the payload, problem solved.
protobuf still requires a schema to distinguish between 1 and true.
Their example of asn.1 also needs a schema.
No, ASN.1 has separate boolean, integer, and enumeration types, as well as separate "printable string" and "octet sequence" types.
Yes, which makes it a schema
OK, then what term would you like me to use to mean "the thing protobuf uses to define messages, commonly called a schema, that lives outside the encoded data itself"? The point is that ASN.1 can do certain things without it which protobuf cannot.
Two functions applied on input (Trim and ToLower in C#) solve all the examples you listed and any similar cases. Yes and no are obviously very different from true and false.
Re:Robust APIs Are Weird
by adrianmsmith on Saturday June 20, 2020 @05:44AM
(#23582901)
> Yes and no are obviously very different from true and false.
The text-based language YAML allows “yes” and “no” for Boolean in addition to “true” and “false”. So if multiple bright people think about this topic they’ll evidently come up with different approaches. Not so with a single bit.
[1]I guess if you really stretch things, you can say 1 is false and 0 is true, and I have actually seen that before, but I can't think of any other ambiguities a single bit could have.