Earlier quoted context omitted.
And there you go, just `[]` is no longer valid, so you need a new format.
If you need a schema for [] you have lost the plot.
[deleted]
TSON – A JSON superset with immutable, hash-pinned schemas
61–68 of 68 posts
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#62Earlier quoted context omitted.
And there you go, just `[]` is no longer valid, so you need a new format.
If you need a schema for [] you have lost the plot.
Are you serious? Do you honestly think that I am talking about a schema for passing empty lists around?
If you are passing around lists of structured objects, I need you to send me what those objects are supposed to look like even if the list is empty sometimes. If you say "ok so sometimes I'll give you an object with a schema key and a list of data, other times I will just give you an empty list because I don't feel like it", everyone will hate you.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#63Earlier quoted context omitted.
If you need a schema for [] you have lost the plot.
Are you serious? Do you honestly think that I am talking about a schema for passing empty lists around? If you are passing around lists of structured objects, I need you to send me what those objects are supposed to look like even if the list is empty sometimes. If you say "ok so sometimes I'll give you an object with a schema key and a list of data, other times I will just give you an empty list because I don't feel…
I assumed you meant empty list because that made sense. What you said here does not make sense.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#64why can't you use hash pinned schemas with existing json? Why do you need a new format for it?
Here's some json: [] How do you add schema info to that?
If you need to embed the schema in the document, Don't design your schema in way that makes it impossible to embed the schema in the document.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#65you can just add schema to json why add new syntax now, especially for json I dont think it makes sense I honestly believe the war is over there won't be a xml to json moment unless we move to a new platform other than browsers which seem rather unlikely, json honestly is fine for something that's somewhat human readable...
A change in the direction of protobufs to reduce serialization and transfer costs of data exchange seems most likely the next trend.
This has been a solved problem for at least two decades. Use ASN.1 and choose your encoding rules accordingly: JER when you need JSON, XER when you need XML, and switch to BER/DER when you need to reduce transfer costs.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#66Earlier quoted context omitted.
Are you serious? Do you honestly think that I am talking about a schema for passing empty lists around? If you are passing around lists of structured objects, I need you to send me what those objects are supposed to look like even if the list is empty sometimes. If you say "ok so sometimes I'll give you an object with a schema key and a list of data, other times I will just give you an empty list because I don't feel…
I assumed you meant empty list because that made sense. What you said here does not make sense.
That's because you're trying to snarkily jump into a conversation you don't understand.
User `flanked-evergl` is asking why do you need a whole new format for this instead of just using json. And the answer is because everyone needs to agree on how to specify the format in the json, which `crote` suggests is as simple as doing `{"schema": ..., "data": ...}`.
There's your format. If you want everyone to agree on the `{"schema": ..., "data": ...}` pattern, you can no longer accept just `[]` as a return type. Every response has to include the `schema` and `data` keys.
Re: TSON – A JSON superset with immutable, hash-pinned schemas
#67Earlier quoted context omitted.
"superset" is just marketing mumbo jumbo that says: "I promise to embed an x86 virtual machine inside my spec that'll still parse whatever weird JSON you're currently handling and give it back to you as an object in your programming language" $ echo '{ "Hello": "World" }' | tson --parse ERROR: ...refusing to interoperate w/ JSON b/c we want to be different ...that's a non-starter. If they're trying to replace or supp…
> unambiguous But it's pretty ambiguous when parsing. Like a long number -- is it a floating point, BigInt or i128? Every language is different JSON was a blessing because it was literally Javascript. It was unambiguous in Javascript only. A true unambiguous would be "everything is a string", like TCL.
Tcl brings with it some other ambiguity when serializing though.
{a 1 b 2}
{"a": 1, "b": 2}
["a", 1, "b", 2]
"a 1 b 2"Re: TSON – A JSON superset with immutable, hash-pinned schemas
#68Earlier quoted context omitted.
I assumed you meant empty list because that made sense. What you said here does not make sense.
That's because you're trying to snarkily jump into a conversation you don't understand. User `flanked-evergl` is asking why do you need a whole new format for this instead of just using json. And the answer is because everyone needs to agree on how to specify the format in the json, which `crote` suggests is as simple as doing `{"schema": ..., "data": ...}`. There's your format. If you want everyone to agree on the `…
Oh guilty as charged, thank you for explaining it.