In a previous life, i worked for a company that was building an x500 MTA. For those not in a fetal position beneath their desk at the very mention of that phrase, an MTA is a Mail Transfer Agent. It's what's responsible for getting your complaint about the new Timeline to zuck@facebook.com. x500 was the "Improved" mail addressing format that didn't presume a user at a site, but instead qualified it by a list of things that described an individual, from least specific to most (e.g.
Country: US
Province: California
City: Mountain View
Company: Widgetco
Floor: 3
FamilyName: Doe
SurName: John
DNAFingerprint: ATTACAG...
etc.)
(i'll beg your forgiveness if the field names are not correct. The therapy helps blot that crap from my mind.)
What's important here is that x500 allows fairly arbitrary fields to be inserted into a given record. The MTA only has to pay attention to the ones that it recognizes, so you could build one that only responds to, say, "Company, FamilyName" if you're a place with a dozen, unrelated employees. The rest of the spec is all optional. This lead to all sorts of interesting abuses, including one of the things i was working on that involved storing a cryptographic key inside of the record that tied back to the authorizing provider, allowing for a verification path to the central root authority, meaning that your headers were often far larger than the actual content of the message and that had to be magically stuffed through a 300baud modem in a timely manner.
Still, flexibility was a strong selling point for x500. So much so, that the example included the frivolous category of "FavoriteDrink", and provided a helpful collection of alcoholic concoctions for the various fictional individuals to imbibe. HaHa, what merriment shall be had!
Only, it was in a spec, so that it became codified.
Now, a few decades later, i fully expect that there are more than a few unit test cases for determining validity of records based on "drink", and some very confused intern wondering what the hell that field has to do with figuring out how to partition their machines. i have been that intern. It was not fun.
This is why i tend to be a little cautious when folks talk about "loose data definitions" in applications, unless they REALLY MEAN IT. As in, they define methods for how data can be stored, but do not require specific elements to be defined. The application is therefore required to determine if a record can be used or not. That tends to shoot a lot of holes into peoples designs, and i'm ok with that. You can't realistically expect anyone else to use something where you hand wave over something as important as "The Data You Use".
Well, unless you're also providing all the alcohol that they'll need to deal with that stuff.
