Structured Data Schemata: don't be an idiot

I eff'n HATE drooling idiots who (don't) create schemata for uniform data-as-JSON from API endpoints.

{ "avalanche-2": { "usd": 31.49 },
   "bitcoin": { "usd":...

Anybody see the problem with this?

Why not:

{ "token-id": "avalanche-2",
  "quote": { "currency": "usd",...

HUH?

When you, the consumer, try to consume the above JSON (the one with VARIANT KEYS?!?!?) in a programatic-fashion?

You're going to have to hack the HELL around trying to define what a key is, BECAUSE THE KEY IS A VALUE, FFS!

Perverting JSON's VERY CLEAR structure is just stupid!

Maybe it's because I have a 25-year background in structured data and knowledge-engineering, but when you define your schema as:

"The key is the name of the token id"

instead of

"The key is 'token-id' because it's an eff'n KEY not an eff'n VALUE!"

Then you're an eff'n idiot.

Remember, kids, there's a difference between:

• metadata, or labels; and,
• data, or values.

If you call yourself a computer scientist, software engineer, or data scientist, you should know this.

And if you don't know this, stop calling yourself what you're not.

Postlude

Now, for my next rant:

Let's talk about people who put compound or composite values into (atomic) cells, so you have to CREATE A PARSER to ingest data FROM A DATABASE?!??? ... when they could have just as easily loaded each atomic value into its own (labeled/typed) cell?

Fun!