[
Lists Home |
Date Index |
Thread Index
]
One use case for default attribute or element values:
An application configuration file in the form of an XML document offers
advantages of flexibility, robustness in the face of version upgrades to an
installation, extensibility, basic error-handling support, basic low-level
validation of the configuration information.
Such a configuration file may contain information appropriate to a whole
range of uses and levels of configurability, that might be manipulated by
several different people filling different roles. For example, there might
be elements and attributes which control the severity level and verbosity of
log entries, locations where the database and naming servers might be found,
communications modes for distributed processes (CORBA vs. COM or HTTP),
directories where log files go. These might be the province of system
administrators. There might also be information specifying some kind of
database metadata which told the application how to extract the data it
needed from the using organization's relational database (e.g., views which
provide the necessary results). This might be the province of some kind of
business unit IT administrator. There might be information about scheduled
activities (backups, logfile cleanups) relevant to the application. There
might be information about which features of the application would be
enabled or disabled. There might be security settings. There might be
specifications of custom extensions, or user programs that would be invoked
by some features of the application. Some of this information is meant to
be edited by users, and some is normally not supposed to be edited, but
might be changed by the vendor or under the direction of the vendor's
customer support office to help diagnose a problem with the software. In
many cases, the producer of the configuration instance document does not
know enough about the meaning of a given setting to be expected to insert
the setting as a required item.
Default values for many of the settings in such a file provide these
benefits:
1. If the installation is upgraded (or downgraded) to a different version,
the defaults can change correspondingly (in the configuration file's DTD or
schema) without affecting the hand-edited settings. The replacement
installation can come with a different DTD or schema, but the configuration
file itself can be unchanged.
2. The vendor can send out a new DTD or schema changing default values for
features that were not approved for certain classes of usage (for instance,
certain high-security usage) when the software was released, but since had
been certified or otherwise vetted.
3. When the default values are the ones that are right or reasonable for
normal operation, the people configuring the application can avoid having to
know about them, while they are still configurable without having to touch
the application code and can be inspected in the schema or DTD.
Jeff
----- Original Message -----
From: "Michael Brennan" <Michael_Brennan@Allegis.com>
To: "'Matthew Gertner'" <matthew.gertner@schemantix.com>;
<xml-dev@lists.xml.org>
Sent: Thursday, March 28, 2002 1:31 PM
Subject: RE: [xml-dev] RELAX NG Marketing (was RE: [xml-dev] Do Names Matt
er?)
> > From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
>
> <snip/>
>
> >...Or
> > do you think that the whole idea of element defaulting is misguided?
>
> .... Honestly, what is the
> use case for software (or a user) to be able to put an empty tag in the
> document and have the value defaulted rather than just explicitly put the
> intended value into the document? This simply shifts a burden from the
> producer of a document to the consumer of the document; a producer can
> *force* a consumer to have to construct a PSVI (or have a hard-coded
> equivalent in application code) in order to reliably interpret the infoset
> of a document. If the default value is intended, why is it an unacceptable
> burden for the producer to just put the intended value in the document?
|
