El profesional de la información


Junio 1994

Los documentos compuestos vivos, base de los futuros sistemas orientados al documento

Por Isidre Canals

Isidre Canals, Inst. d'Estadística de CatalunyaEn su magnífico artículo "Sistemas de gestión documental", publicado en IWE-21, febrero de 1994, Lluís Codina trazaba un panorama sobre las tendencias actuales, que iba más allá, a pesar de su título, de los sistemas documentales; incluso puedo preguntarme si no tuvo problemas para decidir dónde detener el alcance del artículo.

La razón es determinante: es toda la informática la que, dentro de la corriente de fondo de la orientación a objetos (OO), se reconvierte para entronizar al "documento" (dando a este término su sentido más amplio) como centro de los nuevos sistemas, a los que algunos llaman docucéntricos o sistemas orientados al documento (1)

En consecuencia, si hasta ahora a los profesionales de la documentación nos podía bastar con estar al corriente de los desarrollos del software tradicionalmente considerado como documental (2) (aunque, significativamente, hemos tenido que ir ampliando el campo, primero a programas de tratamiento de textos y hojas de cálculo, y después a hipertexto/hipermedia, cd-rom y multimedia), en los tiempos que se avecinan esto ya no será suficiente.

El software de base de nuestro trabajo profesional (cada vez más diversificado, por lo demás) será más general y polivalente, con grandes posibilidades de integración de funciones, muy "personalizable" o adaptable al usuario, ya sea personal o institucional, mediante la combinación de "cápsulas" pequeñas de software muy especializadas, en lugar de los grandes y voluminosos programas actuales.

Y, por otro lado, y esto es fundamental, los "objetos" o "documentos" con los que trabajemos habrán de tener características normalizadas, que los hagan independientes de (y, por lo tanto, compatibles con) cualquier plataforma o sistema operativo ( PC/Windows, Macintosh, estaciones Unix, etc.), para hacer posible el trabajo verdaderamente en colaboración en el seno del/de los grupos en los que estemos insertos.

Diversas y quizá conflictivas son las perspectivas y enfoques con los que se puede describir la evolución hacia esta situación o definir técnicamente el objetivo final. Pero es importante hacerlo, puesto que de ello dependerá el diseño de la ruta técnica que la industria informática tenga que seguir. Por ejemplo, no será lo mismo que los sistemas hipertexto/hipermedia evolucionen por sí mismos, de forma autónoma, que si les asignamos funciones específicas en un marco más general.

Los "sistemas hiperdocumentales abiertos" de Engelbart

Esto último es lo que hace Douglas Engelbart, uno de los pioneros (junto con Ted Nelson ) del hipertexto, cuya "visión del futuro" es la más enriquecedora y completa que conozco. No en vano es el resultado evolutivo de su trabajo brillante y coherente durante 30 años que, dicho sea de paso, merecería ser más ampliamente conocido y apreciado por los documentalistas, por muchas razones.

Baste decir que, aun siendo el inventor, ya en los años sesenta, de muchos de los artilugios ahora corrientes (como, por ejemplo, el ratón, la interface de ventanas o la teleconferencia en pantalla compartida), ha defendido siempre la importancia decisiva de los componentes "humanos" (modos, procedimientos, normas, lenguajes...) respecto de las "herramientas" (tanto hardware como software ) (3).

Pues bien, Engelbart ha analizado minuciosamente las características, componentes y requerimientos de los que llama "sistemas hiperdocumentales abiertos" (open hyperdocument systems, OHS), y ha desarrollado paralelamente varias generaciones de su prototipo Augment, que no se contenta con ser una plataforma de trabajo cooperativo documental en grupo, sino que añade requerimientos sobre procedimientos y modos de trabajar, y define también toda una tipología estructurada de la información y los documentos (generados en el seno de cualquier organización), que convierten el conjunto en una verdadera plataforma abierta de producción, transferencia y acumulación de conocimientos (4).

Los OHS de Engelbart y su situación actual merecen que les dediquemos por lo menos algún artículo futuro. Pero ahora mismo el objeto de éste, que quiere jugar un papel complementario al de Lluís Codina, es el de ilustrar un desarrollo concreto, que puede considerarse un componente necesario de la evolución hacia los sistemas futuros a la que hacíamos referencia anteriormente.

