Universal Configuration Language - UCL

I would like to propose a new Universal Configuration Language, to use when testing multiple firmwares, on the same machine.
The idea is to develop a standard for an abstract language that can be parsed to different firmwares.
If we as a community could invent such a language it would make configuration across systems, as well as sharing configurations MUCH easier!

I have attached a first draft, based en XML, as it will be easy to parse, but most likely something more user-friendly will be more ideal.

Wouldn't copying the 'configuration.h' Marlin file be the same thing? I'm really a newbie and don't understand much; but that was my thought when I read your post.

Yes, and no.
The thing is Marlins 'parameter names' are open for change.
This means a config file from an early marlin might not work on a later version. And lets say, I want to test out Repetier firmware, or maybe the smoothie board firmware. The names are completely different again. But if parameter names could somehow be described on standardized form, then it would be much easier for a user to test different firmware.

Another example. Lets say a company invents a new probe or maybe a filament sensor. Now they have to choose which firmware to support, and figure out how to instruct the user to change his/her config file to support it. This description needs to be accurate not only on a firmware type basis, but also on version basis.

Or they could write one single patch in UCL and let the different firmware developers parser take care of it.

Yes, and no.
The thing is Marlins 'parameter names' are open for change.
This means a config file from an early marlin might not work on a later version. And lets say, I want to test out Repetier firmware, or maybe the smoothie board firmware. The names are completely different again. But if parameter names could somehow be described on standardized form, then it would be much easier for a user to test different firmware.

Another example. Lets say a company invents a new probe or maybe a filament sensor. Now they have to choose which firmware to support, and figure out how to instruct the user to change his/her config file to support it. This description needs to be accurate not only on a firmware type basis, but also on version basis.

Or they could write one single patch in UCL and let the different firmware developers parser take care of it.

I like it; but I'm doubting it'll gain much success across development teams of various firmware's or worse case scenario they'd use the same variable name to represent a value that isn't "exactly" represented the same in their specific brand of firmware. I've actually ran across that quite a bit with abbreviations and standards when trying to merge two pieces of software.

If someone wanted to create an independent tool that would find & replace vendor specific values and would be maintained up-to-date via release alerts then wouldn't that accomplish the same thing? I couldn't help but run into some user input creators online like this one here @ [marlinbuilder.robotfuzz.com]

And couldn't help think with the added ability to say; drop a Marlin configuration.h text file onto the page would be substantially easier to see new fields and configure the firmware and perhaps on the same lines it could output various vendor configuration files or even compile them right there on the tool.

Just some thoughts to add.