strictxml sandbox update

[Curt Arnold <ca...@apache.org>]

A long time ago, I started the seeds of an effort to develop a  
logging configuration schema with the goal that eventually the schema  
could be used to generate documentation for the configuration file  
format, could be used to enable syntax-aware assistance and off-line  
validation using XML Schema aware editors.  The initial couple of  
hours work was committed into the log4j trunk and then lay dormant  
for months on end.  About a month ago, I removed that code from the  
log4j trunk and spun it into the "strictxml" project in the sandbox.   
I've been iterating on the document format for a few days and think  
I've got the general feel of the configuration syntax in place and  
have just recently committed changes in rev 377312.

The source code of strictxml can be retrieved using: svn co http:// 
svn.apache.org/repos/asf/logging/sandbox/strictxml strictxml

Currently, I have defined multiple namespaces that share a core set  
of definitions and then vary by the capabilities offered by specific  
implementations.

The core definitions are in an XML entity (src/xsd/common.xml) which  
is referenced by the schema documents in a manner similar to an  
#include in C.  This entity contains the boilerplate definitions that  
should be common to all the configuration flavors.  The use of the  
entity is an authoring convenience and the schemas delivered to end- 
users would typically have the entity expanded to avoid  
implementation shortcomings of the available tools.

The "generic" namespace (http://logging.apache.org/configuration/ 
draft1) is defined in src/xsd/logging.xsd.  This namespace is  
intended to contain only those elements and attributes that are well- 
established and consistently interpreted by the implementations.  If  
you have a configuration file that conforms to the "generic" schema,  
then it could (at some future date) work with log4j, log4cxx, and  
log4net with consistent results.

The "log4j" namespace (http://.../draft1/log4j, defined in src/xsd/ 
log4j.xsd) and "log4cxx" namespace (http://.../draft1/log4cxx in src/ 
xsd/log4cxx) contain the generic elements plus implementation  
specific features.  For example, the implementation specific  
namespaces include an <object> element that allow configuring custom  
appenders or layouts.  That element could not be in generic namespace  
since a value like "com.example.myapp.MyCustomAppender" would not  
work in both log4j and log4cxx.  Any document that conforms to the  
generic schema should conform to any implementation specific schema  
if the namespaces are appropriately changed.

The schemas are incomplete, for example, only a few of the available  
appenders are defined, but the general approach should be apparent.   
A strictxml configuration looks like:


<?xml version="1.0" encoding="UTF-8" ?>
<configuration debug="true" xmlns="http://logging.apache.org/ 
configuration/draft1">

   <appender name="D1">
     <console>
         <pattern conversionPattern="%-5p %c{2} - %m%n"/>
     </console>
   </appender>

   <root level="off">
     <appender-ref ref="D1" />
   </root>

</configuration>


Compared to the current equivalent:

<?xml version="1.0" encoding="UTF-8" ?>
<log4j:configuration debug="true" xmlns:log4j="http:// 
jakarta.apache.org/log4j/">

   <appender name="D1" class="org.apache.log4j.ConsoleAppender">
     <layout class="org.apache.log4j.PatternLayout">
       <param name="ConversionPattern" value="%-5p %c{2} - %m%n"/>
     </layout>	
   </appender>

   <root>
     <priority value="OFF" />
     <appender-ref ref="D1" />
   </root>

</log4j:configuration>


Valid and invalid configuration files (lifted from the log4j unit  
tests) are in src/test/resources/valid and src/test/resources/ 
invalid, respectively.  The unit tests do not currently work due to a  
Xerces-J problem that I haven't worked around, but tests with a  
different schema validation tool confirms that all the configurations  
in the valid directory are valid against the appropriate schema and  
all the configurations in invalid are invalid.

There are some documentation elements within the body of the schemas  
which can be used by generic schema documentation tools or custom  
transforms to generate end-user documentation.  The schemas also  
contain samples of implementation clues, for example, that the <file>  
element maps to org.apache.log4j.FileAppender in log4j  
and ::log4cxx::FileAppender in log4cxx, that would be used in code  
generation.

My current motivation is eliminating dependency of log4cxx on the DOM  
implementations of libxml2 and MSXML by migrating to an event-based  
parsing approach.  Porting the Joran configurator over to log4cxx has  
been on my task list for a very long time, but I wanted to flesh out  
this approach before diving into Joran.   The next step would be to  
work on a Java parser implementation.