tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: XML config
Date Thu, 20 Jan 2000 19:30:12 GMT
Stefano Mazzocchi wrote:
> Ben Laurie wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > Ehmmm,
> > >
> > > pardon me, you guys. But having dealt with XML configurations for about
> > > a year now, I think I have something to say in this area.
> > >
> > > Ben had a problem: how to validate an XML configutation. The problem is
> > > resolved: you don't. Period. XSchema will not be powerful enough to
> > > allow an external tool to validate, say, apache configurations before
> > > this is applied to the web server. The web server will validate it and
> > > this is how it works for configurations.
> >
> > That wasn't my only problem, but I have to ask: if you can't validate
> > it, how can you define it? If you can't define it, how can you expect
> > anyone to use it?
> ??? do you HTTPD people felt the lack of a "validation" syntax that
> allowed other programs to tell if your apache httpd.conf file was valid
> or not?

That's not my point. My point is that if you _can't_ validate it, then
it must not be well-defined. I'm not suggesting that anything other than
the server should validate it!

> > > - the worst case is where configurations overlap between modules.
> > >
> > > The question is: can we topologically redefine the DTD so that
> > > overlapping configurations don't overlap anymore? can something like
> > > inside Xlinks help in this area?
> > >
> > > I admit I don't know the answer to this last question, but I'm more than
> > > willing to help to find one since it would solve both Apache and Tomcat
> > > problems as well as establish some design patterns useful for other
> > > projects (cocoon, for example).
> > >
> > > What do you say?
> >
> > I say "let's go".
> Great.
> > Now, there are some other problems that need
> > addressing. In no particular order, here they are:
> >
> > a) Namespaces. I think this is a no-brainer if you are prepared to have
> > long names, but is that reasonable?
> IMO, XML without namespaces is just SGML--
> In my "topological" dissertations on, I showed
> how the XML 1.0 model is mostly monodimentional, exactly like SGML.
> Namespaces allow XML to achieve multi-dimensionality.
> In modular documents types (like we need for Apache), the use of
> namespace is a must if you want to achieve validation using XSchema.
> Otherwise, you have to write your schema that covers all possible
> combinations and if your mod_whatever needs a new tag, you need to
> rewrite your main DTD and to reflect this all over the world.
> A DTD that changes every other software revision is totally useless.
> Namespaces + XSchema allow you to make a schema for your particular
> namespace. So, mod_rewrite may need a complex schema but once it's
> defined it doesn't change that much over time. While, mod_my_own_module
> would need to be validated without having to change the global DTD.
> Am I making any sense?

Yes. But this is exactly the point I've been trying to make all along.

> > b) Conditions: a vital point, I think, is that some Apache modules deal
> > with what configuration is currently applicable, and the rest only worry
> > about the current applicable configuration. This is currently handled by
> > mucho magic inside Apache, and it'd be nice if it weren't.
> I think I lost you here. Consider that many people around here know very
> little about Apache internals. I, from my part, know exactly nothing
> about that :) Pier rewrote mod_jserv, I wrote only on the other side of
> the socket.
> > It occurs to me that what I was really trying to get at with my proposal
> > was the idea that as each element is processed, it should determine how
> > the contained elements are processed (or not) by the module that
> > processes the containing element, even if the contained elements are
> > unknown to it.
> This can be done with namespaces: we "push" a filtered tree of elements
> to the module and this tree was pruned by all the elements that do not
> belong to this namespace. I call this "projecting the document on a
> namespace axis".

Right. There's more to it than that, but not much. In particular, we
need to _not_ push stuff when it doesn't match the current context.

> > So long as something has the ability to make this happen,
> > and it is possible to cache the results, then the <Module...> notation
> > is overkill (the relevant module can be determined by the element name).
> or by the namespace.


> > I'm beginning to think this is actually trivial but I still can't quite
> > put my finger on how its done.
> Let's make an example
> <server xml:base="/usr/local/apache/"
>         xmlns=""
>         xmlns:jserv="">
>  <type>standalone</type>
>  <pid>/logs/</pid>
>  ...
>  <modules>
>   <module status="on" name="jserv_module"
> object="modules/"/>
>   <module status="off" name="info_module" object="modules/"/>
>   ...
>  </modules
>  <hosts>
>   <host name="" port="80">
>    ...
>   </host>
>   <host name=" port="80">
>    <jserv:automatic/>
>    <jserv:properties file="conf/"/>
>    <jserv:log file="logs/mod_jserv.log" level="notice"/>
>    <directory path="/home/web/" options="All">
>     <allow>all</allow>
>     <directory path="servlet">
>      <jserv:map engine="ajpv12://"/>
>     </directory>
>    </directory>
>   </host>
>  </hosts>
> </server>
> NOTE: this is just out of my head... it may not make that much sense in
> an apache-wide sense and note that I'm familiar only with mod_jserv
> configurations which are not that standard in an Apache sense.
> Anyway, look at a couple of things:
> 1) the default namespace handles core things
> 2) each important module has its own namespace where it is free to
> define its own stuff
> 3) there are elements like <directory> that drive the module
> functionality and thus require the ability to include elements from
> other namespaces.

These are the ones I want to generalise and avoid the magic I was
referring to above.

> 4) order is always enforced by the XML parser and it's important, like
> in current apache configurations
> 5) XML configurations are much more structured than plain flat
> configurations. These visually enforce the inclusion and layering,
> resulting in a better structured configuration file. IMO, Apache conf
> files "scream" to be ported in XML.
> 6) the .htaccess pattern of distributed configurations needs lots of
> reasoning since it cannot be ported as it is over the XML world. In the
> Cocoon project, we are trying to deal with the same things.

Yes, this is one thing that has been causing me brainstrain. I currently
suspect that the main configuration should say "include files called 'x'
here", but I have a feeling that gets messy.

> 7) servlets like Cocoon should be able to add its own configurations in
> their own namespace and behave like Apache modules in all senses. We
> should define a way to map Apache configurations to
> files but this is possible to do without breaking the servlet platform.
> 8) the use of XML requires people to have some XML knowledge but
> learning by example is much easier than with other syntaxes (how much it
> took you to write your first HTML file?)

XML is trivial to learn to write!

> > As for DTD-like stuff, well, the per-module DTD-like-thing neeeds to say
> > whether each top-level element can be contained within another module's
> > stuff, or not (i.e. is the configuration element server-wide, or not),
> > and, on the other side of the coin, whether it can contain other
> > module's stuff. I'm not sure there's any need for more subtlety than
> > that, is there? Or am I missing something?
> This is almost _exactly_ what the XSchema Structure spec defines. I
> think you should take a look at it.

I will.




"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

View raw message