Slashdot Mirror

And because it's XML-based, it means all this data will easily be searchable

*boggle* XML doesn't exactly lend itself to searchability.

I mean, there exists XML:DB, but it is FAR from optimal for searching. Certainly not "easily searchable."

Unless, of course, they are accustomed the the data being processed being unlabeled; then I guess some standard markup might be useful.

If you need to hit the DB from some type of programming environment I'd recommend using a DB with an implementation of the XML:DB API. I've been looking at Xindice, and Software AG's Tamino, both of which support the Java XML:DB API, which actually seems rather nice.

As for the speed, I can't comment from personal experience, but according to the Software AG folks it's quite fast even for their customers who are indexing terabytes of data. Of course, that's pr bunny speak so it's to be taken with a grain of salt.

I'm not sure exactly how native XML DB's work, but from my research (e.g.)it seems that implementations are based on hierarchical data bases: e.g. Adabas -> Tamino.

Java developers should have a look at the XML:DB API, which provides a common interface to access XML database services.

Could someone explain to me the benefits of an XML database? I can't think of an XML document that can't be expressed as a relation. I've seen vague references to performance advantages and ease of development for certain applications, but I haven't heard a convincing argument. Am I missing something, or is this just XML hype?

• Standardise on XML for configuration files. No, it's not perfect for everything, but it's well known, easily manipulatable with many different tools and is an open standard. It's good enough, and the benefits of standardisation here (in terms of ease of manipulation) outweigh the disadvantages I think.
• Make a GNU Configuration Library that simply exports some DOM interfaces for documents that can be retrieved via URIs. So - an app passes a URI to the config library along with some other information (like is this system or user config data) and gets back an XML document. The idea is that each application can be identified by a URI (or perhaps guid if you're feeling windowsish), and that they don't worry about how their configuration data is stored, only that it is.

  In the background what happens here is the config library is an abstraction layer over a datastore - of any kind. The default would probably adopt the dotfile standard that is defacto at present for personal data, and /etc, /usr/etc for system configuration. However, other plugins could implement an XML:DB backend, or store the data in a binary database, or do anything you like with it. The apps don't care.

• Fantastic, so now we've got most programs reading and writing to a standardised configuration format, and that data will be managed by the system according to user/distro preferences. Storing stuff in personal dotfile(s)/dotfolders would be easiest and most common I'd imagine, after all this system is pretty easy to understand and work with for the user. Next up is how the sort of user who doesn't want to edit text files all day alters the system configuration.

  Everyone will have different preferences for this too, and as Linux is as much about choice as anything else, this must be accomodated. Webmin is great for remote administration, but when I'm sitting in front of my box I'd rather use the KDE Control Centre. Other people would rather have their settings altered in each application. How do you manage this?

  Well firstly, it seems pretty obvious that most of the time it's going to be easier to edit application configuration from within that app. Sometimes that won't be possible, for instance with server apps, but for desktop GUI apps like word processors it'd be easier to select the Configure menu option. In KDE/Gnome etc. apps already use standardised config dialogs, so it's pretty easy for the user. For servers, Control Center plugins (or whatever your favourite equivalent is) would seem the obvious way to go. This doesn't necessarily mean coding up a new control module each time: Broadway would let you embed a KDE/Gnome control center module into Webmin easily.

• So now we've got configuration sorted, or at least a lot better than it was. Next up is software installation. This is a hell of a lot better than it used to be, but one popular misconception in the *nix community seems to be that non-technical end users are willing to compile apps. People who say "but it only takes 3 commands!" are glossing over the problem - often you need developer packages and reams of source code and header files for a program to compile. It can take a long time for even simple programs, and if there's an error during compilation/linking then non-programmers are screwed.

  That's why we have binary packages. Unfortunately there are two competing package systems, and this isn't a great system. Don't get me wrong, I'm all for competition, but sometimes competition is good, and sometimes it's harmful. This is one area where it's harmful, and it means I can't always get programs working on my distro simply because nobody has packaged it for me. But - nobody can seem to decide between Debian and Red Hat package managers! LSB says RedHat, Debian people say Debian, and in the meantime end users are caught in the middle. What's needed is a technically advanced solution that is distribution neutral - like for instance, GNUpdate If I was designing the LSB, this is what I'd use. It's not finished yet, but when it is it will give us backwards compatability with a distro-independant packaging solution. For those who can and want to build from the source, it will even be able to pull programs direct from CVS!

So there you go. Simple things, not a giant leap coding wise, but simply agreeing on some things with a smart architecture would go a long way towards propelling Linux into the kind of ease-of-use that only MacOS and perhaps Windows enjoys.

thanks -mike

It's easy to dismiss a new database technology as irrelevant because of the dominance of the RDBMS, but you should really learn more about it and when it is appropriate and when it's not. It's not going to replace relational, and isn't intended to. Here's a few links where you can learn more beyond what's available on Ronald Bourret's site mentioned in the original post.

The XML:DB Initiative
The dbXML Project (open source native XML database) Soon to become an Apache XML project named Xindice
eXist (another open source native XML database)

My blog on the subject.
Kimbro Staken

Extropia has a detailed tutorial on databases of all types.XML:DB discusses the differences between object-oriented databases, hierarchical databases, and relational databases in detail. You may be interested in DBX a DBMS that is written completely in PHP, and works using XML style text files as its native format.

Someone could leverage XML RDBMS like DBXML which is based on the "XML:DB" standard.

If enough people are interested, I could try downloading dmoz myself and "massage" it into some dbxml store on my own system and build a web-based interface to query it, I've just been really busy with other stuff lately though.

If you happen to read this and are interested, shoot me an email at valmont@wildstar.net and we can take it from there.