>>>>> Vincent Lefevre <vinc...@vinc17.net> writes:
>>>>> On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote:
>>>>> On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote:
[…]
>>> You may want relations between key-value pair. For instance, if
>>> you have a line with a key "foo", then a line with a key "bar" must
>>> also exist. Or a line with a key "number" must have a value that
>>> is a number (more generally matching some regexp).
>> That's not validation of the format, that's validation of the data.
> That's validation of the config file. This is what XML validation
> does: it checks whether the file is valid according to some schema.
That being said, I believe that the reason XML became so
widespread (and, conversely, it's ancestor SGML fell into
disuse) is precisely because the former decoupled the format
(representation, and its inherent semantics) itself from the
validation. That way, we were able to forgo DTD and develop
such (arguably, much better) XML schema representations such as
XML Schema and RELAX NG. (The latter is the one used by Emacs.)
I'm not aware of any “standard” schema representations for the
(sectioned) key-value file formats, however.
>> I've never seen any config file with nested config blocks that
>> didn't make the file more complex and less easy to understand.
> Wrong. Nested blocks make config files easier to understand.
> Otherwise for the same feature (e. g. conditionals), one would need
> things like horrible state variables. For instance, think about
> redesigning a procmailrc with the ini format...
On the second sight, the difference between, e. g.:
<a>
<b>
<c>d</c>
<e>f</e>
</b>
<g>
<h>i</h>
</g>
</a>
and, e. g.:
[a.b]
c = d
e = f
[a.g]
h = i
is mostly superficial.
--
<!DOCTYPE the><the ><tensible ribbon="campaign" /><p>Advocating the
judicious use of XML applications on the Internet at large.</p></the>
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/868v9fy5rm.fsf...@gray.siamics.net
