Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Jan 1999 22:25:39 -0800 (PST)
From:      Allan Bowhill <kosmos@animal.blarg.net>
To:        stable@FreeBSD.ORG
Subject:   managing configuration changes with SGML/XML
Message-ID:  <Pine.LNX.3.95.990101174941.21112A-100000@animal.blarg.net>

next in thread | raw e-mail | index | archive | help
Does anyone have thoughts about using SGML/XML to address problems that
arise from changes made to configuration files? 

If package authors or maintainers each supplied a default configuration
file as an SGML document instance, and a structural specification for that
file as an SGML DTD, wouldn't it make changes to the content or structure
of configurations easier to manage?

For instance, after a CVS update, if a system operator could validate
configurations against the most current DTD for each package, it would be
more convenient than using diff to manually merge *etc changes. Diff
triggers a lot of false-positives on unimportant information.

Structural validation gets closer to the point than diff, because as
long as the document instance conforms to the author's specification, it
doesn't matter how the system operator's particular version of a
configuration file measures up to the system default, (or sample
configuration.) The files really shouldn't be compared directly, becuase
they don't necesssarily share a direct relationship to each other.

In the case that the author changed the package's behavior radically
enough so it resulted in an important change in the configuration
specification (e.g an option was deleted, modified or added; or the
file's structure was changed) the package's DTD would have to be changed,
too.

So after a CVS update, a change in a DTD would have to trigger some kind
of structured comparison to inform the system operator of changes in the
configuration specification, and how it affects his current configuration
files.

If that could be done, changes to configuration files could possibly be
made in-place, without a lot of intermediary steps after a build.

Comments on this are welcome...


--Allan
  kosmos@blarg.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.990101174941.21112A-100000>