xml configuration file

I would like to propose to the list an effort to try to create a XML
specification file that would provide the network configuration details.

Why?
Unix has a know problem, a miss of standard. Because of the openness of
Open Source each of us tries to create the best solution for a given
problem, while this is great for some things it is not that good for
other, because it may lead to fragmentation and disorder, therefore
losing effectiveness.

GST, and you should know this more than i do, suffers alot from the
"each distribution has it's own spec" effect, in what concerns to
network configuration (from now on netconf) each distribution has it's
location and syntax on debian it's a file in /etc/network/interfaces in
redhat it's located under /etc/sysconfig/networkm under slackware in
rc.network, it is an extraneous operation to add and keep up to date
support on each of this platforms.

The solution to this problem, IMHO, is not that difficult. Why not
provide a new spec for this type of file, and not a spec based in bash
or any other syntax, we need something technically advanced such as XML,
it gives us all the benefits that all of you must already be aware of.
Some might say that it won't solve all problems, and that's true, one
thing that has to be created is a service that should be called uppon
system boot that would load the configuration file, but i don't think
that this is harder then supporting all configuration files available on
every distribution (and operating system) that GNOME might used on.

We want an universal configuration tool, why not depend on a spec that
is more accessible and open?

With one configuration file it is up to the back-end to take care of how
it is implemented, whether it's on Linux or on FreeBSD. This way the
work of back-ends is focused on configuration and not parsing data.

This case study was made on netconf, i leave it to you to think about
the following: Is it possible to have other tasks GST currently does
with configuration files?
My guesses are that in some cases, as services, it isn't possible, the
only viable solution is the LSB kind of approach.

Tiago Cogumbreiro