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 Tue, 12 Oct 1999 09:00:44 GMT
Ben Laurie wrote:

> > 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.
> No, Apache config _is_ validated.

I was referring to the Apache 1.x.x conf files which are validated
internally with hardcoded logic.
> > 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.
> Well, that's cool, but I'm not sure I understand the "own DTD" aspect:
> we require a mix (that is, a module needs to be able to say "these tags
> are valid within that other modules tag-so-and-so").

Hmmmm, I don't want to miss your point here. Could you give me a
xml-conf example?

> > 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.
> Exactly.
> > But this could very well be a superset of the configuration XSchema.
> Pointer?

oh, sorry, all XML-related information are found at and in particular   (XSchema requirements)          (XSchema structures)          (XSchema datatypes)

you would also like to take a look at the       (XML fragment interchange)

which defines how several xml fragments can be merged in a single
document without loosing its structure (as for XML entities) to allow
XML editors to work on fragments without having access to the whole
source. This might be _very_ interesting for sym-linking other xml-conf
files internally.

> > To conclude: using a single DTD for configuration is too complicated,
> > therefore it's not useful unless machine created.
> Not quite sure I see why this rules it out?

Well, a _general_ configuration DTD needs to be very loose on
validation, something like

 <parameter name="param-name">value</param>

which doesn't make much sense to validate since param-name and value can
be all you want.

On the other hand if we come up with something like

 <server name="" port="80">
  <directory uri="/">

this is _specifically_ for web servers. And not much useful for other

So, if you come up with something like this

<conf xmlns="" 
  <httpd:port type="integer" default="80">80</httpd:name>
  <httpd:directory httpd:uri="/">
  <httpd:module xmlns:jserv="">
   <httpd:name type="String">mod_jserv</httpd:name>
   <jserv:module jserv:manual="off"
    <jserv:mount jserv:uri="/servlets" jserv:location="/root"/>

with a powerful XSchema, you can validate the namespaces saparately say,
for example, that 

 <!element module (name)>

is associated with the "" namespace and

 <!element module (mount*)>

is associated with the "" namespace.

> > 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.
> Some validation is probably too complex to handle in "XDTD" but at
> present Apache doesn't detect those: it just fails to work. The majority
> of interesting cases are grammatical, IMO.

True. On the other hand, XSchema provides better validation logic, for
example, indicating you cannot have a string value in a port=""
attribute which doesn't make sense.

> > 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.
> That would be doublepluscool.

:) Yep.

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

View raw message