Samofatov, Nickolay wrote:

>Jim, let me turn the problem around.
>Reading such on-the-fly format is 10 lines of code and since it is
>tailored for particular task it is compact and easy to edit by the user.
>

The amount of code is not the issue. If it were, three lines to invoke
existing code is less that 10 lines of new code.

The issue is usability. All configuration information should have the
same format, use the same mechanism for loading, and have the same
general semantics.

>
>Various systems use XML for manifests and configuration due to the
>following reasons:
>1. It is readable and, more importantly, writable by any third party
>system
>2. Handling of non-ASCII characters is very well specified for XML
>3. There are standard means to describe its format and validation rules:
>XSD, DTD, etc.
>

XML was discussed and rejected a year ago. If you have new information
to reopen the discussion, I'm all ears. If you're trying to blow smoke,
give it a break.

>
>None of these issues are addressed in Vulcan meta-syntax to the best of
>my knowledge.
>Why should we standartize of it then?
>

We are standardizing on it because:

1. It was discussed at length a year ago
2. It is upwards compatible from the old scheme
3. The old scheme was too improverished to handle new requirements
4. A huge load of new code has been implemented with it.

If you want to waste a lot of time, we can have the argument all over
again.

>
>Moving further, we can bring in Xerces-C++ parser without significant
>change of Firebird footprint. It uses Apache license which is compatible
>with just about anything.
>Xerces-C++ uses the same standard IBM ICU library for XML encodings
>handling which we use in INTL anyways. The rest is XML syntax and
>DOM/SAX handling which is quite compact there.
>
>

You neglected to mention what problem this is solving.

This is insane, guys. When we discussed the Vulcan configuration files
there was either broad consensus or a complete lack of objection. Do we
really want to have two, three, four different mutually imcompatible
configuration mechanisms? Does anybody really thing this makes things
easier to use?