Slashdot Mirror
Expanding the use of XML in Linux?
elemur asks: "I was wondering if there are any projects to expand the use of XML in Linux? There are alot of areas where XML could be more easily and consistently used than continuing making more and stranger configuration files. Many configs could probably fall under a generalized standard application config DTD, and applications that needed something more targeted could supply their own. Some sort of DTD repository could be setup on the machine to handle this. Then, apps just need to use libxml (or whatever it would be called) to handle the reading and parsing. It would seem to make things much more consistent. Has anybody looked into this sort of thing?" It's a good thought. And a standardized configuration file format might be the thing to reduce some of the complexity most folks find in Linux. What do you all think about the capabilities of XML?
Update: 09/29 04:03 by C : Screwtape submitted this tidbit "I just saw this on MozillaZine and I'm quite impressed. Somebody has taken the XML parser from Mozilla, and written software that makes it work like an xterm - but with extra features. For example, you can write a replacement for ls where all the filenames are hyperlinks to the actual files. The site is here. "
What the expat libs, its about as open source as you can get.
That is what a few other open source projects use to incorporate XML into their code.
*Shrug* I would love to learn more about XML and start using it myself.
Not to mention the possibilities of using XML-based procedure calls for remote interfacing. Check out http://www.xml-rpc.com/
I was just starting on this last night :) I am in the prcess of getting my XML parser on line heheh Benefits: Unicode support Ability to use style sheets to view the data making html system mangament tools easier while at the same time allowing people to go in an hand rework the files. Side notes: nDump the idea of a database to store the files on a machine. AIX and Mach/NeXTSTEP use and idea where you would edit the text files and then reload the database. From a system administration point of view it sucks really bad. It also adds a new level of complexety to a process that dosen't need one. Now where did I leave my language spec. hmmmm Leslie Donaldson
Error checking and consistency is contained in the parser, and DOM gives you a grove of nodes to examine further in the laguage of your choice.
I am just a 'power user' who is very intersted in Linux et al., so maybe I lack the technical background to fully understand the implications of these. But *do* know a little XML (and learning more ;) and I plan to de some programming myself, and I think this could be The Right Thing(TM). I think this could benefit Linux inmensely, and I hope it is implemented ASAP (are you reading, you coders? Yes, I mean *you* :)
Isn't there an XML parser in the Mozzilla project? And if so, can it be implimented in a Linux ecology seperately?
I've seen a little of Linux configuration files, and I think XML would be a great benefit.
Open standards = Good.
(As a simple example, Apache configuration files are XML-ish, though not strongly so.)
A filesystem may look nice from the outside and have lots of great features, but when something goes wrong and the settings for your favorite daemon are in a corrupt filesystem what are you going to do?
A database is not necessarily any worse than a filesystem. (Since a filesystem is actually just a particular kind of database.)
I like my separate config files thankyou verry much. No Linux Registry for me...
Gnome already hevily uses XML. They have a libXML and GConf is using XML as a backend. Everything you asked for has already come true. Didn't expect that one, did you. :)
Also, people creating DTDs on their own is the whole point of XML: You create DTDs for whatever task is at hand.
Of course it would be an advantage if configuration files all used the same DTD, but it's not needed to start using XML.
Another great feature of XML is that it's so easy to convert between different XML formats.
AbiWord actually uses XML as it's native format for storing documents.
.xinitrc wouldn't make much sense in XML... it's one of those things that are really a shell script, like .login or .profile... One more difficulty in doing this.. deciding exactly what is or is not a config file :)
A common problem w/ windoze registry is that ill-behaved registry modifiers blow away other apps configuration.
.so versioning, so every app could take it's chances with the last .so installed, just like windoze dll's.
.so's to have their own private data area, so that any errant app can bring all the other apps down.
Seperate is better. Text based is better.
I hope Linux never tries this horible idea...
If we're really stupid, we could also get rid of
Furthermore, we could allow
How about putting all files in "c:/windows", There's another bad idea we haven't adopted yet.
I wanna be like Bill!
XML sucks, yet another langage, requires yet another parser fatwear
move on, change the channel
That seems a better choice. XML has nothing that S-exps don't have, but S-exps are much easier to parse.
It seems the poster wants XML introduced into all applications - not really the Kernel.
No offense, but whether you like it or not, people are going to be using the word "Linux" to include the kernel, required binaries and supplemental programs -- in short, the whole ball of wax. If somebody wants a change in the kernel, they're going to say "Linux kernel."
I think we are missing the point here. What is great about Linux is that there are choices. The one that works best for people is the standard. nobody descides. We ALL do. It's evolution. We're not try into beat Microso~1. We are try to create a great OS. Worry about that first and MS won't know what hit them.
the use of simple separate config files written in xml is that they can be moved, edited, built using simple sh, grep, awk, cat, vi, etc. commands OR using automated or GUI based tools.
/. filters out the tags even in "Plain Old Text" mode.
XML files are text files, they're just written in a way that helps stupid computers tell what they're about as easily as smart people can.
I doubt seriously that anyone who has the ability to edit config files by hand is going to notice a readability difference between
Username = joeblow
and the xml representation of the above, which would be "Username" wrapped in angle brackets followed by "joeblow" followed by open-angle-slash-closed-angle.
I'd type it literally, but for some reason
Aaargh my angle bracket expression got garbled by the preview even though I used HTML &-entities. The relevant parts were:
Instead of using XML <foo> and XSL or CSS you can as well use <P.foo> or <TD.foo> and CSS.
And as a programmer I don't care if my data is
name,value or
name=value or
<name>value</name>
I like XML's syntax, but have a very small idea
of how it really works. I figured that I could
remedy this by making my next OPEN SOURCE PROJEKT
use XML as a config file format.
Clearly, by the monumental support here, others
like the idea as well. This is definately
something worth learning since it's popping
up EVERYWHERE.
Also, to note: There's no real work involved
in "converting Linux to XML". If all open source
developers "in the know" use XML from now on,
you can bet that in 2 years, everything will be
using XML. (I'm sure, say, the Apache developers
are already moving in this direction).
What I want to avoid though is writing a custom
XML parser, especially if in 2 years, every
Linux distribution is going to have one. Does
anyone know which one that is likely to be?
Should we start arguing now?
Linux Standard Base anyone?
--Michael Bacarella
There is nothing wrong with the concept of a "registry." In fact, /etc can be viewed as a very poorly designed registry, and Debian (and others) have no problem maintaining installed package registries.
/etc directory and emit xml and vice versa. This approach also makes it easy to migrate to XML tools, since the XML-aware applications will read the XML files and the rest will read config files generated from the same files.
Where Microsoft's registry did a major face plant into the cow patties was
1) it uses a *binary* registry, so manual modification of the registry is difficult if not impossible,
2) it is accessed by code with the same high quality that we see in all other MS software. That means you'll need to manually edit the register on a regular basis, but #1 means that's difficult.
I would have no problem with an XML registry, and in fact I've done some preliminary work on some programs that slurp in much of an existing
I would also not be too worried if my registry was stored in a RDBMS with a solid track record. Postgres is a totally free one, MySQL is mostly free, and Oracle would work on those sites which have to deal with thousands of users.
But a binary-only registry with home brew access software?! I wouldn't trust software *I* wrote for that, much less MS software.
(coyote-san on soon)
>maybe it's a religious issue.
Don't sell your argument short. The standard computer "Religious Issue" means there is no compelling technical reason to choose one over the other. However, there are strong reasons to favor ASCII over binary config files. The biggest reason is that a binary config file needs Yet Another Application to view/change. ASCII config files only require an editor. There just easier to use -- try grep'ing a group of binary config files to find some chunk of info.
Anonymous Kevin
Yeah, that's why Postgre is so much more stable than MS SQL-Server, right? Ha!
Libxml is released under both W3C Public licence
and LGPL, you can freely reuse it in commercial
closed source projects.
I'm not an A.C.
Daniel
Daniel.Veillard@w3.org (libxml main author)
Posted by Project'Resin (I can't register, keep getting rejected). NO - It violates the keep it simple principle. It is poor design to require an extraneous package to be present and already operating in order to bring up the main program. This is true for booting the operating system, starting an IDE, or launching an application like a browser. NO - When config files are wrong they must be fixable with the simplest tools. ASCII config files only require a PLAIN text editor, which can be run from a floppy rescue disk. I gave up on Red Hat's GUI program for just that reason, I could not get X11 to come up, but their config tools required it. I am sticking with Slackware and their simple .rc files, kept in a subdirectory of /etc. NO - Anything that slows up booting or launching tasks will not be an "improvement". Anything that takes Linux towards the integrated-bloated software concept pushed by some of the software giants will not have my support. I want config files to be separate and independent so when I mess up one of them the whole system isn't affected. YES - To something that will help INTERPRET the current config file formats. Some kind of common tool that knows the legal values that can be included would be of great help. A common point (like /etc) to look for config files (or links to config files) would also help. But the config files themselves should stay plain ordinary ASCII. YES - If you can improve the syntax of the config files so they use the same idioms. But this does not require any tool, system, or meta-language to get between the config file, the config file maintainer, and the config file reader. YES - A library module that reads config files, so that every application does not have to invent their own, would be a welcome addition. But this does not require XML, and I do not see what XML would bring to the concept. File reading and tokenizing are the main needs from a library tool, no interpretation which is entirely dependent on the applications needs. (Okay, someone is going to have to tell me how to get a line break ...)
Actually XML is a bit more general than S-exps in that it allows you to pass parameters, and specify that these parameters are optional, fixed, or have default values. Of course these can be simulated in LISP, but the ways XML handles them is cleaner.
There's no semantic difference between <foo bar="baz">quux</foo> and (foo (:bar "baz") "quux"). The differences are
I'm worried that my tone is too flaming, but it's hard to convey how much easier the s-exps were to use without sounding like a language bigot. :( (I bet Perl hackers feel the same way trying to convince people that Perl is a great improvement over shell scripts + awk.)
Also XML has something resembling a type system in its DTDs, which seems somehwat alien to the LISP mindset...
Not in my experience -- it was easier to check correctness in the Lisp version. A DTD isn't a real type system for XML documents, it's just a constraint on the shape of the document's tree-structure.
I literally took the cheesiest possible way to write my "Lisp Markup Language" tree-walker (recursive invocations of DESTRUCTURING-BIND, basically) and it automatically gave me the equivalent of validity-checking plus I was able to add the type-checking on the element content.
I got a stronger test of correctness than validity for free -- you'd need to use an XML schema to get as strong checking as I did, and you'd be doing a lot more work than my evening hack.
Fundamentally, the key idea behind XML is that it's better to systematically modify data structures than to randomly hack strings, and that a good way to do this is to use a string encoding format that makes it easy to convert from string->data and data->string. This is a good idea, and XML is a great improvement if you are used to the prevalent way of doing things.
In Lisp, tree structures are programs, so you use this whole powerful language focused around manipulating these interesting data structures. XML has very weak transformability in comparison. And since the point is to do things with the data beyond just admiring how nicely the tags (or parens) match up, this makes Lisp easier to manipulate than XML.
This obviously won't take the world by storm, but I do feel obligated to point it out in case there are people for whom how powerful a solution is is more important than how widely a solution is used is. (You should look at Curl for another much more extensive example of how powerful the Lisp-like approach to documents is.)
He wasn't suggesting a registry, he was talking about a unified config framework like the MMC. So you have one config app that you can plug in modules for configuring all your apps, and even the kernel. Your config files would still be wherever they are, just in a standard format. There would be a unified config app, but you could still edit the files yourself. Well, that's what I thought he meant.
You've still got your project.
Organize a group to define the config file standards, not code the XML library.
Go for it! ;)
I think that the first area that should be explorer are the documents (HOWTOs, FAQs, man pages). The key to using XML is to separate the information from the presentation. By including meta information, we make these things easier to organize, easier to search on, and easier to present. If someone were to define a DTD for man pages, I can then create my own applications for presenting the man pages. Maybe I want HTML; I can use XSL or CSS to format the XML man pages. Maybe I want plain text, so I build a converter. Or I can build a search program which reads the appropriate tags. There's alot of possibilites. And from what I can tell, man pages are in a funky format. This would mean XML man pages would be easier to write. This goes without saying for the HOWTO's and other documents that we rely on to use Linux (and other Unix systems) more effectively.
And the point of making us do all of that extra typing is what?
Most tree structured databases are simply badly thought out and and usually badly implemented versions of the file system.
This is likely to be one example of that.
There are very few applications that could profitably use a tree structured database instead of a file/directory tree.
Compared to the native file system, databases are high overhead, non-portable, have non-standard file formats, usually have bad error recovery, often cannot be worked around if there's a corruption, have slow access because it's not built into the kernel, have high memory overhead, often have bizarre locking semantics, are susceptible to revision control problems as each latest and greatest database engine comes out, often have large files for even small amounts of data and use non-standard compression mechanisms.
Locking in the file system is well understood, is simple and it works. Granularity is controlled by varying the size of the files versus the size of the directory structure. If file/directory size is an issue then they can be compressed with tar/gzip/bzip or by using a compressing file system. Data validity in such a directory tree is controlled in an identical manner to a database - by the programmatic access to it.
Don't reinvent the wheel and create a proliferation of half-baked semi-solutions. Use the fast, easy and effective tools you already have.
This advice comes from bitter experience with a number of databases that purported to be the be-all end-all of data organization.
To keep the config files exactly the same as they are now and write an XML definition for each config file then write a tool to use the XML definitions to edit the actual config file through a browser?
I am loath to change the current config file formats for one major reason: They currently work and work well. I was raised with the notion that if it ain't broke don't fix it.
My 2 cents worth...
There is no user interface. There is only Xul.
Think of parser generators in XML, GUI programming etc.
If you forget the hype, XML really doesn't bring you anything plain old LISP (or GUILE) wouldn't already have. Both are just ways of serializing tree structured data, but LISP has a simpler structure with parenthesis enclosing each level instead of cumbersome pairs.
.emacs file and hardly anyone has any experience with XML. There is also a lot of support for writing LISP code in Emacs (automatic display of matching parenthesis etc.) and very rudimentary XML support.
Choosing XML would be downright stupid when you think that almost every GNU/Linux user knows how to edit his
I know of an application which has about 300 user-configurable parameters!
XML lacks some very specific features, like:
/etc/passwd into XML and you understand, why this is a bad idea. /etc/smb.conf.
- ability to add something to the end of the file. XML requires a starttag and a corresponding end-tag. Additions to an XML file must be inserted in the middle.... Try to change
- XML makes bigger files.
- XML makes more unreadable files compared to
Microsoft wants XML, because:
- They can implement proprietary tags that make it necessary to use Microsoft software.
- FUD: People think they need to learn Microsoft XML and therefore they haven't time to look at Linux.
- Using XML in web-pages prevents people from using other browsers like Netscape, KFM etc., until they get it implemented, too.
Don't support Microsoft - only use XML for what it's good for.
Lars Dybdahl.
lbd@dybdahl.dk
(not a coward, but I forgot my password)
I am currently strting an easy to use XML passer and XSL processor in ANSI C. Owen Synge
If even half of what you say here were true, XML would indeed be a wonderful thing. But unless I have missed something in my reading on XML, it is not what people are making it out to be. Specifically it does not provide "seamless interchange facilities". In order for it to do this it would have to carry the semantics which attach to the data it describes. In other words it would need to be a programming language. Just because XML gives me a way of defining a data structure, doesn't mean that it is really useful. It only becomes useful when different consumers of XML-described data can agree on the semantics of how to manipulate that data. There is no mechanism in XML to describe this; no introspection; no control flow. I predict a rapid growth in the use of XML, followed by disillusionment as people realise that the "version problem" hasn't gone away. With reference to using XML as the standard for Linux config files, it wouldn't fix anything. The semantics attached to the data would still inhere in the particular programs used to manipulate any given config file. Getting the data in and out of the file in XML is not going to change that. If you want a standard for writing config files, maybe it should be some form of scripting language. Then the interface would be through a commonly-defined class structure which would include methods for GUI or character-based manipulation. I don't care what format you store your data in, until and unless I need to manipulate it with an application other than the one which created it, in which case I need a whole lot more information than just what the data structure looks like.
Cyprinus carpio Linneaus 1758
just won't do it--I'd rather use something like Cyprinus carpio Linneaus 1758 . Same thing I think with the configuration files. You can parse them with almost any XML browser and make a GUI conifguration tool using the specific DTD and XLS for the application, make changes, and them send the changed config file back to the application--no binary registry, no need to get 10000 pleople to agree on ONE standard good for every project and for all ages to come--or you have to do this AGAIN to update it!SORRY, BUT /. FILTER F.. UP THE PREVIOUS ONE :) I think you are right. I guess, after all, that this is one of the reasons for advocating the use of XML instead of plain ol' HTML: using and/or making you own markup language, suited to describe structure of YOUR data, and no just some generic one-size-fits-all-suits-none DTD. Myself, I can see that in my field, biology, and how we can move to electronic info handling. I love the Web for science (after all, that was its intended use, remember? :) but <P>Cyprinus carpio Linneaus 1758</P> just won't do it--I'd rather use something like <TAXON><GENUS>Cyprinus</GENUS> <SPECIFIC_EPITHET>carpio</SPECIFIC_EPITHET > <AUTHOR1>Linneaus</AUTHOR1> <DATE>1758</DATE> </TAXON>. Same thing I think with the configuration files. You can parse them with almost any XML browser and make a GUI conifguration tool using the specific DTD and XLS for the application, make changes, and them send the changed config file back to the application--no binary registry, no need to get 10000 pleople to agree on ONE standard good for every project and for all ages to come--or you have to do this AGAIN to update it! :( About editing config files as text--you can do it as well with XML, in fact, *darn*, I JUST DID! :)
> In XML, however, you can see the equivalent
> of the closing parenthesis with your naked eye,
>, without a browser designed specifically for LISP.
You are going to watch at XML documents with a text editor? Without tools? Shiver...
Good luck...
The only problem with that is the same set of problems that you suffer under Windows today. You can't understand it, you can't manage it, and if it gets corrupted then EVERYTHING is corrupted and you can't recover.
> A closing XML tag is always immediately obvious.
...).
Don't believe it.
1) Many XML files
will be poorly formatted, so you
need a pretty-printer (-> Lisp).
2) The Structure will be as complicated as
in HTML files. Have you ever tried to
see the matching end of a table tag in a non-trivial
HTML file - good luck.
Without Editor support for navigation you
won't see the end of XML forms. You
could use a Lisp editor such as Emacs
the same way.
3) A Lisp programmer does not see the
parentheses. She reads the code by using
the clues from the names of the forms
and from indentation. She also uses
the editor to take advantage of the
parentheses (moving, selecting, transposing,
indenting, commenting, evaluating,
Actually for a Lisp programmer the Sexp-syntax
is a ***huge*** productivity boost.
She can manipulate large amount of code
with a few keystrokes and mouse clicks.
Miguel de Icaza and the GNOME team agree with you. They've been using XML to store gnumeric spreadsheets for awhile now. See ya, WaRtHaWg
You can buy one, but is there a OSS ODBMS out there?
One of PostgreSQL's lesser-known features is that it is not just a relational db, but a full object-relational system.
I think this is a better approach than pure OODBMS's -- I've had bad experiences with them; ad-hoc queries are a pain, and only God can save you if a pointer gets corrupted and your db suddenly forgets how to find half the data you put it.
A couple of people have cited what they believe to be disadvantages of XML that I don't really agree with.
1) Something else to learn.
The DOM XML API (which is what is used in expat) is pretty easy to use. If you stick to simple structures, which most apps would, it would probably be easier to learn the DOM than it would be to roll your own config format.
2) Extra data overhead.
This is probably not significant enough to worry about. Most apps should do fine by only reading the config file at startup, and in the era of 20GB disk drives a few more characters isn't going to matter.
"Username = me" could become me
3) Speed
While using XML to describe user interfaces and fabricating the UI everytime a dialog is painted probably does slow things down noticably, simply using xml for the config file probably isn't going to cause any huge speed issues.
4) DTD Proliferation
This could be a real problem. However, I'm not sure it would be neccessary to even define DTDs for config files. Well-formedness (all your tags are balanced) should be enough. Of course, this does sacrifice the ability to syntax-check the configuration.
That being said, I don't think XML will be very valuable everywhere. For example, in sendmail.conf the real work isn't in parsing the config file to extract the rules, but in turning those rules into meaningful behavior. So the work of converting it to using xml probably isn't worth the small payoff. However, for most apps that use the simple "option=value" configuration style XML can provide real value.
Just a little reminder: Niether RPM, nor .deb are proprietary. Detail descriptions of both formats are easily attainable. As would your package format. It's just a matter of people using it. Also, there are the differences in how the dependancy tree is handled. Debian's is much more elaborate. That has little to do with the package format though.
There exists no mechanism for specifying semantics for a program which intends to use your DTD-defined language as the form of its own configuration files, or whatever purpose. Implementing those semantics is as hard manual works as with any other non-XML syntax.
There's the denotational semantics, which the Scheme and ML people use in their respective standards to define the semantics of their languages. The only problem is that the widespread use of formal semantics means programmers would have to think hard about the design and behavior of their programs, so that's clearly not feasible. :/
Agreed. DSSSL was beautiful; I don't understand why the W3C threw away an elegant solution and replaced it with an ugly one. It's not even worse-is-better, it's just nuts.
[I have trouble posting comments, retry]
This library is used in the gnome project for a number of program including gnumeric, gill, dia, libglade, etc.
It offers the following:
Documentation and code can be found from the libxml home page
Considering keeping DTD around, I was thinking about that, I need a DTD cache with the URL and System ID association, this would be welcome.
I'm not an AC !
Daniel
Daniel.Veillard@w3.org
It all depends on how you look at it.
/etc/* and ~/.* be easier to use? Many people would probably say yes. If it doesn't say its a text editor.. is it a text editor?
a) The Unix way: Stuff everything into a proprietary configuration format. This has the advantage that any text editor can read and write the configuration allowing unlimited configuration options and semantics. So would a GUI text editor renamed to "System Setup" and allowing only to edit configuration files
b) The GUI way: Give everything a nice "clickable" configuration using checkboxes to represent boolean and text fields to represent text data. Merely representing text semantics as graphics semantics.
XML is just more complexity being added to an already too complex computer world. IIRC Unix was designed around simplicity. Giving few, simple commands such as cat/grep/etc. and pipes such as stdin/stdout Unix was able to do just about anything.. and still can. Unix was a very simplistic, basic design that was not designed as featureful or powerful. It became powerful by having simple components which did one thing and only one thing.
IMO, its time for a new operating system and paradigm. Unix has outlived its usefulness and today we need ways to communicate in 2d, 3d, audio, and text. We need ways to simply talk to a program/object across the globe or to talk within the same program or computer.
I think we need to look at what we really want our computers to do instead of how we want them to do what we want them to do.
Ok.. enough incoherent ranting.
There has been much argument in this discussion about the utility of a central "registry". Although I agree with the idea that since most problems with the M$ registry come from applications messing up when they are trying to update their sections of the registry. I would think that any configuration information that an application wanted to keep for itself should be in a separate file in whatever file format the developers wanted.
But I would think that there is a place for an xml registry that would hold information that many programs would like to read. It would hold information like IP number, color depth of the screen, available screen real estate etc. Since the main application file formats are already finely tuned and well established. It seems likely that this information should be maintained by some second program like syslog which other programs could pass information to, perhaps using the xml streaming protocols described in this discussion.
In this scheme, the syslog-like program would then write the files to an xml file that other applications could read (but not write). This would be somewhat like way BSD uses databases for fast queries while maintaining the primary document as a text document. Only here the xml is used not for speed but generality while the applications use their own private configuration files for safety (which may or may not be in xml). Of course if applications were already using xml for system information, it would make sense for them to also use it for their own configuration files.
Linux (and to a lesser degree Unix) are great because they are vitually pure meritocracies. Code has traditionally been adopted into the standard tool set because it is useful, not because it is marketable. The day the Linux community starts (more or less) collectively agreeing to and anouncing paths chosen by buzzword, Linux will have the same future as Windows. The right way to do this is to allow some enterprising XML advocate create a distro with XML based configuration files and see if it catches on. A few moth ago, Linux Today posed the question, "Should the kernel be rewritten in Java?" The answer is, of course, "If someone wants to!"
Here is some info on XML
t ml
m l_overview.html
1) Scientific American - XML and the Second-Generation Web
http://www.sciam.com/1999/0599issue/0599bosak.h
2) XML Overview
http://xdev.datachannel.com/directory/xml_101/x
XML Overview
XML is soon to be the lingua franca for open information exchange on the World Wide Web. XML can be used for business-to-business transactions as well as for information delivery directly to a consumer (via a browser or the like). XML is all about information although XML per se is not concerned about how the information is displayed to the human reader.
What is so important, then, about XML? XML provides a significant advance in how data is described and exchanged by
Web-based applications using a simple, flexible standards-based format. Hypertext markup language (HTML) enables universal methods for viewing data; XML provides universal methods for working directly with data. XML is a subset of Standard Generalized Markup Language SGML)that is optimized for delivery over the Web. It is defined by the World Wide Web Consortium (W3C), ensuring that structured data will be uniform and independent of applications or vendors. XML interoperability kick-starts a new generation of business and electronic-commerce Web applications.
The power and beauty of XML is that it maintains the separation of the user interface from structured data, allowing the seamless integration of data from diverse sources. Customer information, purchase orders, research results, bill payments, medical records, catalog data and other information can be converted to XML on the middle tier of a three-tier enterprise IT architecture, allowing data to be exchanged online as easily as HTML pages display data today.
Data encoded in XML can then be delivered over the Web to the desktop. No retrofitting is necessary for legacy information stored in mainframe databases or documents, and because HTTP is used to deliver XML over the wire, no changes are required for this function.
XML is valuable to the Internet as well as large corporate Intranet environments because it provides interoperability using a flexible, open, standards-based format, with new ways of accessing legacy databases and delivering data to Web clients. Applications can be built more quickly, are easier to maintain, and can easily provide multiple views on the structured data.
As well, for any company adopting XML to extend their offerings, XML:
Is open, easy, and flexible to systems and application developers.
Can turn a Web-based enterprise into the ultimate database of databases. Is platform and systems independent.
It operates in a structured data environment with seamless interchange capabilities.
Sits on top of HTTP or IP and provides the protocol and language for exchanging data or information. Improves efficiency at the browser presentation tier and is an effective content storage mechanism.
Is a data integration technology that allows distributed systems to exchange and manipulate only required information.
Helps manage large repositories of content that are both addressable and structured.
Provides a uniform method for describing and exchanging structured information.
Allows every piece of information to be accessed in a Web XML-based infrastructure that has its own URL.
This library is used in the gnome project for a number of program including gnumeric, gill, dia, libglade, etc.
It offers the following:
Documentation and code can be found from the libxml home page
Considering keeping DTD around, I was thinking about that, I need a DTD cache with the URL and System ID association, this would be welcome.
I'm not an AC !
Daniel
Daniel.Veillard@w3.org
XML means an infinite set of yet undefined HTML like languages with no semantics whatsoever. With a proper DTD you have one language from this XML set of languages. You still have no semanctics, except what you write down to the DTD as human language comments.
With an a style sheet, either XSL or CSS, you can define a semantic transformation where a syntactic element of any XML family language, like a tag , is given a semantically meaningful visual presentation. Instead of using XML you could as well use plain HTML 4.0 with CSSS and tags like or to get the same result. XML gives you no benefit at this level here.
There exists no mechanism for specifying semantics for a program which intends to use your DTD-defined language as the form of its own configuration files, or whatever purpose. Implementing those semantics as as hard manual works as with any other non-XML syntax.
XML is a hoax. It is actually nothing but a free licence to invent an infinite number of your own "" and just pray that somebody will agree with you on their meaning.
Of course the world can negotiate standard XML DTDs with standard semantics, and standard software to interpret them. But agreeing on them and getting the semantics implemented is the exactly same problem as would be regardless of their syntactic family ties. The computing world is full of different formal languages, and the their syntactic variance is not a big deal. Finding a good syntax for an application domain is important, and implementing the semantics is the challenge. Just _parsing_ simple specialiced syntaxes for configuration files or application specific data is trivial with modern tools anyway.
I could not care less, if the data I have to parse is comma separated fields, name=value pairs or XML compliant value.
XML is vapor, a hoax, but XSL is the most horrible thing I have ever seen on my career. I won't go to details here.
Anssi Porttikivi
app@iki.fi
currently mostly a html/http/Tcl/Oval/database programmer
While I agree this can definitely be another good way to use XML; I'm not sure everyone will be willing to abandon the ASCII config file formats they have been using for a very long time, and move to an XML-based configuration registry. But something like this has to be done sooner or later...
Why? Using XML for configuration files doesn't actually buy you anything. All XML is is a way of concisely describing the format of a file -- but the data (and more importantly the data's semantics) in each configuration file will vary between programs just as much as they do now.
If you proposed that all configuration files be written as Lisp s-expressions, people would look at you funny because they could easily see that that doesn't magically win -- but mumbling the phrase "XML" seems to escape those filters, even though it's just s-exps with typed parentheses.
[I'm not kidding about the s-exp thing, either. I started to write a little system using XML and XSL to transform some of my docs into HTML, flat text, and LaTeX forms. But when I realized (thanks to Erik Naggum) that the XML document was just a way of serializing a tree structure I changed tacks. Instead, I stored my docs as Lisp s-exps and then was able to use Common Lisp instead of XSL to write the tree-walker and was done in a quarter of the time the other way would have taken.]
In any event, the thought that might bring real benefit is the idea that you can build a hierarchical configuration structure where apps can acquire config data from the containing configuration classes. (It shouldn't be a registry tree, though, because an application might rightfully belong to several disjoint classes -- you'd want a registration directed acyclic graph.) Defining XML DTDs would be a convenient (but not essential) way of creating a lingua franca.
In essence, configuration classes would correspond to OO classes, and the configuration acquisition tree would be an inheritance graph. This could be huge win if the graph were well-designed, because each piece of config data would be kept in one place, and program configurations would automatically adjust when that unique datum was changed. However, if the tree were poorly-designed then you would lose big in the same ways that bad OO designs suck hard -- configurations would be very brittle with lots of interapplication dependencies and needed information would be scattered all over the place.
My personal belief is that the registry approach would tend towards the "huge lose" case -- incrementally designing a good OO architecture requires aggressive refactoring, and refactoring configuration information among dozens of software projects that aren't even necessarily aware of each other would be an interesting problem in change management.
So I see having to manually adjust individual configuration files is the price we pay for letting each project develop independently of the others.
GNOME (specifically, Havoc Pennington) is developing something similar to what you described, in which a single configuration API can output to different formats -- the default is XML, but in theory you could have such systems as LDAP used. In case you're interested, a prototype is available in cvs module gconf.
That's a great idea. There are several places XML is being used rather efficiently already. I know that that the Gnumeric spreadsheet program already stores its files in the XML format. This, to me, is one of the great things about XML....
Werd.
Sounds great, but do you really think MySQL is the right tool for this job? Don't get me wrong, I love it, but it doesn't scale very well, lacks advanced object support, and doesn't support advanced SQL (subqueries, nasty joins etc.) Please folks, do NOT take this as a flame against MySQL! I love it and I'm actively developing a project that depends on it! I just recognize it's (current) shortcomings (as I see it).
If you're going to have a "configuration repository" why not make it hellishly exstensible and enterprise ready by packing a punch with your (O)DBMS backend?
And by the way, how the hell are you doin? ;) Long time no talk....
--
There is of course, Mozilla and Xul. Also, I think AbiWord uses XML, or an XML subset, for it's (future?) configuration file.
If this isn't defined, one of the valid options is for us to attach an electrode to your chair and electrocute you :-).
Why not
That is an interesting idea; two problems:
The tools presently available are generally parsers, and have nothing to do with the grotty work of file locking and error detection/correction.
As such, it would represent a useful inclusion into Linuxconf.
At some future time, when there is actually some useful configuration information managed in an XML repository, and when there is a scheme not only to read, but also to reliably write, XML, it would then prove to be a useful inclusion.
Until there is something of comparable functionality to libPropList for both read and reliable write, I'll remain skeptical of the usefulness of XML for storage of configuration information.
If you're not part of the solution, you're part of the precipitate.
If there is a lot of data, as might be the case for things like mail routing tables, there is also merit to having a random access mechanism so that the data doesn't have to either be stored in memory or parsed repeatedly.
This is one of the merits of the CDB system; it provides a "binary" form that is rabidly fast but which also can be rewritten from scratch with exceeding rapidity.
Approach that supports both needs:
The two merit to CDB in this regard are that:
I once "compiled" a file into hashed form, and got about a million keys inserted in 17s on my PPro box.
There is no temptation to change the binary form, as you can't modify what has already been written out to it.
This means that the text form stays as the true data source.
Noticing that the system needs to "recompile" is the one "problem issue" here; it is not exacerbated by this approach as it would be equally true for a purely text-oriented scheme.
If you're not part of the solution, you're part of the precipitate.
Yes, indeed, it would be a monumental effort to get everything in /etc rewritten to use a set of XML-based data files.
The big deal is not merely that of getting something working, but also to ensure that a robust system results. As you say, "what if ... it is corrupted or incorrect?" The XML standard provides no guidance here, and there are liable to be three answers, not one, which will muddy the waters further.
If you're not part of the solution, you're part of the precipitate.
Are there some that do reliable write, e.g. with file locking, backups, and automated backout if it encounters errors?
If you're not part of the solution, you're part of the precipitate.
However. It is not all fine and dandy.
The "configuration problem" has not one issue, but several:
XML represents Yet Another Format; it is of value if it pushes out some of the existing formats. If it merely augments the population with another, there is no win here.
Result: Ambiguous. XML might provide value.
The issue here is that you need to ensure that the configuration is written out correctly.
This may require writing out the new config to a new file, validating that it is readable and correct. (Oops, made a mistake updating /etc/inet.d. Now the system won't reboot...)
There is merit to having a "database form" ala IronDoc where the physical representation is a database system, which provides a somewhat different persistence model than the typical text file.
(Before people start proposing that I be shot, I tend to favor the notion of, if using a binary format, synchronizing it carefully with a text format.)
The merit of a "databased" scheme, which should provide a separate database for each facility, is that updates can be implemented "instantly" without needing to rewrite a whole file, and without a need to parse the file. Note that even in a situation where XML is used as an interchange format, there is still merit to storing the "tree" in database form. David McCusker, author of IronDoc and architect of the (regrettably failed) "Bento" database system that was part of OpenDoc, suggests this very use for IronDoc.
For those that feel religious about using text files, a system like libPropList still has merit over the "let's do something with XML" idea since it has, already debugged, the locking, parsing, and config-file-rewriting code that let's use XML, it's k001 doesn't inherently provide.
In short, deciding to use XML merely establishes a format; it does not resolve that:
Michael Stonebraker (of fame with such developments as Ingres and Postgres) has most recently founded a company called Cohera based on the Mariposa Distributed Database Management System. This tool allows many databases to work together to process queries.
The "obvious" implication of this with this thread is that a valuable thing to be able to do is to join together many "databases" that are configuration repositories, and provide a central way of getting at the data.
The critical thing that is necessary is for configuration repositories to provide some sort of "metadata" so that they, in effect, publicize their existence.
A "federation" tool like Linuxconf, Ganymede, or such, can then be used to join together the metadata and manage it all together.
Unlike the situation with the infamous Windows Registry, this doesn't force all the configuration data into one fragile binary DB; it allows the data to stay wherever it was concluded that it should reside.
The critical factor here is not that data files all have a common format; it is that there be some way of translating their data into a common format.
XML has a lot to offer here in terms of providing a central "presentation" format. It could offer more if tools were available to make this a two-way street, where updates done to the central XML could be pushed back to the individual configuration data repositories.
However. If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction.
Conclusion: XML may have value to offer in confederating config information.
That has to come along with a whole lot of coding effort to build robust configuration data repositories that may or may not use XML.
If you're not part of the solution, you're part of the precipitate.
Just to pick nits here, the Windows registry IS NOT a single, monolithic file. On NT, it's the contents of \winnt\system32\config, a bunch of files.
Of course all the other things you say do apply, and in fact it makes no difference, it's still an impenetrable black box, and irreparable given a basic text editor or shell (DOS) commands as your only tools.
"The number of suckers born each minute doubles every 18 months."
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Thanks for all the information, but it still doesn't explain: what does XML DO?
Does it replace JavaScript?
Does it replace Java?
What is required to implement it - a web browser that "does" XML? - an office app (like Word or StarOffice) that can parse XML and execute it's "commands"? Is it a programming language? If so, do we consider it to be an "interperated" language? I really don't understand it's use for doing configuration files - though your explanation of what XML is is the best one I've read so far. (most explanations, including the dissapointingly LAME-ASS one in Scientific American, simply say - it's a way for people to create their own extensions to HTML - without saying anything about how those extensions are implemented or acted on, and how a specialized extension is used on a system that doesn't know the extension (platform-specific code? browser plug-in? what? how?)
"The number of suckers born each minute doubles every 18 months."
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
But in order for those specific definitions to be useful/renderable/recogizable on everybody's system, some piece of code somewhere on that system has to know what those tags mean, and knows how to do the specific things that that tag requires - and that's where I'm having a problem with realizing the usefulness of this technology. How do you get that code onto your client's machine, and why is it any more useful than Java?
"The number of suckers born each minute doubles every 18 months."
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
Someone else mentioned the likelyhood of, say, a /usr/lib/sgml-like directory where system-wide XML configuration files would be. An alternative could be /etc/sgml, /etc/xml, /etc/config, whatever.
/etc/sgml/remote and an /etc/sgml/local and update everyone's $XML_CONFIG_PATH appropriately.
The point is that if we establish a standard system-wide configuration path, it would be pretty easy to do what you're describing using traditional remote FS techniques.
If you wanted some apps to be remotely configured and some locally configured, create an
In addition to the other poster's comment that you can use < to represent < and > to represent >, you can also simply use the "Extrans" posting method (versus "Plain Old Text"), which automatically does these conversions for you.
Like another poster said, so long as they have a basic grasp of the XML libraries that exist, it's just a matter of calling the library's parse and write functions to read and create your own application-specific XML files.
Though learning XML would most certainly be a huge advantage, but it's hardly necessary. It's pretty easy for a non-XML-savvy person to edit an XML configuration file. It's not too difficult to figure out.
A libxml already exists. In fact, most languages already have some sort of library support for XML.
The support is there, the libraries are there. It's just that there's no "config file standard" yet and developers haven't really looked into it.
Once it comes of maturity, we'll be looking for uses within the Jabber project, http://www.jabber.org
-- I'm the root of all that's evil, but you can call me cookie..
Was simply an example.. ANYTHING could be used to store the database, merely used MySQL becouse of the typical slashdot reader.. ;-P
-- I'm the root of all that's evil, but you can call me cookie..
Not really.. With the XML wrappers out there, it's be fairly easy to parse in a file, and get the data from it. For general configuration data, this would be rather simple, becouse it's normally just key=value pairs..
-- I'm the root of all that's evil, but you can call me cookie..
One project that will eventually come out of the Jabber IM project is JNX, which would be expanding certain *nix functionality with XML data storage/routing. This actually goes one step further, and allows any program to transfer data to any other, by sending XML 'streams' of data. With the right transports, one could extend it further by having a 'Configuration Repository' for the system, which could actually store configuration data in something like an XML flat file, or even a MySQL database. Imagine 100 *nix desktop systems, all controlling their configuration via XML and a centralized database. This is some of the things that we will be looking at within the next year or so. www.jabber.org
-- I'm the root of all that's evil, but you can call me cookie..
The version of awk that handles XML data is called Perl. I thought you'd heard of it :)
,hacker Perl another Just)'
And then there's sgrep.
Damn all these tools for moving us into the 20th century.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
NetInfo is part of Apple's Darwin and thus Open Source now. I believe someone's even ported it to Linux.
The game project I'm working on uses XML for its network protocol, its database stuff, and (some) configuration scripts. We've explored a lot of the available parsers and run into some issues but no major sticking points. The two key issues:
Streaming - To use XML across the web it is nice to be able to stream XML packets (e.g., object definitions) and collect them client side and make use of them in real time. None of the current parsers provide this adequately, although several are working on it. We had to develop our own library for streaming this stuff (libAtlasWF). It's focused mostly on real time 3D information transferral, customizable by receiver to filter out unneeded information. It's generic enough to be useful for a wide range of applications, though we're using it for game systems.
Binary - A major requirement for games (and other applications) is binary formats for performance reasons. This was a major argument against XML until we realized that the XML tags (and lots of the data) could be rendered in binary simply by replacing tags with particular bytecodes and such. Probably not as compactly efficient as a custom binary code, but extraordinarily flexible (e.g., develop in ASCII XML, then just flip a switch to go to performance-oriented binary, and redefine binary tags as needed).
We're calling this real-time, 3D, binary-ready protocol "Atlas". We'd love your input (and help) in bringing it to any application that could use it. We invision client applications that understand XML-Atlas and can communicate with any server talking in this language, and a variety of specialized servers doing the same.
Here's some links to information about Atlas: Atlas Version 1.0, and WF Protocols
Bryce
Isn't there anybody who is interested in accessing their configuration files over the net? Rather than require that most applications use XML parsers and input from XML files, we should have a common, internet wide, infrastructure which will:
.bashrc aliases and so on.)
1. Allow you to store all your configuration files in a common store accessible over the internet (and with appropriate access controls)
2. Be able to use each others configuration files as example templates
3. Provide a uniform mechanism for a user interface programs (such as linuxconf) to manipulate the configuration.
4. Allow all linux clients on a network to use
common configuration information from central server.
XML will obviously be a candidate for holding the configuration information (the HOW part of it) and LDAP will be appropriate for WHERE part of this infrastructure. I would make my configurations accessible using my own LDAP server; and allow myself to use my configurations from other systems on internet.
We could have a freshmeat-like repository for this purpose, and allow people to upload their configurations (as templates) when appropriate. (Examples of such templates are configuration files for packages such as mutt,
The package specific offline tools can be created independently by each package owner (who will also decide the DTD).
-Vinod
It seems the poster wants XML introduced into all applications - not really the Kernel. I don't know many places where the Kernel would benefit from XML - except for the one configuration file the code itself wouldn't need XML.
I think what is being addressed is more an application issue. That would need to be addressed to many different vendors simultaneously. For instance: Apache config files, WuFtpd/ProFtd/etc files, Gnome/KDE config files...
I could see a lot of reusability for a config file parser for application development. But it would seem like the development tools would need this XML ability and not just everyone using XML. But I imagine that C/C++, Perl, Python, Java, etc already have XML parsers/creators. So really people are waiting for developers to embrace XML.
Does anyone now embrace XML? What are the advantages of XML over other config file parsers? Are there other standardized config file parsers? I know I've written my share of wheels in different languages for parsing config files.
Joseph Elwell.
IMHO, the *real* win of XML is not in replacing plain-text configuration files, but rather in replacing binary file formats and simple databases. One example would be word-processor file formats, which are usually a poorly documented, poorly structured binary mess. XML makes sense there. Another example is the Windows registry.
But XML is a significant *disadvantage* for the plain-text configuration files that dominate the Unix world. Generally, those plain-text files have a comment mechanism to clearly explain what needs to be edited. Adding XML will just add a bunch of unnecessary tags that will make it difficult to hand-edit configuration files - and the ability to easily hand-edit the human-readable configuration files is one of the most powerful advantages of the Unix Philosophy.
What i would like to see in the Unix/Linux world is a GUI that is capable of managing the entire OS via simple graphical tools, but doesn't *prevent* hand-editing of configurations. I don't see XML as a significant boon in that regard.
---
Maybe that's just the price you pay for the chains that you refuse.
Hand me that airplane glue and I'll tell you another story.
Yeah, why not GUILE instead? Stallman is right when he says (I paraphrase) that most scripting languages (and configuration languages) are simply poor implementations of Lisp. What needs to be done is to take the *semantics* of a language like Scheme, and get rid of the damn parentheses. :-)
Actually, I kind of like Mathematica; the notation is related to the original M-expressions for List (see Guy Steele's "The Evolution of Lisp").
An extension to add Karaoke/sub titling should be found here. I say should, because the link does not work right now (strange), so I provide a link to this mail. This should give you a basic idea until the link is working again.
Don't know much about XML but it would be one more thing a person would have to learn before they could begin to write an app worth using. Could go either way, should improve the software that is developed, because you wouuld have to know all of the tools. But it might also deter some good programmers who don't want to learn/don't have time to learn/or are to stubborn to learn a new way of doing things. It might still be easier to parse your own config rather than including a library and learning how to use it.....
Funny and I thought Perl == Paid employment recently located
Mozilla currenly uses Javascript style configuration files (prefs.js) which are basically the same as the ones used in Netscape Communicator. So I don't see XML config files in the forthcoming Mozilla release, however Mozilla does support XML so it could be a possible configuration file format in the future if anyone actually feels it will be of benefit.
--
Maybe an XML front-end to existing configuration file?
I mean an XML file format that describes existing configuration files, so that the new XML-based configuration tool will be able to access old files as well in the same environment. I wonder if that's possible...
okay, add also: /etc/hosts smb.conf and in comes instant remote management!
Absolutely Correct!
Right now XML is "the thing" (TM). Does that mean it's viable for all applications? No! Is it viable for this? Who knows, but lets not jump into it before it's been tested!
There certainly are advantages, but they've been mentioned so I'll skip 'em. On the other hand, there are a good number of disadvantages. Things like: larger data overhead in the conf files, Less readability in conf files, progammers would need to learn XML (which many of us don't want to!) and XML might not be adequate for everyones needs.
That being said, if you wish to proceed, pick an app and convert it to using XML conf files. See if it goes over.
However, one thing I would love to see is a unified method of getting config info, regardless of file format. Something along the PAM lines so admins can just drop a module in and suddenly the linux box can draw all of its config files from a central server! As an admin, I'ld love to be able to configure all aspects of every linux box I admin from a central server.
** Martin
I've been working on ideas for a new Linux distribution (yeah yeah, flame on) that's based around CORBA and XML: backend objects convert a normal program's configuration files into XML and back again, communicating with whatever frontend program you want to write (a java applet, a command-line program, a GUI, whatever). So Apache's httpd.conf gets rendered into XML, the XML gets edited (by whatever means), then the edits get handed back and the backend program converts it back into an httpd.conf file.
There are three specific advantages to this, as opposed to making every program use XML for its configuration:
1. Some programs are just optimized for a particular parsing style. Apache's needs differ from sendmail's, which differ from inetd's. There's no reason each program needs to use XML internally.
2. It's backward compatible. My hypothetical distribution wouldn't need to make major patches for every new release of every daemon in existence. It's also forward compatible, because it doesn't require new daemons to use XML either.
3. It doesn't piss off the "tomsrtbt and vi at 3 am" people, who either by necessity or choice want to be able to hack directly on configuration files.
Does this turn into a "Windows Registry"? No. The only differences between Linux and the Registry is that the Registry is binary, and that it's all in one place-- Linux configurations are scattered all over. This method lets you edit all configuration files using a single tool, but it doesn't give up the ability to hand-edit files if necessary.
The other application XML has in this distribution idea is for package management. Instead of a proprietary format (RPM, DEB, whatever), we have an XML "manifest" or "spec file" in a tarball along with the relevant files; the XML file has a well-defined filename, and tarballs can be created anywhere, without installing any additional software. This doesn't burden software developers with the need to make special arrangements for binary distributions; by including such a spec file with their normal source distribution, they've effectively created an "SRPM" without any additional effort. If they want to package up binaries as well, more power to em; otherwise, someone else can.
Nothing worth doing is worth doing today.
now, a GNU reference implementation of some XML DTDs would be nice. without it, XML is another hatchling produced by commercial vendors. The point of XML is to separate you, the buyer, from your current technical commodities (eg: ASCII, HTML). that's just my opinion.
How can they feel the rain but not know of the flood?
I think it would be interesting to look at standardizing some baseline configuration files, or to explore if this sort of consolidation is possible. Given the number of XML parsers out there (in C, C++, Perl, Python, Java, etc..) it should be reasonably easy for people to use this in their own applications.
Linuxconf is not very good. It also needs modifications (or maybe it has modules of some kind ?) for every new tool you want to add.
A suitably general DTD for application configuration would allow a single tool to read the config file for an app, generate the appropriate GUI, and let the user mess with the configuration.
I think XML would be just fine for configuration. If nothing else, it would help us standardize on *one* comment style in tool configurations. Right now, I have to guess - is it #, //, %, or what?
The biggest problems are that XML adds more verbiage, a good DTD has to be designed, and a bunch of tools have to be hacked to understand the new format.
It's very tempting to hope that XML will solve all the problems that config files cause. I don't think that it would get us that far.
.emacs files. Each config file is really a program in a language that can at least do ifs; it would be great to replace all this little languages by one consistent language, but that replacement would help the computer little to understand the semantics of the config file - and therefore no go for the grand unified config editor.
The main purpose of XML is to add machine-readable semantics to data by marking that string up as an address and this string as a last name. To create the grand unified config DTD, we would need to describe the semantics of all those config files in a grand unified way. For simple config files of the key-value type this would be great: mark the key 'background' as <COLOR> and the config file editor knows that a color chooser needs to be popped up. A config DTD would at least relieve the burden of writing yet another crummy key-value parser and make all kinds of config editors possible.
For other kinds of config files this seems very hard. For one, many config files are really written in some kind of (often braindead) language: think of sendmail.cf or procmail files or
XML is just SGML with a few esoteric, seldom used functions removed that make XML easier to parse.
Also, XML permits "well formed" documents to be parsed without the need for a DTD.
You can use all the existing SGML tools to read and write XML as well.
In short, I think XML is more useful than SGML because it is simpler and a little more permisive.
It isn't more useful than Java. It gives Java something to do!
XML is used to define the syntax of a data format. Someone must write some code to add the symantics (meaning).
Java has syntax and symantics. The syntax defines how you may put characters together into a file that the parser section of the Java "compiler" will accept as correct. For example that "a = a + 1;" is a correctly formed Java statement.
The symantics of this statement is given meaning in another part of the Java "compiler". It is this part that generates the byte codes that will cause the value stored in the variable "a" to be increased by one.
XML is used to define only the syntatical part of this duo. It is left as an execsize to the student to create the software to add the symantics. The fact that XML parser libraries are avaliable just makes the job a little easier, but there's still plenty to be done to have a complet and useful system.
Don't get caught up in the hype. XML is, IMHO, just another tool in our arsenal. Only use it if it makes sense.
FreeBSD already uses a database system for information from /etc/passwd to improve performance on sites with a large number of users. Parsing a ten thousand line file every time you want to login, print username for ls/ps/etc. is not very efficient design. Databases solve that problem.
The /etc/passwd and /etc/master.passwd (shadow passwords) are there as usual, but there are also /etc/pwd.db and /etc/spwd.db. You make your changes to the regular password file and then run pwd_mkdb. Vipw, chsh, etc. handle this automatically. The getpwuid and getpwname functions in libc read the database version, providing a real improvement on systems with a large number of users.
I haven't heard of any reliability problems with this system, probably because vipw does proper locking of the database, and if the database ever did get corrupted it's easy to run pwd_mkdb to rebuild the thing from the traditional text files. The regular /etc/passwd files also provide backwards compatability for programs that don't call the database-using libc functions.
FreeBSD (and probably other BSDs as well) made this change a long time ago and haven't looked back. It really does work well.
I have been working with XML pretty much since it's inception, having been involved in the development of the first viable internet XML Search Engine at http://www.goxml.com. While we are totally a Linux/Unix shop, we do recognize that Microsoft is actually doing a good job of pushing the XML Development envelope. A lot of the time many of us are really frustrated with the slowness of the w3c in making a technology standard. M$ is just really anxious to use XML and are not prepared to wait on the w3c for everything. It is also interesting to note the the w3 org is basically an industry consortium, of which m$ is a major delegate, their "Bastardizations" may in fact become de-facto standards, mainly as a result of early adoption of their extensions (xml-data, schemas). Their "BizTalk" initiative marks a big change in their strategy, they are actually moving toward an open document exchange standard. The fact that they make money from it by selling biztalk servers is beside the point, as you are totally welcome and free to make one yourself. Give them a break, I know for a fact that the Microsofties are not all puds.
--------- Matt
Here is an idea, don't reinvent the wheel. http://www.biztalk.org. Like M$ or not, it is a solid standard, and a perl api will be out soon.
--------- Matt
XML is a wonderful thing, and would be far superior to the current way we store configuration files (haphazardly) in Linux. However, binary files may have an arguable advantage - space and speed. I don't know why everyone is so opposed to copying the Windows Registry idea. Granted, you can edit XML with a text editor, but if every Linux distribution which used a "registry" for configuration came with command-line and GUI tools to edit it, and resonable precautions were made for redundancy and backups to protect the database integrity, who could object? After all, even "text" is really a binary file.
What we do need is a CORBA interface, provided through GNOME (or KDE if you will), which would allow editing of configuration information without knowledge of the specific representation. Then we could use XML or some kind of binary database, and the software using the CORBA Configuration Interface wouldn't care. Software unaware of this CORBA mechanism could do it the old-fashioned way, be it text manipulation of XML files, or libxml, or whatever.
By association, we can assume (having never even used XML) that it is cool as well.
By this logic, one would assume that SGML is really, really, wicked cool, being the granddaddy superset.
Back in the day, I wrote all my term papers at The 'tute in Scribe, before TeX and LATeX came along... Scribe fizzled and is hardly remembered, but it apparently was a direct progenitor of SGML, which became the framework within which HTML and, more recently, XML were defined.
The XML gods have done a remarkable job of finding a delicate balance between the flexibility and completeness of SGML vs. the ease of understanding HTML.
I, for one, would love to see XML become a prominent technology. A project such as this, if it catches fire in the GNU/Linux marketplace, would be a nice proof-of-concept and could help move XML into prominence.
Bravery, Kindness, Clarity, Honesty, Compassion, Generosity
...Nothing interesting here. Just move along...
As long as there is an XSL to translate it back to normal format :)
Look, XML is great for moving info between apps;
nice nested tagged data, easy to parse.
But DO NOT replace the common config files with XMLised
goop! Many of use use plain text editors to
control configs, or many and varied simple tools
to batch edit them. This is very easy with the common line-oriented configs.
Moving to XML will: (a) break every automatic script out there, (b) piss off everyone who hand edits these files.
Plain text configs are a BIG WIN.
Maybe for complex configs with weird nested data structures this might be an ok idea, but even then I'd
go for something terser than XML (even the broken XML-with-short-closing-tags is too verbose).
Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
Glade does something like this. It will produce C, C++, Ada source code or an XML file describing the GTK application. With python you parse the XML and then use a build tool to build the GTK objects as they are laid out in the XML by Glade. You just have to attach the events to code that you write.
:-).
While I see a great possibility here of having a way in which the author gives the user GUI elements and a set layout that the end user can change, the implementation suffers from the same problems that almost all XMl suffers from.
First, very few people understand the full scope of XML and all the adjoining technologies. The only way I understand it is putting it into the same perspective as SGML, but that doesn't cover many of the other parts. I guess most of us are waiting for an O'Reilly book on it.
Second, part of XMLs power is the way it can be used for almost anything. Part of the reason of it not being universally excepted is the the way it can be used for almost anything. Has anyone seen XML used the same way twice? From what I can see this has resulted in a lack of tools to deal with XML from beginning to end. Yes, you can merge a lot of tools to do some really amazing things, but it takes a lot of time and mental effort to come up with these chains of tools (much more so then other chains of tools).
Third, the resource consumption for most XML based projects is high. High enough that it will limit the viable uses of XML in the short term. Building a large GUI from XML may increase the start time of memory consumption beyond where it is usable for some applications. Netscape already loads slowly, if that time were doubled I'd be looking to use lynx for most everything (half
Agreed, for a programmer this wouldn't be an issue, but if we ever want to get some real market share from MS we have to use the K.I.S.S. ideology (Keep it Simple Stupid). Anyone can open up a text editor and read the entries of a file to some sort of tech support group, trying to read a database on the other hand wouldn't be as easy. IMHO sticking with flat files is a better bet.
I have no problem with the use of a database, I have some reservations, but no strong objections. Though who would create such a database? It would either have to be something built into the kernel...(doesn't really belong there). Or we may end up with a configuration databse holy war. I can see 2 seperate, but equally useful, implementations in use. Both strongly supported by deticated users. This would force App programmers to support both adding more work to their job. Truthfully besides database corruption that is the only other problem I can come up with for a configuration database, except for the inablity to edit conf file with a text editor.
As I said in my original post I think XML conf files are a great idea. I just wanted to mention that people are using XML for database migration and someone might try to do this with conf files, which IMHO is not a great idea.
Personally I think XML would be a great way to help organize all those sometimes nasty .conf files. There is one large pitfall that needs to be avoided. XML is very easy to convert to a database system. One of the main uses it has (at least in my experience) is a great way to abstract out databases in a non-proprietary format. If XML were used with wrapper classes to access conf files some people might be tempted to port those conf files into a database and change the wrapper library to a database wrapper instead.... to a naive user (how many of these are there now?... but in 5 years?) there would be no difference. What would we end up with? A Windows like registry system. I believe this should be avoided at all costs. A database system may look nice from the outside and have lots of great features, but when something goes wrong and the settings for your favorite daemon are in a corrupt database entry what are you going to do? XML will provide the organization linux conf files need and allow the existence of the flat files everyone loves, but also presents an easy step toward database (registry) systems.
Whoops! I double checked. libxml comes with two license files, COPYING (GPL) and COPYING.LIB (LGPL). I missed the second one, read the first, and assumed that since it said "GPL V2" is was indeed GPL V2. Nothing in the README file though.
A Government Is a Body of People, Usually Notably Ungoverned
Although not "fully grown", libxml will do what you want it to do. However, it has one major drawback: it is a GPL, not a LGPL library. This means that only other GPL programs can make use of it. Since libxml is part of the Gnome libraries, this is normally not a problem as all Gnome applications must be GPL (hmmm, are LGPL libraries allowed link to GPL libraries?). However, the question was wondering about broad XML support, and thus libxml won't work for other licenses such as BSD, Artistic or MPL (a lot of XML utilities are licensed under MPL).
However, there are two other C/C++ alternatives. The first is expat which is a C library that's pretty extension with extremely liberal licensing. The second is still beta, it's a new feature in the Qt 2.1 snapshot. The KOffice project is using this. There are, of course, dozens of Java and Perl XML libraries as well.
I don't think that you will ever see one single XML library for all purposes, but there are enough XML libraries available now in a range of Free licensing and languages that it won't be a problem.
A Government Is a Body of People, Usually Notably Ungoverned
What you do to put tags into a Slashdot post is you escape the angle brackets. For example, instead of putting , put <. And, of course, represent & signs as &.
--
Do I look like I speak for my employer?
See here. Duh. Its LGPL.
LGPL libraries can link to a GPL library, but then they will be GPL'ed. Unless there is a source and binary compatible implementation of the lib in non GPLed form - for this you could make a stub, pretend its work in progress, and still use the GPL'ed library in reality if you don't feel like abiding by the spirit of the GPL. This is a bit evil though.
It is not very reasonable to define XML as something human-readable. A human is forced to read the fairly-cryptic DTD, and then apply that knowledge towards the structure of a document.
I find it much easier to say something like: echo "nameserver 192.168.1.1" > /etc/resolv.conf than to spew several lines of XML header followed by the arbitrary, possibly multiline contents of a tag or nested set of tags.
Simplicity in reading, writing, manipulating and parsing are all positive attributes in a configuration file format, and XML fits few or none of those critera, as far as I understand. In a pinch, I can use very simple tools (such as those built into ash or found on a rescue floppy) to fix a configuration problem, whereas with XML, a layer of complexity is added to that task which is extraordinarily unnecessary and possibly irksome under the circumstances.
I've been dreaming of this for a while. Just think, all the config files are still text, but you have the option to configure anything using a generic curses or X-based program. Or you can still use good-old (insert your favorite text editor here).
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
A common dtd is good if you want to exchange the xml data that it describes among different applications. In the case of a document or spreadsheet, this is clearly a good thing. However, I don't see people developing a pressing need to exchange their configuration files between different applications. What other application could possibly have a use for a sendmail configuration other than sendmail?
If each application has its own configuration dtd, then editors can use that dtd to help the user write a valid config file. It can specify required tags, optional tags, and describe the structure of the file. Rather than using generic tags like <item id="username">Ethan</item> you can have <username>Ethan</username>, and this way the dtd can require the username tag, so you don't forget it. A common configuration dtd would be far too generic to be of much use in this.
Consider this already done.
Check out Allaires contribution to XML: WDDX
isn't that what linuxconf is?
"Subtle mind control? Why do all these HTML buttons say 'Submit' ?"
ReadThe ReflectionEngine, a cyberpunk style n
The place to start is linuxconf-- it's already trying to be a central warehouse for modifying configuration files. It would be a great testbed for the DND's used for various system configuration files. It's already got lots of code to bidirectionally parse many config files.
Having small modules to filter the XML's into the appropriate config files is a small price to pay for a robust development strategy. (Don't touch the application until the new form is proved to work.)
I don't happen to be working with such an application at the moment, but I am enhancing some Linux documentation with XML-type labels. Not that it will be directly visible, as it will only be used in producing other documentation. But you can just pick a corner you like and start painting.
and there I was getting all excited about starting a cool project -- fame, fortune, free coffee mugs.... :)
Thanks for the tip.
Save the whales. Feed the hungry. Free the mallocs.
XML in place of the current config files would have some advantages. For one thing, it would allow use of a single high-performance parser to parse the files. The days of writing/copying a config file parser for every application would be over. Perhaps we could create a shared library to do this. (If there is any interest in a libxml.so, please let me know. It sounds like a cool project.)
It might reduce version control issues in some cases since new/unknown tags in XML can be ignored (much like unknown HTML tags are ignored). However, a well-written config file parser would do this already.
It would probably speed up the process of creating GUI front-end configurators, since the parser/generators could be reused. An advanced user without a GUI configurator is like a fish without a bicycle, but it would be helpful to newbies and regular desktop users. The "Linux is hard to use" argument would start to go away.
There are some big drawbacks, though. The first is that tons of applications would have to be revised in order to read XML config files. In an open-source world, this means a long painful process where some developers switch to XML immediately and others wait a while. Then there is the pain of converting your customized http.conf/fstab/.profile/etc (bad geek pun intentional) files to XML.
Also, there is the fact that most of the cool tools in Linux are really designed for all of the Unix world. Realistically, the Linux environment can't just switch over to XML config files unless the entire Unix community does.
Maybe future apps should use XML as their config file format. I don't see our well-worn existing tools making a switch anytime soon, however.
Just my 2 cents.
Save the whales. Feed the hungry. Free the mallocs.
Space and speed are cheap, especially given the negligible cycles required to parse config files.
Part of the Unix philosophy is that the pervasiveness of text is considered a feature, not a bug. Text is a good interface for many reasons. Three of the most important ones are:
- It is easy for a human who knows what (s)he is doing to hand-edit text. This becomes very important in cases like config file corruption or broken configuration tools.
- Text editors are well-understood and mature, and almost never broken: emacs, vi, etc.
- Most existing Unix tools are very good at working with text, making it easy to write scripts to automatically process anything made of text.
I don't know why everyone is so opposed to copying the Windows Registry idea. Granted, you can edit XML with a text editor, but if every Linux distribution which used a "registry" or configuration came with command-line and GUI tools to edit it, and reasonable precautions were made for redundancy and backups to protect the database integrity, who could object?Q: What is the purpose of a registry?
A: To provide a unified heirarchical view of configuration data and an API for accessing that data.
A heirarchical view of configuration data is provided by the Linux filesystem. An API for accessing that data is provided by stdlib.c.
Adding a binary database gives us exactly zero advantages over merely (a) standardizing the configuration file heirarchy under
Registries in and of themselves are not a bad idea. However, we don't need an opaque binary file coupled with a superfluous API in order to have a registry: we can implement one just fine using only the existing filesystem, text, and existing libraries. It would have all the features that you outline above.
~k.lee
(remove nospam for email)
What i'd like to see is a standard way to read/write too/from XML files using a standard C library type function call. Right now most C programs (and face it those are the majority) have a standard fopen(), fget(), fput() calls which make the database format fairly standard - ascii text in various forms. I'd like to see the equivalent in XML so read/writes can occur from XML files (no , i dont want to parse it manually in my C prog..thank you very much)...something like an add on to the standard C/Java/C++/Fortran libraries will be very nice. and it should be GPLed.
So rather than it being "another thing to learn" it can provide a simpler user interface.
Microsoft has already discovered a solution that will make those silly text configuration files completely unneccesary:
Let's give it up for the Registry!
The best thing about UNIX config files is that they are self-documenting -- the good ones contain comments that allow users with a basic proficiency to figure out how to configure stuff easily. The history and purpose of changes can be conveniently embedded. Putting aside its fragility, Windows' registry is broken because it is simply incomprehensible. Even sendmail.cf gives some guidance about what stuff means in the UNIX world.
But most UNIX config files are broken in that comments don't have a well defined place in the config file syntax -- they are just ignored by parsers. This is BAD. If config files are edited both by users and by automatic tools that parse and regenerate, all of this infomation and history can be lost. It is hard to code around this -- even if you preserve the comments, their meanings are location dependent and getting the location right in the face of changes can be nearly impossible.
The biggest win about XML is that instead of defining a comment syntax that parsers ignore, we could define a standard <config:comment> element which would maintain a well defined place in the structure of the files. Hackers could edit plaintext and comment, tools could edit and regenerate (and comment), and all the documentation would be well preseved. [Parser-ignored <!-- ... --> comments would not be used.]
This is a perfection, not a departure from the UNIX philosophy -- information in simple, human readable, machine manipulable ASCII files. We just need to take care that our DTDs are easy for humans to read, understand, and edit.
But the biggest win will come from minimising the proliferation of DTDs. If the community can co-operate on the development of common DTDs then the exchange of data between software agents developed by different projects will be hugely easier. By all means have diffrent projects - both KDE and Gnome have, in my opinion, benefited from the competition between the two - but if that competition develops the sort of bitterness which reduces communiction and co-operation we all lose.
I would strongly urge anyone who is developing a new software agent - whether it's a user-level application or a new daemon - which either stores data or exchanges data with other agents to seriously consider XML as a format, but more importantly should look at the DTDs that already exist to see if any will fit, and should communicate with anyone else working on related tools.
If anyone wants to look at the XML tutorial I gave at INET99 it's here
I'm old enough to remember when discussions on Slashdot were well informed.
the use of simple, separate, config files is that they can be moved, edited, built using simple sh, grep, awk, cat, vi, etc. commands.
XML is great. Although there are some places in which it doesn't fit in, it is as much a panacea as anything could be. XML basically is just a standard plaintext way of describing everything. RDF can basically describe any resource. AllianceOS is also looking at XML as a way of storing system configuration. XML is being used already as an application revision synchronization mechanism. It's being used for those little Slashboxes. I don't want to sound like a zealot, but I think XML is /the/ way to go. It can only help. Imagine standard installation routines specified by XML...XML system configurations and package formats...the list goes on.
XML IS overkill in some cases...some things are just so darn obvious tags would just get in the way...but I think at higher, broader level, XML can help very much.
It's 10 PM. Do you know if you're un-American?
I agree that XML datastructures could be filtered by a perl script into an equivalent LISP structures. In XML, however, you can see the equivalent of the closing parenthesis with your naked eye, without a browser designed specifically for LISP. Tcl is another dialect of LISP, but with brackets and braces and newlines to break the monotony.
(Reality reasserts itself sooner or later.)
I'm aware that it is (in a way) a superset of HTML.
We all know that HTML is cool.
By association, we can assume (having never even used XML) that it is cool as well.
Linux really could use a standard config system, and this is a proposal that sounds as though it really has some merit. Hopefully some guy at RedHat or Debian or Slack or YellowDog or TurboLinux or... (being distro agnostic here...)
hopefully one of the distros picks up on it.
It'd be cool. Truly Cool (tm).
From a motherboard manual, error beep codes: S-L-L-L-SS: Speaker Error
I've established a project to produce a lightweight structure document management system using XML. Essentially it is an XML DBMS. The project is still very very young, but is growing rather quickly.
http://www.dbxml.org
"one of the reason why you don't find so much tools like javadoc for c++)" --
Doxygen, Doc++ and KDoc are all variations of Javadoc for C++.
Stephen Molitor steve_molitor@yahoo.com
The more you stray from line-based text files that you can easily call things like awk and grep on, the more you'll alienate some people. I don't believe there's a version of awk or grep that handle XML-based records. This is pretty important to tool-minded people.
You can buy one, but is there a OSS ODBMS out there? XML really needs a good Object Database to make sense. Why worry about DTD's until the storage schema is developed. God I just got an idea, I need to go code...
It seems to me that using XML for general-purpose
config files is extreme overkill (would every
application need to submit a DTD?). Maybe for a general-purpose registry (like KDE is doing) it makes sense; one DTD for all apps. But I don't think we can expect a large number of applications to use such a complicated format as XML for config files.
On the other hand, a robust SGML library that can let applications manipulate DTDs and documents would be amazing! Linux would blow all
other contenders away if it provided a full suite of SGML editors, publishers and architecture tools.
I'm also curious why everyone is focussing so much on XML. Wouldn't SGML be a more powerful solution?
Let me make my point another way: if one uses S-exps, then one finds oneself looking at an awful lot of nested brackets. With XML, one sees that s match s, etc.
The second point about typing is that, whilst one may easily test whether an S-expression is well-formed, one doesn't need to. In my view, a volutary type discipline such as LISP/Scheme uses is less than half a type discipline.
Lastly, about ease of use: there can be no doubt that using S-exps with LISP/Scheme is very natural: all of these wonderful tools such as quasiquotation. Also very natural to use in a UNIX setting with scsh or guile. But this is a `one size fits all' argument: tools exist in other languages for XML, but they don't for S-exp. I think XML has the edge on XML for ease of reading, but I understand that may be debated; still I think the point about language support trumps the issue.
And I am not getting at Scheme/LISP: scsh is one of my favourite languages...
It should be possible to write a set of filters to convert between XML and standard configuartion files. Whilst this a lot of work to begin with (ie. such a filter for each different kind of configuration file, which is pretty much one for each different configuration file, if it was possible to begin with a biggie) such as the .xinitrc file, that might create the momentum to convert over the other applications. Writing filters of course obviates the need for the application writers themselves to rework existing code, which may be pretty much impossible with something like X windows.
Of course people have been saying config files should be LISP S-expresions for years; maybe the hype about XML will be enough to make this idea work...
Actually XML is a bit more general than S-exps in that it allows you to pass parameters, and specify that these parameters are optional, fixed, or have default values. Of course these can be simulated in LISP, but the ways XML handles them is cleaner.
Also XML has something resembling a type system in its DTDs, which seems somehwat alien to the LISP mindset...
What about using LDAP together with XML or other text/script configurations to build a single configuration framework for linux, just like the windows registry?
-- You are in a twisty maze of passages, all alike.
Thanks, I have written a couple of XML apps myself, and know it is text based. The distinction between what I refer to as "ASCII config file" and XML config file should be fairly obvious.
People creating DTDs on their own is not the whole point of XML. People using standardized DTDs that are widely accepted by the target community is. If you see half a dozen different DTDs for Linux app. configuration files, all supported by various(different) development groups, there will be added confusion to Linux maintenance and installation; which is already being used as FUD material by Microsoft and the gang. That will not be good.
The bottom line is: With XML, you're not supposed to "create DTDs for whatever task is at hand", if your application is intended to interoperate with those of other vendors, companies, etc. Industry groups already started to take the liberty of creating DTDs on their own with the hope that their DTD may turn out to be the de facto standard in the field; and that will cause major fragmentation in the near future. It is already happening in the e-commerce area with different DTDs being pushed by Microsoft's BizLink and Rosetta, etc.
Zigbee Central: A Zigbee weblog
While I agree this can definitely be another good way to use XML; I'm not sure everyone will be willing to abandon the ASCII config file formats they have been using for a very long time, and move to an XML-based configuration registry. But something like this has to be done sooner or later.
People are moving and creating DTDs on their own which has the potential to cause a huge fragmentation on the XML arena; so before someone tries to design a configuration DTD, there must be some concerted effort to start a group within the Linux community that will work on this and other relevant XML DTDs.
Just my 2 cents.
Zigbee Central: A Zigbee weblog
On the whole I agree with the Anonymous Coward about the basic equivalence of XML and S-expressions. However, I think that XML has four important things going for it: * The existence of DTDs provides a standard way to declaratively specify a schema as well as well-formed representations of that schema * The existence of XSLs provides a nice standard declarative way to seperate data structure from data format. * The momentum and hype associated with XML helps to assure the acceptance of an XML approach as well as the existence and longevity of tools, browsers, etc. -Mark
Any plain text editor can be used to edit XML files, but a structured editor helps enormously. I have tried out quite a number of (free and commercial) structured XML editors on Unix and Windoze and my favourite so far is the XML mode for Emacs, which is based on the excellent PSGML package. And it's open source and I don't have to leave my favourite development environment. Does anyone know of any other open-source XML editors?
Cheers
HH
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
Since XML is plain ASCII, just like HTML, standard ASCII editing tools and scripting languages can be used to build and edit XML files. XML is also easily human-readable, sometimes more so that standard *nix config files.
HH
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
It's not a traditional programming/scripting language like C, Java, Javascript or Perl. It's a meta-language for defining markup languages such as HTML or SMIL. You would use it for creating structures of tags to mark up data. These would look very similar to HTML markup tags, the difference being that HTML gives you a fixed set of tags (e.g. <P>, <head> etc.) whereas XML allows you to define your own.
The tags are defined in a Document Type Definition (DTD) which looks complex, but isn't that hard to write. This gives you an enormous amount of flexibility in what you use XML for. If you defined a slashdotter DTD as:
<!ELEMENT slashdotter (name, email)>
<!ELEMENT name CDATA>
<!ELEMENT email CDATA>
You could then write the following XML:
<slashdotter>
<name>A Coward</name>
<email>a.coward@slashdot.org</email>
</slashdotter>
This could then be displayed in a web-browser using a style-sheet, read into a database, used to send spam etc. DTDs can be defined for configuration files, spreadsheets, word-processor documents, or almost any data, which makes XML enormously flexible.
Hope this helps a bit
HH
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
I started out using XML for simple configuration files on a Java software project. Once we started to use it, we realised that it's extremely powerful and soon started finding many uses for it.
Expect to see XML cropping up everywhere soon. Microsoft (boo, hiss) is going to be using it for document exchange (XML is very good at this) in their Office products. There are rumours that M$ is already bastardising XML, rather than stick to the standards (now where have we heard that before?).
XML initially looks daunting, but really isn't too difficult to learn. There are some standard API's being developed (SAX and DOM), at least in Java. XML and Java work very well together. I haven't used XML with Linux, so can't comment on available libraries, if indeed there are any yet.
I certainly would encourage developers to look into using XML. It certainly beats writing your own parsers and you'll soon appreciate its flexibility. HH
Yellow tigers crouched in jungles in her dark eyes.
She's just dressing, goodbye windows, tired starlings.
I'm sure that there are a multitude of uses that XML can be put to on a GNU/Linux system. However, I don't think that XML is the panacea it's touted to be. Like Java before it, and C++ before that, and C before that, and Pascal before that, and Basic before that, XML is just another tool that's been the target of a lot of hype.
Certainly, you could implement a 'registry' in XML. The question is not "can you", but "what benefit does it provide and what are the drawbacks". The question of a "Windows registry" for Linux has often been discussed in the newsgroups and the usual response is: "What happens if your registry gets corrupted?".
By all means, develop an XML 'registry' tool, and/or enhance X to include XML attributes, and/or develop a new filesystem that uses XML as it's structure, but please don't expect that your development is going to replace the existing tools and features of the system. Like the ever growing variety of scripting languages, the only thing your development will accomplish is to add another choice to the mix.
Good Luck.
"values of beta will give rise to dom!"
I have heard/participated in many a similiar conversation and have a couple of thoughts --
1) I see the real added value of XML config files as this. Ease of configuration through applications (scripted or some GUI or whatever). The great thing about XML documents is that they can be self describing. Markups like: could easily be used to create "on the fly" interfaces to modify any file. If created wisely, a DTD could provide enough generic ability to accomodate most any resource file (why not X resources too?). Then, it would be trivial (compared to establishing a DTD) to create UIs that need not care about the data, just the fields.
3) And another thing, why not use it to describe hardware and devices.
4) How about users and profiles?
5) I could rave forever...
The point is -- using XML has little impact on the actual data but would provide a common and pleasant way to interface with the data (ie: manipulate, read, interpret (you could have comment fields, hyperlinks to help files)) -- none of this is out of the scope of XML. It just needs some agreed upon standards and a few champions. Arent Mozilla config files already stored in XML? and are Slash's config files not also in XML(ish)?
remember: "Good ideas go to waste on those who already know the solution" -- versil
ps: Many posters are pointing out unwillingness to learn new things or to change from old ways on the part of developers. Tough. This is how the future moves.
Imagine if you were to convert everything in /etc to XML. think of all the apps that already know how to read those files -- they would have to be rewritten to know how to extract useful info from XML (eg: bind, login, the inetd). A very daunting task indeed. Still, I am not opposed to the idea. I see a whole new system emerging based on the linux kernel...
XML is probably best applied where there is some variable structure data in some kind of nested format. For an excellent example of this just look at the un gzipped spreadsheet files from gnumeric which are XML. However, configuration data often doesn't require quite such a level of nesting and although XML solves object oriented data etc very neatly it seems overkill for configuration issues. A lot of configuration data is quite happy with the old "keyword=value" format.
:) .
... but that's going to an issue anyway no matter what the format.
If we ever wanted to implement a Registry for Linux (shudder!) then XML would be a good way, though why you'd want to do it is another matter
As a data interchange format it seems to me ideal, as long as the tags are understood at both ends
Bitter and proud of it.
I've been thinking about this for a while. different users want to configure their machines via different types of mechanisms: windows lusers like their gui tools, old school unix crustys like to use vi and remember cryptic syntax in a million different formats, sysadmins would like somethign that can be managed locally and rolled out across the network easily...
would it be a Good Idea to make something akin to the Pluggable Authentication Module? people could adapt existing applications to use a Pluggable Configuration Module of their choice; the PCM lib would then translate whatever configuration type of configuration information that existed into a generalized format and then feed it to the application. the app would only have to be rewritten enough to translate the generic generalized command format into the information that it needed, and then any type of configuration format is just a module away.
> ... and refactoring configuration information among dozens of software projects that aren't even necessarily aware of each other would be an interesting problem in change management.
:)
Heh. Droll, very droll.
Every serious code writer needs to look at GSLgen from http://www.imatix.com , a freeware XML parser and code generation engine. The idea is to have code write the bulk of code. Machine generated code is more precise, more easily maintained, and becuase you control the generator, you don't sacrifice control. Config files as XML is a step in that direction.
See the following: http://www.xml.com/pub/1999/09/serialization/index .html
Those who forget Amiga's IFF format are doomed to re-implement it, poorly.
I don't quite see the one to one comparison. I wouldn't call this reinventing as well, since XMLTP has been in existance for at least a year and a half. Gavin
I am working on an Open Source project called XMLTP. XMLTP seeks to standardize the transport mechanism for XML data. By taking cues from the Linux and Apache community, XMLTP.org is in the process of developing a standard way to send, receive, and execute upon XML data. By creating a common pathway, in the form of a client and server, a protocol, programming API's, and standard for formatting, XMLTP.org will provide a core technology to make XML more than just a web-based data formatting standard. For more information http://www.xmltp.org
The LinuXML Project is "devoted to changing the UNIX de facto standard for inter-process communication (IPC) and storage from line-based ASCII records to XML."
Check out the
There is indeed a version of grep for XML-based records. It's called sgrep (structured grep) and "is a tool for searching and indexing text, SGML, XML and HTML files and filtering text streams using structural criteria." It is based on the concept of regions, i.e. nonempty text substrings that are typically occurrences of constant stsrings, SGML tags, or meaningful text elements recognizable via delimiting strings or the built-in SGML, XML and SGML parser.
Check out the
... back when we were doing the initial work on wiring XML into perl. I managed to get hysterical storms of laughter out of the audience by flashing up 5 or 6 well-known *nix config files in increasingly ugly and baroque syntax. I forget the details now, but there was inetd.conf and fstab and httpd.conf and so on; all of which have multiple chunks of data encoded in text with a totally arcane ad-hoc set of syntax rules for fishing them out.
XML probably wouldn't actually be as easy to read as inetd.conf or fstab for someone who's used to inetd.conf or fstab, but there are those times when you pull up a conf file that's new to you and wonder what the author was smoking. Lesson - great programmers often design hideous config syntaxes.
The one that totally brought the perl conference house down was fvwm95rc.whatever.m4, I forget the exact name, which has an absolutely hair-raising melange of positional, functional, and from-another-planet syntaxes (and then had to be run through m4 fergosshakes. (why does m4 still exist?)
Anyhow, I think history has shown that a set of textual config files is a better way to run an OS than a set of dialogue boxes or a hierarchical binary 'registry', so it would be kinda nice if there was some common syntax out there. But even speaking as a certified XML bigot, it's hard to see how to get there from here. If I can help, let me know.
Cheers, Tim Bray (tbray@textuality.com)