Catalis

Algunos detalles técnicos

Esta página presenta un resumen de los aspectos técnicos que sustentan el desarrollo de Catalis.

En función del interés que pueda haber sobre estos temas, iremos agregando explicaciones más detalladas de cómo se resolvieron algunos problemas —tales como la manipulación de subcampos repetibles, la generación automática de la puntuación, o la construcción de la ficha AACR2—, o bien de cómo se usan ciertas técnicas ya establecidas pero aparentemente poco difundidas —como el acceso a datos XML en un navegador vía JavaScript, o la creación/eliminación dinámica de elementos en un formulario HTML usando el DOM.

Además de la utilidad que Catalis pudiese tener en el contexto de la catalogación, nos gustaría también que sirviera como una muestra de lo que puede ofrecernos hoy en día un navegador web, considerado como plataforma para correr aplicaciones con interfaces de usuario “amigables”. En ese sentido, tal vez podría servir como modelo para el desarrollo de otras aplicaciones similares para bibliotecas, aunque no necesariamente vinculadas con MARC o con la catalogación.

Algunas referencias útiles sobre las tecnologías que aquí se mencionan, pueden encontrarse en la sección Enlaces.

ISIS

Catalis trabaja con bases de datos CDS/ISIS. El acceso a estas bases en el ambiente Web se realiza mediante el programa WWWISIS (conocido también como WXIS), de Bireme.

Para tareas de mantenimiento, control de calidad, y demás manipulaciones de las bases ISIS desde la línea de comandos, usamos los utilitarios CISIS de Bireme, principalmente mx, i2id e id2i.

Para poder implementar ciertos aspectos del formato MARC 21 con bases ISIS, hemos tenido que luchar un poco con el lenguaje de formateo, con resultados que, suponemos, podrían en algunos casos mejorarse. En particular, cabe mencionar que la FST utilizada para la generación del archivo invertido de la base bibliográfica contempla la indización de ocurrencias individuales de subcampos repetibles, descomponiendo (splitting) primero cada campo en subcampos, y luego recorriendo éstos para procesarlos de la manera apropiada.

Descripción de la estructura de las bases bibliográficas.

JavaScript

Hemos intentado que la mayor parte de las actividades que lleva a cabo Catalis se ejecuten en el cliente, limitando la comunicación con el servidor para lo indispensable: leer y grabar información en las bases de datos. Al momento de iniciar la sesión de trabajo, el navegador recibe un conjunto de datos y de funciones que le permiten realizar una gran parte de las tareas del sistema: importar un registro, colocar la puntuación ISBD, presentar plantillas para registros nuevos, generar visualizaciones, exportar un registro, presentar tablas de códigos, alterar la estructura del formulario de edición, etc. Esto nos ha llevado a que la aplicación se base muy fuertemente en el uso del lenguaje JavaScript.

DOM, CSS

Un aspecto clave que depende del uso de JavaScript, es el trabajo con formularios dinámicos: nos referimos a formularios cuya estructura se va adaptando a las necesidades del catalogador. Esto es posible gracias al DOM, o Document Object Model, el estándar para manipulación de documentos HTML (y XML) que los navegadores más recientes han implementado de manera bastante satisfactoria, y gracias al cual la relación entre una página HTML y un usuario puede volverse bastante diferente de la que conocimos en los primeros años de auge de la Web.

Junto con el DOM, hay un uso intenso de hojas de estilo (CSS, Cascading Style Sheets), que es la otra pieza necesaria para controlar los aspectos visuales de la interfaz.

XML

El trabajo con el formato MARC plantea la necesidad de contar con una gran cantidad de datos de manera más o menos permanente en el navegador, entre ellos:

• información sobre los campos, subcampos e indicadores del formato: nombres, repetibilidad, valores posibles, valores por defecto;
• tablas con códigos de idiomas y de países;
• tablas de códigos para los campos de control (leader, 007, 008);
• códigos usados en ciertos campos de datos, e.g. los códigos de relación (traductor, compilador, editor, etc.)

Para poder acceder a estos datos en el navegador, manteniéndolos al mismo tiempo en un formato que sea independiente del lenguaje específico empleado en esta aplicación —JavaScript—, nos pareció apropiado experimentar con el uso de documentos XML, aprovechando que los navegadores recientes tienen la capacidad de manipular XML tanto mediante métodos DOM como mediante XSLT.