Digamos, para centrar el tema del que queremos hablar, que los nuevos sistemas informáticos permitirán trabajar con lo que llamaremos "documentos compuestos vivos " (5), es decir, una especie de contenedores o recipientes ( repositories en inglés), cuyos componentes son piezas heterogéneas de información, que pueden haber tenido origen en diversas aplicaciones informáticas (un procesador de textos, un gestor de proyectos, una base de datos, una hoja de cálculo, etc.) y que (y esta particularidad es decisiva) continúan "ligados" a ellas, de manera que tales documentos compuestos son realmente sistemas integradores de aplicaciones, y sus componentes objetos reprocesables.

Ahora bien, para conocer las características de estos nuevos sistemas, podemos empezar por preguntarnos, con carácter general, si sabemos en realidad a qué tipo de "documentos" nos referíamos cuando decíamos que la nueva informática se orienta a los "sistemas centrados en el documento".

Un primer nivel: documentos compuestos "pasivos"

Por una parte, podemos aludir con ello al hecho de que los nuevos sistemas serán capaces de reconocer y tratar piezas de información más cercanas a los documentos reales que su sola componente textual, a través de la traducción electrónica de todos sus componentes.

Es decir, documentos que no sólo contienen texto, sino también gráficos e imágenes, juntamente con una presentación formal tipográfica y compositiva "rica", tal como se presentan los actuales documentos impresos: son lo que llamamos comúnmente documentos compuestos. Esto implica que, para su tratamiento informático, necesitamos estándares que no sólo reconozcan las distintas partes materiales de los documentos sino también su formato o "composición" y las relaciones lógicas entre ellas (entre un párrafo y una nota al pie de página, y entre una ilustración y su pie, p. ej.). Estándares que nos permitan, pues, integrar las distintas partes de un documento compuesto en un "objeto" (6), como hacen, por ejemplo, sgml (standard generalized mark‑up language) y ODA (open document architecture), entre otros, de forma distinta cada uno.

Por otra parte, cuando trabajamos en un entorno de interface gráfica de usuario (GUI), sea Macintosh, MS/Windows, X‑Window, etc., y sobre todo, en la medida en que trabajemos en el seno de un grupo (o simplemente en red), lo que desearíamos poder hacer es intercambiar de forma transparente nuestros "documentos compuestos" entre aplicaciones y entre usuarios, sin que pierdan la riqueza visual y formal de origen ni la relación lógica entre sus partes. Es lo que nuevos estándares, como PDF (portable document format) de Adobe (7), Replica, Commond Ground o TrueType o el anunciado Bento de Apple pretenden, así como también CDA (compound document architecture) de Digital.

Lo significativo es que estos estándares (mejor dicho, propuestas de estándares "de facto") son componentes de verdaderos sistemas integradores de aplicaciones ( PDF lo es de Acrobat, y Bento de OpenDoc y CDA es integrable a LinkWorks, v. más adelante) a nivel de usuario final, lo cual permite reconocer la íntima relación existente entre arquitecturas de documentos compuestos y las interfaces gráficas de usuario (8). Es una relación que se deriva del hecho de que ambos enfoques utilizan el modelo "objeto", aunque sólo sea como referencia conceptual.

Un segundo nivel: documentos compuestos "vivos"

Precisamente por esta razón estos sistemas integradores de aplicaciones permiten ir más allá en el concepto de documento compuesto, abriéndose paso el concepto de documento compuesto vivo, cuyas partes permanecen ligadas a las diferentes aplicaciones que les han dado origen, y que puede definirse como "recipiente de piezas de información diversas y sus relaciones, así como de las aplicaciones requeridas para procesar aquellas" .

Así, en palabras de Marshak : "Los documentos compuestos (vivos) (9) son más que documentos que contienen gráficos, imágenes escaneadas y texto. Son verdaderos entornos aplicativos que contienen objetos reprocesables de todo tipo" (10).

Este es el concepto de documento compuesto en que, por ejemplo, se basa la arquitectura de "incrustación y ligadura de objetos" OLE (object linking and embedding) de Microsoft, en su versión 2.0 (11), de LinkWorks de Digital, o bien de OpenDoc, que Apple ha empezado a distribuir recientemente en su versión beta a los desarrolladores del mundo que trabajan bajo esta plataforma.

Este hecho nos da pie para describir sucintamente en qué consiste OpenDoc, como ilustración de lo que pueden depararnos estos nuevos sistemas. Y lo haremos huyendo de tecnicismos, desde el punto de vista del usuario.

OpenDoc, arquitectura para los documentos compuestos vivos

