tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XML configuration revisited
Date Mon, 11 Oct 1999 20:43:33 GMT
Ben Laurie wrote:

> Actually, I don't think it was lack of code that stalled the discussion,
> but an embarassment of options on how to solve the "XDTD problem".


> ...I think that until you think about how to integrate subsystems you
> haven't addressed any problems that don't fall into the realm of the
> bleedin' obvious(tm). To take a really trivial Apache example, some
> modules have some configuration that can appear within <VirtualHost ...>
> sections, and some that can't. The XDTD should define this, rigorously.
> Somehow. Ideally in a way that everyone thinks is good and is
> standardised.

There are solutions to this problem but require a significant perpective

1) Do not validate. 

Let XML be well-formed and let the server understand if the format has a
valid meaning. This is what currently happens with both Apache and
java.apache projects. Wellformness, is these cases, is ASCII compliance
(which we take for granted!)

This solution allows you to remove the "contract" inside the DTD and
replace it with documentation. Exactly like it's done today. True, part
of the XML idea is lost.

2) Use namespaces.

Let every module define it's namespace and it's own DTD. Currently the
XML spec doesn't allow this, but the XSchema WG is specifically working
to integrate what you defined as "XDTD", thus the ability to have
different pars of the document being validated by different DTDs.

The IBM XML4J parser (don't know about the C++ version) is currently
supporting XSchema for validation, but I don't know its status.

3) Use pseudo-RDF.

Create a meta-configuration language which is what a group of four of us
(Daniel Lopez Ridruejo, Eric Proud'Hommaux, Pierpaolo Fumagalli and
myself) have been discussing at ApacheCon98.

This XML should have information _about_ configurations and drive human
interaction programs (either GUI, command line or web based) to create a
valid configuration file.

But this could very well be a superset of the configuration XSchema.

To conclude: using a single DTD for configuration is too complicated,
therefore it's not useful unless machine created.

Since configurations should be human editable, we need a way to separate
different validation rules on their contexts. Placing validation rule
definition to the project/module developers, and allowing those
validation rules to be _merged_ without influencing the "container" DTD.

I believe the XSchema spec is what we lack to provide such a
configuration framework. Thing that would also allow configuration tools
to work on every ASF project based on it.

Hope this is useful.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message