[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML for configuration files

• From: Jeff Greif <jgreif@a...>
• To: xml-dev@l...
• Date: Fri, 15 Jun 2001 09:39:08 -0700

It's hard to imagine a better application for XML than configuration files,
particularly if the configurations must be modified by users (even
supposedly knowledgable administrators at user sites).

You can implement a complete generic configuration data structure as a
collection of properties (e.g. java.util.Properties), where nested
structures are simply properties in the collection whose values are other
collections of properties.  Similarly for attributes.

Simple SAX event handler functions or DOM PSVI accessors can establish the
individual properties in their proper place in the structure.  Just invoking
the XML parser/validator prepares the data for your application.  The
application is free to ignore properties it doesn't know how to treat.  If
you don't use the generic data structure, then some more specialized (but
usually almost trivial) code will need to be written to access the parser
output.

What else do you get:
-- default values for attributes automatically supplied by the parser from a
DTD or schema or RELAX model or another content model. This allows attribute
defaulting to be handled/modified declaratively, without having to recompile
the application.
-- A significant amount of error handling.  If you use a validating parser,
various constraints on element and attribute values and element presence can
be tested with no application code -- you specify the constraints in the DTD
or schema or Schematron rules.
You can probably remove 90% of the validating and error-handling code from
your configuration reader and replace it by declarative constraints in the
content model, making it easier to maintain and change.  The XML
parser/validator will report the errors for you.  Often, you don't need
anything too fancy except a clear error message, as misconfigurations can
cause the application to quit and be restarted when a revised configuration
file is available.
 -- Significant decoupling of application code from changing configuration
features.  In many cases, an old version of the application will be able to
handle a new configuration file, just ignoring the new parts.  A new version
of the application will often be able to handle an old configuration file,
if there are reasonable defaults for the new parts.
 -- ability to use off-the-shelf XML editors which grok the content model
(DTD or schema, etc) and can enforce the constraints during the editing
process for the configuration file.  This will help to ensure a valid
configuration file at the time of saving.  If things change slowly enough,
you could even turn off validation in the runtime parsing of the file, but
often you can afford the extra validation at runtime which will help find
incompatibilities between the file and the version of the application or
content model owing to upgrades after editing.  The XML editor can
incorporate the content model's documentation as help during the editing
process, helping users to build the configuration file correctly and know
what they're doing.

There are rarely performance implications in setting up configuration
processing this way, because this processing is rarely a bottleneck in
getting a significant server running.

Jeff

----- Original Message -----
From: "hector santos" <xml-dev@w...>
To: <xml-dev@l...>
Sent: Friday, June 15, 2001 6:06 AM
Subject: Re: almost four years ago....



| I had a debate with one of my engineers.  He wanted to change our
| fixed structure configuration file that our server reads to an
| XML format. Good idea, flexible, allows easy expandability for
| the future.  But I don't agree that it will improve server
| performance or will it reduce our Q&A.  In fact, it will be
| worst. For example:
|
|      ReadConfiguration(TConfigurationData &cf);
|
| will now have to be expanded to read each supported field
| represented in the configuration, individually.
|
| Internally, I don't think it is a good idea.  However, to
| expose our external interfaces, this is probably ok. Not
| because it better than before, but it if allows us to
| "advertise" to potential customers and partners "You
| can access our system using XML/SOAP", then I think its
| good.

• References:
  • Re: almost four years ago....
    • From: hector santos <xml-dev@w...>

• Prev by Date: Re: SAX 2.0 enhancement proposal
• Next by Date: Re: SAX 2.0 enhancement proposal
• Previous by thread: Re: almost four years ago....
• Next by thread: Re: almost four years ago....
• Index(es):
  • Date
  • Thread