Barrapunto

Pues eso, que la traducción más comun para "parser" es Analizador Sintáctico, o abreviadamente, analizador.

En cuanto a lo que comentas de que ya existen, es cierto. Pero una de las ventajas de los ficheros en texto ASCII actuales es que si, por lo que sea, se corrompen es fácil recuperarlos a mano, o por lo menos parte de la configuración. Con XML, la biblioteca que uses te dará un error de validación y finalmente te lo tendrás que currar a mano. De hecho XML fue diseñado para ser "sencillo" y "legible por el humano", y ya se ha visto que pocas veces es así. Existe un grupo creciente de detractores de XML precisamente por esta razón.

Otra cosa que le veo al XML es que fue diseñado para ser fácil de analizar ('parsear'), y para que fuera sencillo construir analizadores para él. Al hacerlo así, se ha vuelto más orientado a la máquina que al ser humano, y creo que debería ser a la inversa: que los ordenadores trabajen nosotros y no nosotros para ellos.

Pienso que la única desventaja de los ficheros ASCII actuales es que cada aplicación tiene un formato distinto, que es lo que el XML viene a unificar.
Para mí con el antiguo .INI que está implementado en Perl, Python y creo que hasta en C por todos lados, es el formato ideal, tanto para humanos como para programas.

Existen parseadores (que mal suena esta palabra) de XML ya hechos para todos (o casi todos) los lenguajes de programación existentes

Sí, pero es que un archivo de texto típico unix lo puede manejar cualquiera, aunque no sea programador, con un simple shell script. El hacer los archivos de configuración xml es casi como hacerlos binarios para la mayoría de la gente. No se pueden editar a mano ( sólo hay que ver los xml's que generan muchos programas de gnome ), y para hacer cualquier cosa automatizada con ellos hay que ser poco menos que programador con conocimientos de xml. No me gusta