Ayuda para mejorar la clase TghXMLDoc

[[Al González]]

En el sistema operativo Windows existe una API conocida como MSXML, la cual ofrece un rico conjunto de interfaces COM con las cuales podemos leer, escribir y manejar archivos XML evitándonos complicaciones de análisis sintáctico. Aprovechando esta circunstancia, hace más de un año comencé el desarrollo de una modesta clase de nombre TghXMLDoc (el infijo "gh" por ser parte de GH Freebrary), cuyo propósito es facilitar el uso de MSXML desde Delphi. Cabe mencionar que de esta clase derivé algunas otras, más específicas, relacionadas con el manejo de hojas de cálculo Excel (pues internamente también son archivos .xml). Y pretendo que esta clase sea la base para cualquier otra relacionada con documentos XML (para LibreOffice, por ejemplo) que haya que crear en el futuro dentro de la biblioteca.

La finalidad del tema que ahora abro es captar propuestas de mejoras o ampliaciones de esta clase base, y que entre los interesados ayudemos en el análisis y desarrollo de tales modificaciones. No está de más recordar que para formarnos una opinión sólida de lo ya hecho, primero conviene descargarla (disponible para Delphi 7 y pronto para XE2) y al menos haber examinado un poco su código fuente.

Expongo la primera inquietud de mejora. El actual constructor de la clase está así:

Código Delphi [-]
  Constructor TghXMLDoc.Create (Const AContent :String = '');
  Begin
    Content := CreateOLEObject ('MSXML2.DOMDocument.4.0');
    Content.Async := False;

    If (AContent <> '') And Not Load (AContent) Then
      ghRaise ('Invalid content or file for XML document.');
  End;

Podría extenderme explicando cada línea y quizá lo haga luego, pero ahora me gustaría hacer notar sólo lo que realiza la primera sentencia. Content es un campo o miembro de la clase y su tipo es OLEVariant. Como puede verse, en ese campo guardamos la interfaz de un objeto COM creado mediante la función nativa CreateOLEObject. Tendrán presente que a esta función debemos darle el nombre o ProgID que identifique la clase de objeto COM que deseamos crear. El ProgID MSXML2.DOMDocument.4.0 corresponde al objeto principal de MSXML, el que representa a un documento XML entero. Así es como la clase Delphi TghXMLDoc viene a encapsular un único documento XML a través de la interfaz asignada a Content.

En la parte final del ProgID aparece "4.0", y eso es lo que me interesa abordar con ustedes. Significa que, invariablemente, la actual implementación de TghXMLDoc requiere que la versión 4.0 de MSXML se encuentre presente en el sistema operativo, con sus debidos asientos en el Registro de Windows. Confieso que esa parte del código nunca me convenció del todo. ¿Por qué elegí específicamente la versión 4.0 de MSXML? La verdad no lo recuerdo, creo que bebí algunas cervezas ese día.

Según la hoja de ruta de la API, resulta que la versión 4.0 no viene "de cajón" en Windows, sino que se instala con algunos otros productos. Y aunque es rara la vez que no está presente y muy fácil instalarla con esta actualización, creo que TghXMLDoc debería poder aprovechar alguna otra de las versiones disponibles en el equipo, sin que el programador o el usuario tenga que actualizar nada. Lo que propongo es que la clase no esté "casada" con esa versión en concreto, sino que sea flexible y pueda utilizar alguna otra versión de MSXML vigente.

La pregunta del millón es ¿cuál es la mejor estrategia? Lo primero que se me ocurrió fue que podría agregarle algún parámetro (en el constructor) o propiedad para indicar la versión de MSXML con la cual debe trabajar. Pero luego pensé que el constructor de la clase podría examinar el Registro de Windows para determinar qué versiones hay instaladas y elegir el ProgID más apropiado ("MSXML2.DOMDocument.6.0", "MSXML2.DOMDocument.4.0",...). OK, ¿y si el programador quiere que se use uno en particular? (suponiendo que haya razones válidas para ello). Por otra parte, ¿es eficiente que el constructor busque en el Registro cada vez que creemos una instancia de TghXMLDoc? ¿no sería mejor hacer una única búsqueda y guardar el resultado en una variable global/de clase? Y haciéndolo así, ¿no importaría que la aplicación ignorase la instalación de alguna versión de MSXML ocurrida después de haber creado ya el primer objeto TghXMLDoc y antes de crear otros más? ¿Qué problemas de incompatibilidad tendría la clase si le permitimos trabajar con diferentes versiones de MSXML? ¿qué previsiones tendríamos que tomar?

Sí leemos la tabla MSXML Releases de la hoja de ruta que mencioné antes, podríamos decir que actualmente sólo hay tres versiones estándares y vigentes que valdría la pena considerar: la 3.0, la 4.0 y la 6.0. Y quizá la preferencia debería ser de mayor a menor, pero Microsoft dice (cito parte de esa tabla): When MSXML 6.0 is not available MSXML 3.0 is generally the best fallback version. [Cuando MSXML 6.0 no está disponible, MSXML 3.0 es generalmente la versión anterior más adecuada].

Bueno, creo que habrán entendido el tipo de interrogantes que se presentan para mejorar esa parte tan importante de la clase. Les solicito algo de ayuda para flexibilizarla y que use la versión de MSXML que se tenga instalada (o la que el programador indique), y no forzosamente la 4.0. Ideas, código, seudocódigo, pros y contras...toda colaboración será bienvenida. De antemano, gracias.

Al González.