Es por este motivo que entre los requisitos para el uso de Catalis aparece la versión 3.0 del MSXML (Microsoft XML parser).

Conexiones HTTP en el background

En interfaces de este tipo, es importante poder establecer conexiones HTTP con el servidor para enviar y/o recibir datos, y que como resultado de esa comunicación se actualicen elementos específicos de la pantalla, dejando inalterados los restantes.

Los frames de HTML no bastan para resolver este problema —aparte de que introducen complicaciones adicionales—, pero afortunadamente existen técnicas alternativas que dan buenos resultados. Kent Fitch las denomina synchronous background HTTP connections, puesto que el usuario no percibe los síntomas habituales de un navegador que está a la espera de una respuesta del servidor (el “mundito girando”, la página que demora en dibujarse). También se conocen como remote scripting.

Una de estas técnicas se basa en el uso de un IFRAME oculto, y es la que hemos adoptado en Catalis. Entre las ventajas que tiene este tipo de conexiones con el servidor, podemos mencionar:

• el contexto de trabajo del usuario se mantiene todo el tiempo, y la aplicación tiene un aspecto más estable,
• los datos que envía el servidor se reducen a lo indispensable, pues no necesita enviar páginas HTML completas, sino sólo datos “crudos” que luego serán procesados y posicionados adecuadamente en la página actual usando JavaScript. Estos datos, por otra parte, pueden enviarse con la estructura que creamos más apropiada para su manejo por parte del cliente, e.g. documentos XML u objetos de JavaScript.

Diseño de la interfaz de usuario

En el diseño de la interfaz, se intentó reproducir el entorno de trabajo que es habitual en las aplicaciones de escritorio:

• ventana de tamaño fijo en pixeles, que permite posicionar con alto grado de precisión los elementos del área de trabajo;
• scroll vertical limitado a ciertas porciones de la página (no es necesario “bajar y subir” por la página como un todo, como sucede frecuentemente en la Web);
• uso de cuadros de diálogo (ventanas modales) para solicitar información al usuario.

La elección de colores y tipografía está guiada por el propósito de mantener una alta legibilidad, y de no fatigar la vista de alguien que deba trabajar por largos períodos con la herramienta. Esperamos haberlo logrado, pero por supuesto aceptamos sugerencias al respecto.

Acerca de la restricción sobre los navegadores

No hemos pretendido que la aplicación sea utilizable en forma general con navegadores antiguos, como Netscape 4.x o IE 4, por no hablar de navegadores que no usen JavaScript. Si apuntamos a navegadores “modernos” es por el simple hecho de que cuentan con un considerable soporte de los estándares establecidos por el W3C, y por lo tanto brindan una plataforma de desarrollo que permite construir interfaces gráficas de cierta complejidad, y más fácilmente portables entre plataformas.

Dentro de los navegadores actualmente disponibles, la elección (en 2002) de Internet Explorer fue motivada a su vez por estas razones:

• Su amplia difusión, lo que minimiza la necesidad de estar descargando e instalando software adicional para testear la aplicación (un argumento cada vez más débil, por cierto, pues el “esfuerzo” de bajar e instalar un navegador como Mozilla Firefox —ex Firebird— se ve hoy en día más que recompensado por la calidad del producto obtenido).
• La disponibilidad de extensiones propietarias que facilitan la implementación de algunas de las características deseadas para la interfaz de usuario.

No es ésta, de ninguna manera, una elección definitiva, y al respecto podemos citar un párrafo de un interesante trabajo de Kent Fitch:

I'm also assuming that although you may recognize the “market reality” of 90% market-share for IE, you may also not want to forever lock yourself into IE, so you'll be hoping to deploy a solution which vaguely adheres to some Javascript and DOM standards and avoids as far as possible obvious “Microsoft only” approaches such as scripting-MS-Word, or ActiveX controls. A version of your application which used the Netscape 6 implementation of the DOM for example should be at least “plausible”.

En la sección Planes agregamos algo más sobre este punto.

Herramientas utilizadas

Catalis ha sido desarrollado inicialmente bajo el sistema operativo Windows Me, y luego bajo Windows 2000 Professional, usando un servidor Apache 1.3.x en forma local. Actualmente, el desarrollo se realiza en Linux.

Como editor de texto se usó inicialmente HTML-Kit, posteriormente SciTE y Bluefish.

Las imágenes usadas en estas páginas fueron capturadas y manipuladas con XnView.