Copyright © 1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability,trademark, document use and software licensing rules apply.
This document represents an preliminary proposal for a general HTTP server configuration schema. It does not represent the views of the W3C team or member companies.
@@@current apache conf has some inconsistancies and assymetries. need a new one. For example, the current conf does not allow one to copy rules and from one virtual server to another. A good XML schema will promote a more structured graph of relationships.
XML is an excellent compromise between the precise, yet incscrutible SGML and the ubiquitious HTML. XML is well suited to presenting hierarchy in a well structured, but editable format.
At this time, there are many XML parsers, available in many languages. One popular one, James Clark's Expat, has already been ported to apache's PHP scripting module. Netscape and Microsoft are commited to supporting XML editors and renderers in subsequent browsers/editors. IBM's alphaworks project provides reams of XML tools and utilities. While there are many options for "the language of the future", XML is well structured, extensible, and has a really scary amount of momentum.
I beleive RDF's most important contribution to XML is the ability to reference other nodes in any document without including them in the hierarchy. This changes the structure from a tree to a graph. Using this we can introduce the ability to build a configuration file that has internal references. This avoids, for example, repeated Directory directives in multiple virtual hosts:
NameVirtualHost 18.29.0.111
<VirtualHost 18.29.0.111>
ServerName ella.w3.org
ServerAlias hal
RewriteEngine on
RewriteOptions inherit
Alias /ads/ /usr/local/apache/share/ads/
<Directory /usr/local/apache/share/ads/>
Options +Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
NameVirtualHost 18.29.0.65
<VirtualHost 18.29.0.65>
ServerName niku.w3.org
ServerAlias niku
RewriteEngine on
RewriteOptions inherit
Alias /ads/ /usr/local/apache/share/ads/
<Directory /usr/local/apache/share/ads/>
Options +Indexes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
to a more symbolic
<Directory rdf:about="#Ads_1" TreeRoot="/usr/local/apache/share/ads/" UriMapsTo="/ads/" Options="+Indexes" AllowOverride="None" Order="allow,deny" Allow="from all"/> <VirtualHost IP="18.29.0.111" ServerName="ella.w3.org" ServerAlias="ella" RewriteEngine="on" RewriteOptions="inherit"/> <Map resource="Ads_1"> ... more directives </VirtualHost> <VirtualHost IP="18.29.0.65" ServerName="niku.w3.org" ServerAlias="niku" RewriteEngine="on" RewriteOptions="inherit"/> <Map resource="Ads_1"> ... more directives </VirtualHost>
While the current RDF infrastructure is not sufficient to motivate its adoption, its potential should be more than compelling. The ability to express information in a machine-processable and exchangable will permit the exchange of pieces of the configuration with other clients for servers.
The Platform for Privacy Preferences (P3P) Specification is an example of a protocol that uses the RDF concept of resource reference. It enables servers and clients to exchange privacy policies for URL trees. Allowing the server to associate such a policy with a URLs in a server configuration opens up a world of configuration options.
There are many other possibilities. Imagine, for example, sending the client an AUTH_REQUIRED with information about the boundries of the realm. This would allow the client to build a map of the realms wihtout an extra round trip for each connection.
While I am strongly in favor of an RDF-compliant syntax, I must note that it does constrain the syntax. There is a limited syntax to serialize RDF and it may create certain contstructs that are not so pallatable to those editing the configuration by hand. There are alternate RDF syntaxes being discussed, but they are not complete and may not solve the issues of having the occasional awkward syntax.
Hmm. Not sure whether to propose a DTD or not. If I propose a DTD, it simplifies the parser but prevents us from taking full advantage of the RDF syntax.
If each module that has specialized instructions, (ones that are to be read by it and only it), they should be placed in a namespace specific to that module:
<Directory rdf:about="#Ads_1" TreeRoot="/usr/local/apache/share/ads/" UriMapsTo="/ads/" xmlns:spel="http://www.apache.org/mod_speling/v3.2#" spel:whatToDo="justCaseWrappingPleaseThankYou" spel:errorThreshold="2" ...
Namespaces are generally selected by asking "Who can
understand this directive". For instance, if I write a new module
identified by
"http://www.w3.org/mental-hiccups/mod_crazy_speling/v0.1b#",
I may choose to continue to use the original whatToDo
directive, but decide that my errorThreshold is so
different than Apache's standard mod_speling that I don't want
anything that thinks it understands the original
errorThreshold directive to try to interpret mine. In
this case, I put it in a sepparate namespace:
<Directory rdf:about="#Ads_1" TreeRoot="/usr/local/apache/share/ads/" UriMapsTo="/ads/" xmlns:spel="http://www.apache.org/mod_speling/v3.2#" xmlns:crazy="http://www.w3.org/mental-hiccups/mod_crazy_speling/v0.1b#" spel:whatToDo="justCaseWrappingPleaseThankYou" crazy:errorThreshold="6.02E23" ... />
One feature of having references to either internal or external elements is that one may keep the configuration in a distributed set of resrources. The immediate use is that it makes it easy to break a configuration up into multiple files for convenience or deviance. One interesting extension is to have the stored, in part, in network resources. A
Here are links to relevent specifications and products:
Last revised: $Date: 2014/02/24 22:02:48 $ by: $Author: sysbot $