My lack of imagination is clearly preventing me from grasping something crucial. That and the fact that I'm a SQL Dev only. I don't do any application programming. So, I fully acknowledge that there may be some intricacies on the app side (that I'm simply not aware of) that this concept mat very well solve.
I swear, I'm not trying to bag on the idea. I'm just having a tough time visualizing an actual need.
From where I stand, there are two main way data finds it's way into a database. 1) Users using an application, inputting small amounts of data per transaction but having a number of such transactions. 2) Bulk data imports from files that are generated in external systems and delivered at preset intervals, typically 1 or 2 time per day.
So, for #1, I simply can't picture needing anything simpler than EXEC dbo.SomeStoredProc @P1 = 'Jason', @P2 = 'Long;
#2, on, the other hand, has lots of room for improvement... csv, fixed width & xml (and anything else) all have their own set of drawbacks. So, if your idea centered around data exchange formats, eliminate the delimiter hassles of csv, column width limitations of fixed width or the file bloat of xml... now I'm interested!
My idea on that front would be a system that automatically "normalized" & compressed all redundant data, splitting a file into multiple sub files and then zipping it all up into a single, consumable file... Similar to the new(ish) MS Office "X" fole types which are, in reality, zip folders containing multiple sub-folders & files... but... to the end user, function as a single file.
As far as it being a no downside "panacea" that allows my schema to talk to your schema without either of us having to know about each others schemas... Well, that sounds a lot like the sales pitch we all got with xml & more recently json (not to be confused with me... Jason).