Para empezar, digamos que OpenDoc no es un simple software de aplicación sino una arquitectura de base, orientada a objetos, y pensada para hacer posible, de una parte, la simplificación de los programas y su combinabilidad por el usuario; y, de otra, como dice un documento técnico de Apple (12) "el desarrollo de aplicaciones totalmente integradas y operativas a través de plataformas cualesquiera y redes distribuidas".

Para comprender rápidamente los beneficios que para los usuarios representa OpenDoc, pondremos un ejemplo: el de la edición de textos.

¿Qué ocurre en estos momentos con los programas informáticos disponibles para ordenadores de sobremesa? Que como consecuencia de la acusada competencia con la que se enfrentan los fabricantes, son cada vez más sofisticados (y voluminosos) e incluyen mayor número de funciones, además de la que hace su especialidad. Una que todos ofrecen es la de edición de textos; y no sólo los procesadores de textos, para los que ello es su parte esencial, sino también hojas de cálculo, bases de datos, gestión de proyectos, sistemas gráficos o hipertextos.

Lo que ocurre es que, para el usuario, los editores de textos correspodientes difieren unos de otros en sus prestaciones y en su modo de trabajar. Por ejemplo, el editor de una hoja de cálculo o de una base de datos puede ser muy pobre comparado con el procesador de textos favorito de un usuario, que además conoce muy bien. ¿No sería mejor que se pudiera elegir y utilizar el mismo editor siempre, cualquiera que fuese la aplicación? Y ello de forma transparente, sin que tuviéramos que pasar expresamente de una a otra aplicación, ni preocuparnos de posibles incompatibilidades?

Yendo aún más lejos, ¿no sería fantástico que pudiéramos montar, a la manera de un juego de construcción, la combinación de "partes" o funciones más adaptada a nuestras necesidades concretas? Y sin perder por ello la posibilidad de compartir de forma abierta y transparente nuestros documentos con los integrantes de nuestro grupo de trabajo o cualquier otro?

Pues éste es, precisamente, el objetivo de OpenDoc. Pero además añadiendo otro aspecto importante: el de que podamos no sólo combinar piezas de software sino también "partes" de documentos, o sea, piezas de información que constituirán nuevos "documentos compuestos", pero que conservarán toda la funcionalidad de la pieza de software que les dio origen. Es más, podremos mantener ligaduras ( links ) entre una "parte" y otros documentos o aplicaciones, de manera que se actualice o modifique como consecuencia de cambios en estos últimos. De ahí que hablemos de "documentos compuestos vivos ", puesto que ellos y cada una de sus "partes", independientemente, siguen siendo objetos reprocesables.

La figura ilustra de forma simple el funcionamiento de OpenDoc

¿Qué es OpenDoc?

Ejemplo de OpenDoc

En el ejemplo, Folder One es el nombre de un documento compuesto mediante OpenDoc, conteniendo diversos "documentos" o "partes" originadas en aplicaciones diversas, de las que conservan consigo no sólo el formato sino también su capacidad de proceso (a nivel variable, pero por lo menos de visualización).

La figura muestra cómo seleccionando y arrastrando una "parte" en formato tiff y copiándola en un documento textual de otra ventana, se abre como una nueva "parte" de este documento compuesto. Y ello, aun en el caso de que el documento nos haya sido transmitido por otro usuario, sin necesidad de disponer de las aplicaciones completas que éste puede haber utilizado.

Figura reproducida con autorización de Apple Directions, agosto 1993.

Pero la lucha de estándares sigue

Claro que, para que esto suceda con carácter general, es preciso que los fabricantes de software adopten la arquitectura OpenDoc y, complementariamente, también el estándar Bento para el formato de documentos compuestos, y construyan entonces futuras "cápsulas" simples de software, según la filosofía subyacente.

Para facilitar esta evolución, Apple, por un lado, ha establecido la libertad de uso del código fuente de OpenDoc (contrariamente a la política de Microsoft con su OLE ); y, por otro, intenta que los grandes actores de la industria informática adopten oficialmente esa arquitectura, por lo menos haciéndola transparente a la suya propia.

En este sentido, baste decir que, además de Apple, IBM y Taligent, han adoptado ya la arquitectura OpenDoc y el estándar Bento : Novell, WordPerfect, Oracle y Xerox, a los que se ha sumado recientemente Hewlett Packard, agrupados en el consorcio CIL (Component integration laboratories). Lo que no impide, por otra parte, que Apple y Microsoft hayan llegado a un acuerdo para hacer mutuamente transparentes la versión Windows de OpenDoc y OLE. Por cierto, otras versiones de OpenDoc están siendo preparadas para OS/2 y Unix.

