XML/XSD based configuration files.

[Frans Englich]

On Tuesday 07 December 2004 14:47, Waldo Bastian wrote:
> From the buzzword-department.
>
> See http://bugs.kde.org/show_bug.cgi?id=94611
>
> Anyone interested in looking into this? I most certainly do not want to
> *switch* configuration formats, but I think it's a viable strategy to offer
> an alternative configuration format to our users with great marketing
> potential.

( 1. Don't get  language-religious; 2. Don't get religious; 3. I'm not saying 
I'm right, and go for the big pictures)

I have no particular opinion on the KConfig side, but the concept put in a 
general perspective -- to use XML -- is very interesting. I think that not 
using XML for anything data related(with exceptions) is equivalent to hitting 
oneself with a brick. Unfortunately we still do it, and it will take long 
before the "aha" goes through the audience at large, I think.

All the technologies invented through W3C are made for describing, handling, 
and processing data. Much of what we do with our file formats and Free 
Desktop standards is non-optimal solutions which would be easier, in several 
ways, to do with XML. When I look at the Free Desktop specs, which are random 
and not coordinated into a whole, I want to gather a 3-4 engineers for a 
couple of weeks and build a _platform_ described in RDF and WXS. Of course 
it's an impossible project for several reasons, but the advantages would be 
enormous; greatly simplified code in implementattions, easily extended, more 
enterprise friendly, and fit well into the meta-search paradigms starting to 
pop up now a days.

Much of what the bug reporter writes makes to me sense. It is simply 
unnecessary to invent own file formats, when a bullet proof meta-language as 
medium exists, when deterministic languages to /describe/ languages exists -- 
and along comes a heap of tools as complement.

I think the problem of sewing in XML isn't technical, but rather 
organizational: no one knows a dime about XML(it's a general problem though). 
For example, those few who know XSLT find it an incomplete language -- 
because they abuse it by using it as a procedural, instead of the 
declarative, recursive, it is. I also have plenty examples of discussions in 
KDE where people reject and fight back XML approaches, because they simply 
don't know better.

That's the problem, similar to how the GNOME hatred and desktop religiousness 
prevents a heap of topics to even be discussed.

What we can do, is to stay aware; promote WXS in front of DTD for example, 
such that future projects/combinations hurt less. 

		***

Waldo touches the marketing advantage, and I too thinks it's indeed valid; 
because it can solve open source' problem of being scattered, while 
simultaneously bringing great technology. For example, the KDE platform, 
basically the Win32 API written in a beautiful, sane, and efficient way, 
isn't interesting: the market is small and C++ isn't that compelling 
from a productivity perspective. The same can be said with many other open 
source projects -- great technology, but they're living in their own corners, 
and are too small to have an impact.

That problem, is for example what Mono tries to solve, but another approach is 
to support the "XML platform". Let's say KDE had a Web Services library, 
implementations of the various central XML technologies hooked into for 
example Konqueror, then would KDE's adoption chances not depend on whether C++ 
is considered attractive, but slide right in because it fit in platform 
independent solutions, built with XML technologies. Using KDE wouldn't equal 
"develop with C++" but mean "develop with XML".

For the same reason companies are successful in the PC hardware market, why 
open source applications are successfull in the backend/network area(because 
they support tcp/ip), would KDE ride the wave of the open standards from W3C. 
In other words, KDE wouldn't be selected because "it's KDE", but because it 
"is" the open market of XML technologies. In short, I think KDE/Web Services 
would work, for the same reason milk vendors put recipies on their packages. 

The result at large is that KDE wouldn't compete with for example dot Net, but 
all open source projects supporting XML, and all 3rd parties/small companies, 
would, standing united behind one open platform, be an alternative for dot 
Net. And hence would KDE no longer be a niche, but start to float because of 
the tide, along with the other boats.

What was the topic again?


Sorry,

		Frans