Re: Jakarta/Apache XML/RDF configuration file format(s)

Dan Brickley wrote:

> Is the detail of the XML format finalised, or up for discussion? There
> was some talk last autumn of an XML/RDF representation of Apache
> configuration files.

A little history might help:

During the ApacheCon '98 party at the SF Exploratorium (in October),
Eric and I talked a lot about XML and the new stuff the W3C was
creating. Eric is a very smart guy and we shared lots of ideas about how
the web was going and how we could use those new technologies to do
better things. (Some of that very early discussion made me create Cocoon
a few months later to investigate it further, but this is another
story).

We both agreed that XML was a major move forward and given its
simple-yet-powerful syntax and structure, it could really be used for
XML configurations (at that time, some of the Apache folks were not
satisfied by the three-files Apache configurations and wanted to move
forward for Apache 2.0. XML was proposed as a choice) and all a bunch of
other things.

At the same event, Daniel was showing its new Comanche and showed me how
he had some "configuration wrappers" that allowed its engine to be very
flexible and abstracted on the real configurations. (we had discussed
this privately the summer before when I was trying to start off a new
Swing-based configuration project for JServ under java.apache called
"Jack - Java Apache Configuration Kit" but went nowhere).

It was simple to associate this meta-configuation separatation model
with what the W3C was doing. So Erid, Daniel, Pierpaolo and I spent a
whole afternoon to find out the best way to do it. (Eric later set up
the mail list you were indicating). As you see, those ideas have been
around for a while and if we move Jakarta into the configurations-in-XML
world, this is something we should seriously investigate since it would
allow people (and vendors) to contribute with such configuration tools
in a very abstracted way.

Here is a simple configuration file to show what I mean:

 <server>
  <name>jakarta.apache.org</name>
  <port>80</port>
  <admin>jakarta@apache.org</admin>
 </server>

Given the configuration DTD, you might use XML tools (such as IBM Xeena)
to edit these elements in a valid way, but DTD are very limited because
they validate the XML structure and not the internal rules.

So you need to come out with something that allows a configuration tool
(might be GUI or text based) a way to present information in an
interactive way (use TextField or ComboBox, etc..) and to validate it
against some strict rules (1 < port < 64K, admin content is a valid mail
address, etc..)

If all this information is based on a common meta-configuration
definition language (Eric thought about RDF for this, but I don't know
RDF enough to express a final opinion on this), then one tool may be
used to configure every possible software that can express such RDF for
its configurations.

This is so flexible (being on different files) that old vi-style people
are not bothered by unnecessary information in their XML configuration
file, but people willing to use more coherent tools (such as Comanche)
for different software in their network. This tool might also be nicely
wrapped by SNMP logic and so on.

The key point is the separation of configurations (in XML with some DTD)
parsed by the configured software and meta-configurations (in another
XML using the RDF DTD) parsed by whatever configuration tool. An
important thing is that meta-configurations are used as "templates" for
the creation of an XML configuration and might even be used by
installers to present interactive information to the user during
installation.

For example (I'm not using RDF for this, just to show my intentions):

 <element name="port" required="true">
  <template-value>80</template-value>
  <gui type="counter">
  <comment xml:lang="en">This is the port used by the server</comment>
  <comment xml:lang="it">Questa č la porta usata dal server</comment>
  <comment xml:lang="fr">Cette est la porte utilisče par le
serveur</comment>
 </element>
  
as you see, a configuration tool that is able to interpret this document
would be able to generate the <port> element and query the user
(depending on its language).

Unfortunately, the list is dead for some time now. But the ideas, IMO,
as still solid and useful.

P.S. Eric, Daniel, sorry to make you jump on this. For more information
about Jakarta, look at jakarta.apache.org. Send any comment to me and
I'll forward to the mail list (or you might consider to subscribe to the
list if interested)

-- 
Stefano Mazzocchi       A language that doesn't affect the way you 
                      think about programming, is not worth knowing.
<stefano@apache.org>                             Alan J. Perlis
---------------------------------------------------------------------

Received on Monday, 12 July 1999 08:52:26 UTC