From owner-freebsd-stable Fri Jan 1 22:26:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA15267 for freebsd-stable-outgoing; Fri, 1 Jan 1999 22:26:04 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from animal.blarg.net (animal.blarg.net [206.124.128.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA15259 for ; Fri, 1 Jan 1999 22:26:03 -0800 (PST) (envelope-from kosmos@animal.blarg.net) Received: from localhost (kosmos@localhost) by animal.blarg.net (8.9.1/8.9.1) with SMTP id WAA11495 for ; Fri, 1 Jan 1999 22:25:39 -0800 Date: Fri, 1 Jan 1999 22:25:39 -0800 (PST) From: Allan Bowhill To: stable@FreeBSD.ORG Subject: managing configuration changes with SGML/XML Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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