Naturalmente, puede discutirse cuál será el estándar (o conjunto de estándares) vencedor en la lucha por la inter‑operabilidad entre documentos y entre plataformas; aunque, por el momento, lo que ocurre es que los contendientes no se alinean rígidamente en una única posición. Por el contrario, se multiplican las ocasiones en las que una misma empresa participa en alianzas promovidas por adversarias, o que responden a estrategias aparentemente contradictorias.

La razón estriba en que el resultado final es muy incierto y la prudencia aconseja "no poner todos los huevos en el mismo cesto".

Ello no es óbice para que la lucha sea real y existan estrategias realmente en competición.

Para poner un ejemplo paradigmático, la estrategia impulsada por la alianza Apple‑IBM con la creación de Taligent, se propone como objetivo declarado el diseño y creación de un sistema operativo radicalmente nuevo, orientado a objetos (OO) "de arriba abajo" ( top to bottom ), en expresión de su presidente. Estrategia a la que se han adherido los componentes de CIL ya citados, desde su creación en septiembre de 1993. Y es en ese marco global en el que se inscriben los desarrollos concretos actuales, como OpenDoc, que constituyen la avanzadilla del futuro sistema.

Sin embargo, Bill Gates, presidente de Microsoft, hace bandera de su posición contraria, en el sentido de que no cree necesaria la creación de todo un sistema operativo OO para avanzar por pasos en la incorporación paulatina de esta filosofía informática.

Precisamente esta posición tajante del líder que controla el mercado mundial del software para ordenadores de sobremesa, está siendo criticada por los que la interpretan como un freno por razones comerciales al prometedor desarrollo y expansión de la OO. Los primeros en la crítica son, naturalmente, los abanderados de la OO a través del Object management group (OMG), que impulsa el estándar de informática distribuída Corba 2.0 (Common object request broker architecture), adoptado ya, por ejemplo, por IBM, Apple, Digital, Sun, Hewlett Packard, etc., para sus plataformas de interoperabilidad o integración entre aplicaciones.

Pero la orientación a objetos, que es el tema de fondo, es tan importante que merece ser tratado en otra ocasión.

Referencias:

  1. Véase p. ej. Cary Lou, "Objects for end users", Byte, dic. 1992.
  2. Admitiendo, por otra parte, la ambigüedad de la que habla Lluís Codina en su artículo.
  3. Véase un resumen en: D. C. Engelbart y H. Lehtman, "Working together. The 'human system' and the 'tool system' are equally important in computer-supported cooperative work", Byte, dic. 1988.
  4. D. C. Engelbart, "Knowledge-domain interoperability and an open hyperdocument system", Proceedings Cscw'90, Los Angeles.
  5. Término que se utiliza en el contexto de este artículo para diferenciarlos de los "documentos compuestos" comunes o "pasivos". Pero en la literatura, la ambigüedad es la regla, y sólo el contexto permite diferenciarlos.
  6. Cuya naturaleza electrónica permite además ampliar el concepto de "documento" en la dirección multimedia, incorporando voz, sonido e imagen en movimiento, y las relaciones entre ellas.
  7. Véase el Informe especial de IWE-22 (marzo de 1994), p. 11, 13-14 (autor Pedro Hípola ).
  8. Llamadas, más propiamente, por Shneiderman "interfaces de manipulación directa".
  9. El mismo término "documento compuesto" se utiliza para los dos conceptos que hemos definido, con lo que hay que interpretar en qué sentido lo utiliza cada autor.
  10. Ronni Marshak, Paradigm Shift, 25 febr. 1991.
  11. Ampliado ahora con la arquitectura Chicago (para Windows/NT), que Microsoft ha empezado a distribuir también en su versión beta a sus desarrolladores, y que competirá directamente con OpenDoc.
  12. Apple Computer, OpenDoc white paper, 1994.

Isidre Canals, Institut d'Estadística de Catalunya

Via Laietana 58, 08003 Barcelona

Tel.: +34‑3‑412 00 88; fax: 412 31 45

canals@ines.es

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1994/junio/los_documentos_compuestos_vivos_base_de_los_futuros_sistemas_orientados_al_documento.html