Expanding the use of XML in Linux? 216
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. "
gnumeric uses xml today (Score:1)
Re:Same Thought..What about OSS ODBMS? (Score:1)
You can buy one, but is there a OSS ODBMS out there?
One of PostgreSQL [postgresql.org]'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.
Disadvantages of XML? (Score:1)
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.
Re:XML and Linux: a new distribution (Score:1)
Re:Who needs grammars or parser generation? (Score:1)
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.
The Gnome XML library (Score:1)
[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 [rpmfind.net]
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's all in the mind. (Score:1)
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.
Central XML registry for READING (Score:1)
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.
Eschew Buzzword Based Planning (Score:2)
Here is some info on XML (Score:2)
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.
The Gnome XML library (Score:2)
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 [rpmfind.net]
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
Who needs grammars or parser generation? (Score:3)
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
Re:XML and configuration systems... (Score:5)
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.
Re:Pluggable Configuration Modules? (Score:1)
great (Score:2)
Re:Jabber and JNX (Score:1)
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....
XML already in use (Score:1)
Re:Upsides, Downsides... (Score:2)
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.
Avoiding Binariness (Score:2)
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 [uic.edu] 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.
Agreed. (Score:2)
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.
Libraries to reliably write XML? (Score:3)
Are there some that do reliable write, e.g. with file locking, backups, and automated backout if it encounters errors?
Upsides, Downsides... (Score:5)
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 [hex.net] 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 [windowmaker.org] 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. [berkeley.edu] 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.
Re:Possible Pitfalls of XML (Score:1)
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."
Re:XML Everywhere (soon) (Score:1)
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."
Re:XML Everywhere (soon) (Score:1)
"The number of suckers born each minute doubles every 18 months."
Re:Upsides, Downsides... (Score:2)
XML isn't terribly difficult to represent with data structures. Thus, so long as you have valid data structures in memory, it shouldn't be much of a chore to write that out in a valid XML file.
Now, if the program poorly represents what it wants in a badly-constructed data structure, that XML, while perhaps valid XML, might not be exactly what the author intended. Unfortunately, there's not much you can do about it. A crappy programmer is a crappy programmer, and the author would probably just as easily foul up a plaintext configuration file.
Re:Eschew Buzzword Based Planning - Correct! (Score:2)
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
Re:ASCII, not XML (Score:2)
Re:Libraries to reliably write XML? (Score:2)
Do a search for XML [freshmeat.net] at FreshMeat and test some of the implementations out. If they don't have support for the reliability mechanisms you state, request or add them yourself.
I believe most of these libraries just generate the XML text and more or less rely on the application to write it out to file, so you pretty much have as much control to be as reliable as you want.
Developer doesn't necessarily have to learn XML (Score:3)
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.
Re:XML and config files (Score:4)
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.
Re:Shameless Plug, but Interesting you should ask (Score:1)
Re:Jabber and JNX (Score:1)
Re:One more thing.... (Score:2)
Jabber and JNX (Score:4)
Re:great (Score:1)
Why XML?
I don't see the added value in using XML for a configuration file format. XML is a great format for representing heirarchical (sp?) data. How is this helpful for config giles? Config files are normally sectioned key value pairs. In my experience, the easiest config file format is the old Windows INI file format, which looks like [section] key=value key2=value2 Not only is this format easy to parse, easy to read and flexible, it also has been used widely and many parsers for the format have been written.
It appears to me that most people who want to use XML for configuration files don't really understand XML, or don't really want XML. All they want is a localized configuration file with a common syntax. If you can provide a good reason for using XML in configuration files, please email me and explain.
Mike, who thinks GLADE is a really cool use for XML.
Re:Bye-bye grep and text tools (Score:2)
And then there's sgrep.
Damn all these tools for moving us into the 20th century.
perl -e 'print scalar reverse q(\)-:
NetInfo (Score:1)
NetInfo is part of Apple's Darwin and thus Open Source now. I believe someone's even ported it to Linux.
XML for Games (Score:3)
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 [worldforge.org], and WF Protocols [worldforge.org]
Bryce
Use LDAP to keep config files (in XML format) (Score:1)
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
Linux the Kernel. (Score:5)
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.
XML vs Unix Philosophy (Score:4)
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.
Re:XML? Hooray! (Score:1)
>XML parser that could (should?) become the
>standard: libxml, written by Daniel Viellard
>(he also runs the rpmfind system) from the W3C.
>It is already in use by the GNOME project.
While libxml is nice for simple parsing, it's not really satisfactory for larger applications making heavy use of XML, simply because it doesn't validate. Of course, there's always RXP, which does validate, is GPL, written in C, and quite fast. We chose to use that for a rather large document system we're finishing these days (soon to be released under the GPL, tell me if you're interested).
Re:XML and configuration systems... (Score:1)
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").
The CD Index uses XML (Score:1)
An extension to add Karaoke/sub titling should be found here [mp3.nl]. I say should, because the link does not work right now (strange), so I provide a link to this [cd.ro.nu] mail. This should give you a basic idea until the link is working again.
One more thing.... (Score:2)
Re:Mozilla uses JavaScript config (Score:1)
--
Re:XML and config files (Score:1)
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...
Re:Good Idea (Score:1)
Re:Eschew Buzzword Based Planning - Correct! (Score:1)
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
Re:Linux the Kernel. (Score:1)
You could have things like /proc/cpuinfo in an XML format. I can also imagine that in five years' time, things like the wire protocol for distributed filesystems will be in XML. Yes, it would be less efficient, but probably easier to code, more robust and more forward-compatible (discard elements you don't recognize). If you just had the 'header' or metadata in XML, and not the file data itself, the performance loss would be small.
XML and Linux: a new distribution (Score:2)
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.
Re:.xinitrc? (Score:1)
you could always do something like:
#!/usr/bin/xml2shXML code
and have this xml2sh program convert the user's XML version of .login, .xinitrc, or whatever to a shell script to perform the indicated actions. This could help get a lot of applications 'XML ready' without having to rewrite them all at once. As I understand it, the whole point of this is to have a common config file format that is easily parsed and edited by machines, so you could put together the intended XML configuration for a particular application by using xml2sh (or whatever we call it) to do a slower prototype version before committing to use an XML parser in the application itself.
de-commoditization awaits XML (Score:1)
Interest in a mail list/site? (Score:1)
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.
Re:Linuxconf? (Score:1)
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.
XML is good for configuration (Score:1)
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.
XML dreams (offtopic, I know) (Score:1)
Semantics and XML (Score:1)
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
Re:Why not SGML? (Score:1)
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.
Re:XML Everywhere (soon) (Score:1)
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.
Database config works great under FreeBSD (Score:1)
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.
Microsoft (Score:1)
Re:XMLTP (Score:1)
We need a CORBA interface (Score:1)
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.
Re:XML? Hooray! (Score:2)
> 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?
Several Linux distributions already include an XML parser that could (should?) become the standard: libxml, written by Daniel Viellard (he also runs the rpmfind system) from the W3C. It is already in use by the GNOME project.
See http://rufus.w3.org/veillard/XML/xml.html
Re:Wow, good idea! (Score:1)
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 [mit.edu] 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
As long there is an XSL ;_) (Score:1)
yuck! (Score:1)
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).
Glade (Score:3)
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
Re:Linux the Kernel. (Score:2)
We need a standard config database setup so that people can develop tools for (insert your favorite windowing envt here) to ease the configuration headaches that most users experience. Don't get me wrong, I like the flexibility of text based config files and I'd hate to be forced to use only one tool (like regedit.exe) but a central repository in a standard format would be a boon to sys admins everywhere.
Re:Possible Pitfalls of XML (Score:1)
Possible Pitfalls of XML (Score:2)
Problem with libxml (Score:2)
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.
Re:great (Score:2)
true, didn't think of that. You might want to consider storing it somewhere else though because the last thing you'd want is joe average launching turbo vi to mess up his config file.
"Such "generic software" already exists for flat ASCII text files. It is called emacs, vi, perl, sed, awk, grep, diff . . . the list goes on and on"
BS. It's not the same, if you don't see that you have a problem. I'm not going to waste my time trying to explain you the difference between a text editor and configuration tool.
"This isn't that shocking a suggestion, since it's been done. Those who have programmed ColdFusion Server's CFML language, to take one example, already know that XML-based programming languages tend to have heavy, verbose, and annoying syntax because you have to enclose everything in angle brackets."
Now that's interesting's I guess those guys were trying their generic vi/emacs editors on XML. Jesus! The idea of XML is definitely not that you open vi and start hacking away. Rather you build a tool that does it for you. If you really want to program good old c, just build a program that parses the file and converts it to C. This is also a great way to convert old code.
Imagine having the linux source tree available as a giant XML tree. Sure it would be big but you can always gzip it.
"One feature of markup languages like XML and HTML is that anything not enclosed in angle brackets is a string literal. This is good when you want to mark up content, but annoying for general-purpose programming. How much of the average program consists of string literals?"
I wasn't talking about enclosing the original source but rather about replacing it. I.e.
public void aMethod(int param)
{
a lot of other stuff
}
would become something like
a lot of other stuff
Now the fun part would be inserting tags like bla bla
smart ass
etc.
"The reason there is no javadoc for C++ is cultural: Bjarne Stroustrup did not decide that there should be a way to automatically generate documentation from code, and Arnold Gosling did. The task of parsing special comments, which is what javadoc uses to generate its output, is pretty trivial and would not be hard to do for C++."
The real reason is that C++ syntax is so complex he would have a hard time building the tool. Can you say #define? Now of course there are some Javadoc like tools for C++ but most of them place restrictions on the input. Javadoc does a little more than just parsing comments. It also parses method headers, class definitions. Since C++ uses a macro language rather than language constructs for all sorts of definitions, it is really hard to get decent documentation from the source code.
Re:great (Score:2)
OK, heres the xml with the brackets replaced with *'s you'll get the point:
*method name="aMethod"*
*param type="int" name="param"/*
*block*
a lot of stuff
*/block*
*/method*
Re:great (Score:2)
"Config files are normally sectioned key value pairs."
That's nice if you have only a few sections but if you have a lot of them you might want to organize them hierarchically. -> xml does this, ini files don't. Currently the solution for this is LDAP which is also a nice solution. The only problem is that it is a protocol rather than a fileformat. Technically you could probably combine LDAP with XML. It wouldn't surprise me if that already has been done somewhere since it is so obvious.
Windows ini files were a mess. It is good that MS abandoned them. The windows registry really wasn't a bad idea until they started putting com registration in. Then it became really messy.
The last thing I want is a localized ini file. What if I move to another place? right I loose all my settings. I want to store my settings on a central place in the network. With personalized configuration files for each program you use, that becomes really messy.
Database guys figured out years ago that flat files are not good for datastorage. First they invented hierarchical databases and later on they came up with relational databases. After that came object databases and now we have XML (which can be used to store objects).
So why use XML:
- rich, extensible syntax
- standardized
- easy to handle (it's just ascii)
Re:great (Score:3)
Using XML would allow us to separate the configuration files from the configuration applications and those could be separated from the applications that are being configured.
If some effort is made, a generic configuration program (or more than one think expert and novice user targeted software here) could be made that would work with any application that needs to be configurated. I imagine application creators could write an xml file describing all the properties in their application, with documentation included as meta tags. A generic configuration application would read the resource file and present a nice GUI for it. The entered values could be stored in another xml file. The administration possibilities are also way cool. Imagine having permissions on certain properties, default properties and user specific properties managed automatically.
The advantages are clear:
- platform independent, possibly even program independent (imagine having a set of default parameters that any app can use) configuration
- fine grained control on configuration for administrators
- user friendlier
- no more obscure textfiles in obscure places on your hardrive, no more
- advanced tools for configuring any application
Plain ASCII files with fixed syntax are obsolete. The revolutionary thing about XML is not it's syntax, not the way it stores stuff but the fact that you can define extensible syntax structures with it and that you can use generic software to read and write to it.
In fact I have an idea that may be shocking for hardcore UNIX guys (stop reading if you want to sleep tonight): why not replace the syntax of programming languages like C and Java with XML equivalents. The reason I would want to this is that XML is extensible so you could add meta tags to it. Imagine having author tags, documentation tags (in many flavors), etc in your code. The possibilities are endless. There may be some problems with the grammar, for instance I know that c++ syntax is more complex than Java syntax (one of the reason why you don't find so much tools like javadoc for c++).
I'd love to see your reactions on these ideas.
Why a standard DTD (Score:3)
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.
Just do it. (Score:2)
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.
XML and config files (Score:5)
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.
Re:Linux the Kernel. (Score:2)
belette
Re:great (Score:2)
Joe Average will not be launching vi in the first place, and if he goes messing around in his
Now that's interesting's I guess those guys were trying their generic vi/emacs editors on XML. Jesus! The idea of XML is definitely not that you open vi and start hacking away.
Clearly you know practically nothing about software engineering, because if you did then you'd realize that typing in code is only a tiny fraction of the battle. Reading ColdFusion code is as annoying, compared to reading C, as writing it, because of the verbosity. No tool can remedy that.
If you're suggesting that programmers abandon the source text entirely and start programming using visual tools exclusively, then I've obviously been wasting my time here.
I wasn't talking about enclosing the original source but rather about replacing it
So was I. My point was that the following:
contains exactly 5 characters of string literal. The rest is actual program content. In an XML scheme, the program content would have to be written something like the following:
which gains us very little except extra verbosity. If you had bothered to go look up some ColdFusion code on the web, you'd have realized what I was saying.
I have programmed in an XML-syntax-based programming language. You have not. Please don't tell me how it feels. It's annoying. In fact, it's so annoying that Allaire (makers of ColdFusion) included a <CFSCRIPT> tag in the latest version, which allows you to write JavaScript-like, non-XML code instead.
The real reason is that C++ syntax is so complex he would have a hard time building the tool. Can you say #define?
If you really think Bjarne Stroustrup would have trouble building a javadoc-like tool for C++, you need a reality check. C++ syntax is complicated, but compiler authors have had tools (like lex, yacc, bison) for dealing with complicated syntax for years. Clearly, the *compiler* parses C++, so a javadoc-like tool could do so as well. Go learn a bit about compilers (e.g., write one [0]) before you start schooling the rest of us on the complexity of parsing computer languages.
~k.lee
[0] Yes, I have written one. Many CS students do.
Re:XML vs Unix Philosophy (Score:2)
A few observations (Score:2)
Go for it - but keep communicating (Score:5)
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 [weft.co.uk]
Shameless Plug, but Interesting you should ask (Score:2)
http://www.dbxml.org
Bye-bye grep and text tools (Score:3)
Re:XML.. (Score:2)
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...
Re:XML and configuration systems... (Score:2)
Also XML has something resembling a type system in its DTDs, which seems somehwat alien to the LISP mindset...
Re:XML vs Unix Philosophy (Score:2)
From a UNIX system admin of 5 years with dozens of various platforms under administration: BAD IDEA, BAD IDEA, BAD IDEA!!!! I have to explain to all of my managers why NT is impossible to remotely manage because there is no way to connect to the console of the machine remotely if there is a network problem or the system becomes unstable.
OK OK, there are third party product that allow "telnet" access to NT, and most UNIX's come with a Remote Service Processor, and even Linux can be configured with a modem and you can set that modem to be the CONSOLE with later kernel's.
Now, explain to me how I can change configuration files while accessing these machines over a terminal? I can't use the GUI over a console connection, and launching GUI's via modem's sucks.
How can I know ahead of time that the machine I will be using for remote access will even have X windows???
Most of the machines I maintain don't even have a monitor on them, nor a keyboard, and I don't have X installed on them at all.
I don't want to have to enter TAGS around all my text and remember XML rules. I am not a webmaster, I am a sysadmin.
I don't even like most GUI admin tools because they don't follow the syntax rules for files and end up stripping out or relocating comments. They usually don't have the flexibility of "command line" interfaces which is what a config file really is all about, it is a batch of preformated command arguments.
PLEASE PLEASE PLEASE DON'T USE XML for fomatting config files. Leave them in plain text so I can access them from my PALM PILOT MODEM when I get paged at the beach. Or I can access them from the UNGODLY poor MS Win/NT Telnet client if I have to use someone else's machine to connect to them.
Linuxconfig is a great tool for all those people
who don't need very fine control over their config files. It offers basic control of all config's and is centrally located. It also gives those of us who don't want a config GUI the option of not installing it and using the plain text we want.
A very concerned Linux and UNIX advocate.
-Ben.
Re:XML.. (Score:2)
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.
XML.. (Score:4)
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.
XML Everywhere (soon) (Score:4)
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
Flavour of the month (Score:2)
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.
Re:Linux the Kernel. (Score:3)
I think using XML makes a fair amount of sense. It can be relatively human-readable, even in raw character form (a trait shared with HTML that focuses more on semantic mark-up and less on graphical design). And perhaps the best part about it is that you don't have to write a new parser, unless you really really want to. Lots of them exist already in a wide variety of languages. All you have to do is agree on a DTD.
Furthermore, it has the potential to support a variety of useful tools, such as the following:
As there are compiled versions of XML tools out there, and XML is sufficiently high-level that programs that manipulate XML are readily written in commonly compiled languages, the XML tools stand a good chance of being faster and more efficient than the present interpreted tools. And if you don't want to build the XML tools, there are script-based XML tools as well.
XMLTP (Score:2)
LinuXML Project (Score:3)
grep for XML-based records (Score:3)
I spoke on this at the 2nd perl conference... (Score:2)
... 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)