El profesional de la información


Septiembre 1999

Xml orientado a objetos

Por Antonio de la Rosa

Resumen: SOX (Schema for object oriented xml) es una especificación heredera de xml que aporta algunas características de la orientación a objetos. Trata de aumentar la interoperabilidad de xml con algunos lenguajes de programación. El artículo pretende, en primer lugar, repasar las nociones de la orientación a objetos y aplicarlas al entorno sgml-xml. Después analizar las afinidades y diferencias entre xml y SOX y señalar las posibilidades de este último. Finalmente, reseñando los esfuerzos de Marc, las Aacr2 y algunos tipos de metadatos para catalogar eficientemente los recursos www, especular sobre si SOX o la orientación a objetos podrían tener algún papel en este sentido. En concreto se analiza la aplicación de algunas nociones como clases, objetos, jerarquía y herencia a la identificación de los documentos electrónicos (ya sea por medio de catalogación tradicional ya mediante metadatos). ¿Podría, por ejemplo, heredar un capítulo determinadas características de su elemento contenedor: el documento?

Palabras clave: SOX (Schema for object oriented xml), Xml, Sgml, Orientación a objetos, Clases, Objetos, Herencia, Estructuras arbóreas de datos, Marc, Aacr.

Title: Object-oriented XML

Abstract: SOX (Schema for object oriented xml) is one of xml’s inheritor specifications that endows xml with object orientation features. Also attempts to increase xml’s interoperativity with same programming languages. The article first reviews certain concepts related to object orientation and applies them to the sgml-xml environment. Then similarities and differences between xml and SOX are analyzed, and the potential scope of the latter is highlighted. Finally, certain initiatives using Marc, Aacr2 and metadata for efficiently cataloguing www resources are reviewed, including the potential role that SOX or object orientation could play in these efforts. Specifically the use of certain concepts, such as classes, objects, hierarchy and inheritance, for identifying electronic documents (either by traditional cataloguing or metadata) is analyzed. For example, could a chapter inherit some features from its container element: the document?

Keywords: SOX (Schema for object oriented xml), Xml, Sgml, Web, Object orientation, Classes, Objects, Inheritance, Tree structures of data, Marc, Aacr.

Rosa, Antonio de la. “XML orientado a objetos”. En: El profesional de la información, 1999, septiembre, v. 8, n. 9, pp. 4-23.

Para gestionar con eficacia gran número de archivos, Unix estableció su famosa jerarquía: directorios, subdirectorios, archivos..., en la que, generalmente, los archivos con temática similar se agrupan juntos en directorios que, a su vez, se sitúan próximos a otros relacionados, etc.

Si se dibujara un esquema vertical de esta estructura jerárquica de archivos, subdirectorios y directorios resultaría una especie de árbol. Del mismo modo, si se aplicara el mismo esquema a la organización interna de un documento sgml o xml se obtendría otra ordenación arbórea. La única diferencia con el primero sería que los nodos son capítulos, párrafos, etc., en lugar de archivos o directorios. ¿Sería posible integrar estas dos jerarquías en un solo esquema?

Un documento electrónico puede concebirse como una base de datos con su correspondiente esquema y diseño interno. ¿Sería factible integrar esa estructura en una mayor? La única forma de conseguirlo es utilizar un formato que permita, por un lado, el diseño de estructuras jerárquicas arbóreas y, por otro, el tratamiento de los nodos como objetos. Este formato puede ser xml junto con las especificaciones que se están desarrollando sobre él, como Smil (Synchronized multimedia integration language) para multimedia, SOX para objetos o xml-ql (eXtensible markup language – query language) como lenguaje de consulta a bases de datos.

Objetos. Estructuras de objetos. Objetos en el www

Muchos de los conceptos subyacentes a la orientación a objetos existen desde hace más de treinta años y, sin embargo, la tecnología orientada a objetos es una disciplina relativamente reciente que ha surgido como respuesta a lo que se llamó la “crisis del software”.

La causa se encuentra en que anteriormente, con los medios de programación tradicionales, la gestión de un gran sistema software era más difícil que mantener otros tipos de estructuras complejas como puentes o aviones.

Esta situación causó problemas bien conocidos: los grandes sistemas excepcionalmente se atienden a sus plazos de desarrollo y nunca a su presupuesto inicial. Muchas veces no cubren el ámbito para el que se suponía que estaban diseñados, se quedan obsoletos enseguida, etc.

La tecnología orientada a objetos —se puede encontrar en la bibliografía en inglés con las siglas OT (Object technology)— se concibió como la principal respuesta a ese problema. Al igual que en cualquier disciplina moderna, la OT todavía no tiene una estructura ni una nomenclatura precisa. Hasta hace poco tiempo se confundían y superponían distintos enfoques: OOP (Object oriented programming), OOD (Object oriented development), OO (Object orientation) y Ooa/d (Object oriented analysis and design). Actualmente cada uno de estos enfoques ocupa un lugar más o menos delimitado dentro de la OT.

La programación orientada a objetos es un proceso en el que se construye un mapa entre el dominio del problema y el software.

De acuerdo con este punto de vista, la crisis del software se produjo porque este mapa era muy difícil de crear con las viejas técnicas y herramientas de programación —especialmente las metodologías y los lenguajes—, que estaban muy lejos de poder formular con fidelidad entidades del mundo real y demasiado cerca de los aspectos estructurales de los ordenadores.

Basándose en esto, el planteamiento fundamental es aumentar la representatividad del lenguaje hasta que pueda expresar eficazmente cualquier dominio y, de esta forma, abordar cualquier problema.

Objeto. Es una entidad informativa que puede ser manipulada individualmente y puede tratarse de información de cualquier tipo. En programación orientada a objetos se cuenta con datos y procedimientos (métodos) para manipular dichos objetos. Teniendo en cuenta esto, objeto sería el mecanismo básico que se usa para representar las entidades del mundo real. Tiene tres atributos fundamentales: estado, comportamiento e identidad.

El estado es el conjunto de valores de datos que el objeto comprende y que puede cambiar a lo largo de su vida. Si se considera como objeto el asiento bibliográfico asignado a un sitio web, se ve que puede englobar muchos campos de datos: nombre del autor, organización que lo mantiene, número de enlaces, URL, etc. La información en cada uno de esos campos puede cambiar. Es más, teniendo en cuenta las características del www, con toda probabilidad lo hará muchas veces.

En un contexto sgml-xml, el estado sería el conjunto actual de los valores de sus atributos. En el caso de un objeto compuesto por la combinación de otros —por ejemplo, un documento sgml o xml compuesto de elementos— la definición anterior incluiría los valores de los atributos de los objetos que lo componen.

Algo muy importante en el desarrollo de una aplicación orientada a objetos es determinar los posibles cambios que puede presentar y el papel de las transiciones de estado. Sin embargo, salvo excepciones, los datos sgml y xml son relativamente estáticos —no cambian mientras la aplicación está en funcionamiento, ya que se asignan cuando se crea el objeto y no suelen sufrir alteraciones de estado—. Por lo tanto la pregunta sería si pueden la automatización y la orientación a objetos influir en la dinamización de los datos sgml o xml.

La identidad es un identificador inmutable (generalmente asociado al objeto en el momento de su creación) que lo caracteriza a todos los efectos. Si se considera como ejemplo de objeto el registro bibliográfico online de un recurso www se podría, eventualmente, utilizar como identificador un DOI (Digital object identifier).

Los dos últimos métodos no son relevantes para cualquier elemento sgml-xml

DOI es un identificador permanente que se puede utilizar en documentos web. Los usuarios que quieran conectarse a un recurso con un DOI asignado que haya cambiado su dirección pueden ser redirigidos automáticamente. Una agencia centraliza toda la información sobre estos documentos, de modo que si se tiene su DOI se puede recuperar sin necesidad de conocer exactamente su localizador.

El sistema DOI fue ideado por la Association of American Publishers y la Corporation for National Research Initiatives. Hoy es gestionado por la DOI Foundation y se pretenden crear más delegaciones a imitación de las agencias que gestionan el Isbn.

Un ejemplo de DOI: 10.1002/IsbnJ0-471-58064-3.

“10.1002” identifica el directorio. Lo que hay tras “/” es el identificador del libro en particular al que pertenece el documento web. “3” indica el capítulo en el libro. Este DOI podría asociarse con una página o URL específicos en el directorio:

http://www.doi.org/10.1002/IsbnJ0-471-58064-3

Aquí “www.doi.org” es el directorio central. Su función es responder a la anterior petición, localizando la URL asociada al DOI en cuestión y enviársela de vuelta al usuario.

En caso de que los identificadores “semánticos” (DOI por ejemplo) puedan ser cambiados a lo largo de la vida del objeto, se asociarían también a éste identificadores en el ámbito de implementación/programación sin ningún significado.

http://www.doi.org

El comportamiento de un objeto es el conjunto de operaciones a las que puede ser sometido. Siguiendo con el ejemplo anterior de asiento bibliográfico, éste podría ser presentado en pantalla. El comportamiento actúa entonces como interfaz por medio del cual los usuarios pueden acceder a la funcionalidad del objeto y cambiar su estado.

Booch define comportamiento como “la forma en que un objeto actúa y reacciona en términos de sus cambios de estado y su gestión de los mensajes”. Definirlo significa escribir el código para que cada clase pueda responder a los mensajes enviados a los objetos de esa misma categoría.

Una buena DTD (Document type definition) evita deliberadamente la definición del comportamiento de un elemento con el fin de dar a los desarrolladores la máxima flexibilidad posible en el uso de los datos. Por lo tanto, la definición del comportamiento de los elementos (sgml, xml o SOX) es el primer paso para integrar esos elementos en sistemas orientados a objetos y podría llevarse a cabo mediante una aplicación externa. De este modo, usando la DTD solamente como referencia, se podría mantener la integridad de los datos.

Clases. Es el patrón a partir del cual los objetos son creados. En otras palabras: un objeto no es más que uno de los casos u ocurrencias de una determinada clase. Especifican la estructura que todos los objetos asociados a ella deben mantener, es decir, son categorías de objetos. Por ejemplo, la clase forma podría contener los objetos: círculos, rectángulos, triángulos, etc. La función de forma sería definir las propiedades comunes de círculos, rectángulos, triángulos, etc.

El uso que el entorno sgml-xml puede hacer de los conceptos clase y objeto es más limitado. Se recurre a identificar las definiciones sgml-xml de documento y elemento con el concepto clase, mientras que los casos actuales de documentos y elementos desempeñan el papel de objetos. En la sección 4.102 de la norma ISO 8879 (sgml) se define tipo de documento como una clase que posee características similares; por ejemplo periódicos, artículos, manuales técnicos o memorandum. Los tipos de elementos son definidos de forma similar, lo que unido al uso de los atributos sgml-xml para identificar esas características comunes, aproxima bastante las DTDs a las clases y las ocurrencias de documentos y elementos a los objetos.

Si se quisiera que un documento o clase fuera un asiento bibliográfico para recursos web, se debería definir una serie de elementos, atributos y relaciones. Para establecerlos se podrían seguir las indicaciones de la International standard bibliographic description for computer files Isbd (CF)— llamada ahora International standard bibliographic description for electronic resources Isbd (ER)— publicada en 1997.

Un ejemplo de lo que se podría hacer es: las clases definen tipos que se usan para especificar variables, prototipos de función, etc. y asociarles información. Así, en el registro bibliográfico citado, se haría la siguiente declaración del tipo “int”: int t, tp, tc, seguida de la asociación de información a las variables:

t= título [Marc 245 (NR) ‡a (puede incluir ‡n, ‡p), 246(R)]

tp= título paralelo [Marc 245 (NR) ‡b, 246 (R)]

tc= t+tp

Esto podría usarse, a efectos de programación, para gestionar los registros de recursos www. Por ejemplo:

tc= [245 00] Electronic journal of communication ‡h [computer file]+[246 31] ‡b Revista electrónica de comunicación.

Ocurrencia o caso. Como se ha visto, una clase define un conjunto de objetos infinito. Los cuales son, de hecho, ocurrencias o casos de esa clase. Cada ocurrencia puede presentar un valor propio para cada atributo, sin embargo, éste es el mismo para todos los objetos de la clase.

Atributo. La norma ISO 8879 define atributo como una cualidad característica de un elemento distinta de “tipo” o “contenido”. Sgml reconoce dos niveles de atributos: primarios y secundarios.

Los primarios son los “identificadores genéricos”. Atributos únicos para cada tipo declarado de elemento. Los atributos adicionales que caracterizan a un elemento son considerados secundarios.

Una aplicación orientada a objetos construida sobre datos sgml o xml usaría los “identificadores genéricos” para descubrir a qué clase pertenece el elemento-objeto en cuestión, y los atributos secundarios como conjuntos de valores asociados a la ocurrencia actual del elemento-objeto.

Evolución de algunoslenguajes de programación orientada a objetos

Métodos y mensajes. Es una determinada acción que se ejecuta cuando un objeto recibe un mensaje. El concepto método es muy similar al de procedimiento, función o rutina de los lenguajes de programación procedurales —los tres se refieren a una sección del programa que cumple una tarea específica—. La única diferencia es que en la programación orientada a objetos un método siempre se asocia a una clase.

Cada una de ellas posee un conjunto de métodos que constituyen su interfaz y que define el comportamiento de los objetos contenidos en ella. Los mensajes son los únicos medios que tienen los objetos para comunicarse e interactuar. Son éstos o los usuarios quienes invocan los métodos mediante mensajes mandados al objeto en cuestión.

Herencia. Es el mecanismo por el cual una clase (subclase) se deriva de otra (superclase), proceso que implica dos cuestiones:

a. La estructura de la superclase es heredada por la subclase. Los atributos y métodos de la primera también se hallan disponibles en la segunda, lo que permite que el código se reutilice.

b. Si la clase B se deriva de la clase A, cualquier objeto del tipo B pertenece también a la clase A.

Por estas dos razones la herencia sirve para reducir considerablemente la complejidad de un sistema, ya que la inmensa mayoría del código puede relacionarse con las abstracciones de las raíces de la jerarquía en lugar de hacerlo con las de cada una de las clases y subclases del sistema.

Bases de datos multimedia en el www

Últimamente las bases de datos multimedia han empezado a enfrentarse a dos de los problemas más importantes que se les presentaban a los desarrolladores de recursos web: controlar la proliferación de información digital y generar páginas complejas e interactivas. En este sentido hay cuatro tipos de bases de datos compitiendo por la atención de los webmasters y los productores multimedia:

  • Los tradicionales modelos relacionales (Rdbms) de Oracle, IBM, etc.
  • Las orientadas a objetos (Oodbms).
  • Los híbridos o bases de datos relacionales orientadas a objetos (Oordbms), como Illustra.
  • Un número creciente de bases de datos desarrolladas específicamente, como por ejemplo Cinebase.

Los productores de sistemas gestores de bases de datos relacionales como Oracle, Informix, Sybase, Computer Associates, IBM y Microsoft mejoran continuamente sus productos en capacidad, velocidad, amigabilidad y compatibilidad entre distintas plataformas. El principal argumento que siempre han esgrimido es que estas herramientas comparten un lenguaje de consulta estandarizado: SQL (Structured query language).

Sin embargo, los Rdbms presentan problemas al enfrentarse con el proceso de imágenes, vídeo, sonido o datos espaciales, ya que no fueron diseñados para ello. En general, se puede almacenar casi cualquier cosa en una base de datos tradicional, pero solamente como Blob (Binary large object).

Cualquier tipo de dato que trasciende la relativa simplicidad del formato alfanumérico es un Blob, una masa confusa de bytes impermeable a la búsqueda, indexación o comparación, y esencialmente relegada a la categoría de “información no procesada”. La base de datos no la gestiona y deja este proceso para las aplicaciones cliente específicas.

Actualmente, cuando las grandes compañías están almacenando y publicando masivamente información multimedia en cd-rom, intranet y www, los productores de bases de datos tratan de aumentar las capacidades del modelo relacional de sus respectivos servidores para mejorar el tratamiento de datos complejos, lo que está degenerando en una auténtica batalla comercial.

Oodbms (Sistemas gestores de bases de datos orientados a objetos). El argumento principal de las firmas productoras de Oodbms es que, puesto que el modelo relacional se basa en tablas, se ve superado cuando las relaciones entre los elementos se vuelven muy complejas.

Las bases de datos relacionales distribuyen vínculos entre muchas tablas y deben procesarlos uno por uno. Emparejar todas esas tablas y sus componentes exige un proceso que consume mucho tiempo. Una base de datos orientada a objetos almacena la información sobre las relaciones de sus componentes junto a los datos.

Es necesario puntualizar algunos términos:

  • Modelo de datos: es una representación lógica de los datos, sus relaciones y sus restricciones.
  • Modelo de objetos: combinación del modelo de datos con otro de comportamiento de los objetos basado en principios de la orientación a objetos.
  • Oodb (Object oriented database): colección de objetos persistentes definida por un modelo de objetos.
  • Lenguaje DB: una sintaxis para representar y manipular esa colección.

Dado que los Oodbms deben admitir la gestión de los datos por una parte y, por otra, proporcionar un completo soporte para la orientación a objetos, necesariamente son productos complejos. Por ejemplo, el modelo de objetos no solamente define los datos sino también su comportamiento. Así pues, un Oodbms debe ofrecer mecanismos que permitan gestionar el comportamiento de los objetos en la base de datos, incluyendo módulos que gestionen la evolución del esquema, etc. Otro punto difícil es la generación de índices. Este sistema depende en gran medida del uso de la herencia, lo que obliga a que se definan clases o jerarquías.

Sgml-xml y las bases de datos orientadas a objetos. Tal como lo describen los desarrolladores, estos modelos se convierten en una base de datos orientada a objetos mediante la adición de una característica: la persistencia. Es lo que permite que los objetos existan después de que la aplicación que los procesa se haya detenido, de esa forma están a disposición del usuario cuando se activa de nuevo.

Ésta es una característica muy importante a la hora de pensar en sistemas sgml-xml orientados a objetos puesto que, en estos modelos, los documentos y sus elementos existen independientemente de que se estén ejecutando o no las aplicaciones que los procesan. Por lo general se usan Rdbms para gestionar este tipo de recursos, ya que presentan mayores garantías de madurez y estabilidad que los Oodbms.

Por otra parte, hay algunos aspectos de sgml-xml que hacen difícil, aunque no imposible, comprimir en tablas un documento típico:

  • Los elementos de texto tienen un tamaño extremadamente variable.
  • Los subelementos se comparten en muchas ocasiones.
  • Frecuentemente existe la necesidad de navegar a través de relaciones jerárquicas.
  • El uso de sgml, y sobre todo de xml (y sus especificaciones), está aumentando espectacularmente en la gestión de aplicaciones multimedia: Smil.

“Almacenar xml en una base de datos orientada a objetos es lo natural” opina Michael Kay, integrador de sistemas del ICL Electronic business systems. “Ambas cosas están diseñadas para manejar datos complejos y tender un puente entre el mundo sin estructura del texto libre y el mundo rígidamente tabular de las bases de datos relacionales”.

Lo que en la actualidad está uniendo a xml con el mundo de la orientación a objetos son las interesantes perspectivas de comercio electrónico que despierta el www. La respuesta lógica a la hora de plantear un sistema de comercio electrónico vía www es xml + Oodbms.

El W3C aprobó la especificación xml 1.0 en febrero del 98, y desde entonces los fabricantes de Oodbms están recibiendo con los brazos abiertos a los desarrolladores xml. Un ejemplo: Object Design Inc. hospeda en sus páginas corporativas un sitio dedicado a recursos xml:

http://www.odi.com

Oracle, IBM e Informix apuestan más bien por sistemas híbridos antes que por la orientación a objetos pura. Como ellos, muchas empresas están anunciando ya la salida al mercado de nuevos productos capaces de gestionar objetos xml. Sin embargo, en la mayoría de los casos sólo hay anuncios. Un ejemplo es la empresa Poet Software Corp. con su producto Content management suite, que utiliza el servidor Poet’s object server 5.0 database que facilita el intercambio entre clientes y aplicaciones de objetos xml.

http://www.poet.com

El problema fundamental es que xml todavía no ha alcanzado su madurez, y existe mucha confusión en cuanto a cómo deben implementarlo las bases de datos. De cualquier forma, una cosa está clara, los Oodbms hasta ahora no han alcanzado todo su potencial porque, en general, se han utilizado para almacenar objetos primitivos como tipos de datos básicos, imágenes, etc. Sin embargo xml está permitiendo desarrollar actualmente tipos de objetos mucho más ricos.

La idea en la que se apoya la programación orientada a objetos es que éstos no sólo contienen datos, sino también metadatos o información sobre la clase a la que pertenecen y cómo deben ser tratados. Xml opera de la misma forma, permitiendo que las aplicaciones intercambien objetos que contienen información y metadatos —DTDs o esquemas en general, como es el caso de SOX—.

Por último, una de las características básicas de xml es que, además de ser legible por las personas es fácilmente procesable para las aplicaciones. Los intentos previos para crear un lenguaje simple para el intercambio de información estructurada fracasaron porque el software que se necesitaba para codificar y decodificar los objetos era demasiado complejo (sgml). Ahora, los Oodbms entendidos como aplicaciones disponen de un lenguaje de intercambio: el xml, relativamente simple y sobre todo funcional.

Sin embargo, hay que admitir que la integración entre Oodbms y xml —o especificaciones SOX, xml-ql— en la actualidad no es una realidad, sino solamente un proyecto lógico.

¿Xml-ql?

¿Necesita este proyecto que se llegue a un acuerdo sobre un modelo de datos xml común para formular consultas a bases de datos? Si se considera a xml capacitado para ser el medio que haga realidad la utopía del www como base de datos distribuida, es necesario conocer cómo se le va a poder interrogar. Todo depende de la forma en que se entienda su esquema o estructura, ya sea tabular (relacional) o arbórea (jerárquica y orientada a objetos).

El antes mencionado SQL es un lenguaje asentado y normalizado que se usa para la recuperación de datos relacionales. Xml presenta la información de una forma diferente pero no opuesta: el modelo de datos es un árbol jerárquico de elementos y atributos. Por eso está aumentando el interés en desarrollar un lenguaje de interrogación que tenga en cuenta las características xml, pero que también sea capaz de proporcionar las mismas funcionalidades que actualmente cubre SQL.

Habría que preguntarse si este lenguaje puede basarse en la propuesta del W3C, el xml-ql.

Un lenguaje de interrogación xml facilitaría la gestión de grandes colecciones de datos y la extracción de información relevante. Además incrementaría en gran medida la precisión de las búsquedas, pues se podrían realizar sobre la estructura jerárquica de los documentos y dispondrían de ciertas facilidades heredadas de las especificaciones XLL (eXtensible linking language, enlaces) y XSL (eXtensible style language, presentación). De hecho, un lenguaje como éste supondría, incluso, una mejora en las actuales tentativas de interrogación a texto completo.

Tecnologías orientadas a objetos en el www

Aparte de los objetos xml presentes en el web
—los relativos a algunas de sus especificaciones como SOX, Smil, Mathml (Mathematical markup language), DOM o los desarrollados a partir de sgml como TEI (Text encoding initiative)— hay una serie de objetos que, ya sean puros o combinados —como es el caso de Java o Corba (Common objects request broker architecture) con xml—, están alcanzando una importancia fundamental en el desarrollo de aplicaciones www.

De una forma u otra, mucho de lo que se encuentra en internet podría ser considerado hasta cierto punto un objeto: desde los mensajes http hasta los documentos html, pasando por los localizadores universales URLs (Uniform resource locator), URIs (Uniform resources identifer) o URNs (Uniform resources name).

Clasificar las tecnologías parcial o totalmente orientadas a objetos presentes en el web no es una tarea fácil, sobre todo por el espectacular desarrollo que han alcanzado en los últimos tiempos.

Se podría empezar mencionando dos tecnologías muy influyentes en el desarrollo de internet. Por un lado, la interfaz que introdujo el concepto de páginas dinámicas, CGI (Common gateway interface), y por otro el lenguaje que hace posibles los objetos tridimensionales en la Red, Vrml (Virtual reality modeling language).

Después habría que pasar a las aplicaciones www orientadas a objetos en el sentido estricto de la palabra “aplicación”. Como ejemplo se podrían nombrar tres productos comerciales: VisualWave de ParcPlace-Digitalk, WebObjects de NeXT y NetDynamics de Spider Technologies. Los tres son entornos de desarrollo que permiten construir herramientas para la Red.

http://www.w3spider.com

http://www.next.com

A continuación habría que comentar los entornos en los que no se requiere interacción con un servidor para implementar algún tipo de comportamiento en el cliente. Aquí se nombrarían JavaScript y su competidor más directo, VBScript de Microsoft. Hay que aclarar que ninguno de los dos es un lenguaje orientado a objetos, puesto que no implementan características básicas de estos sistemas como la herencia o el polimorfismo. Sin embargo, JavaScript proporciona un mecanismo muy simple que permite la creación de estructuras de objetos, propiedades y métodos.

Cómo se implementaría una jerarquía de clases en un sistema sgml-xml orientado a objetos

Después sería obligatorio mencionar el lenguaje orientado a objetos por excelencia del web, Java de Sun Microsystems junto a Hotjava, su navegador. Dentro de este entorno hay que referirse, en primer lugar, a los Java applets. Su importancia reside en que pueden ser cargados y ejecutados localmente en los navegadores que soporten este entorno.

Otras extensiones de la tecnología Java que sería necesario nombrar son: JavaBeans, Java RMI (Remote method invocation), JOE (Java objects everywhere), Java ORBs (Object request broker), OrbixWeb, VisiBroker, LiveConnect y Jdbc, así como su competidor Microsoft ActiveX. También habría que mencionar las tecnologías OLE (Object linking and embedding) y Corba.

Xml y objetos

Xml puede ser considerado como un metalenguaje de naturaleza jerárquica y con una estructura arbórea. Sin embargo también es posible usarlo en un entorno de programación declarativa, el cual, con la adición de Java, se convierte en una especie de lenguaje orientado a objetos muy ligero. Alternativamente, también puede ser visto como una sintaxis de serialización.

Esto significa que una disciplina puede crear sus propios objetos de información usando xml, sus especificaciones, o combinándolo con algunos lenguajes de programación. Esto es lo que ya ha sucedido en disciplinas como las matemáticas (Mathml) o la química (CML, Chemical markup language) y lo que está sucediendo actualmente a una velocidad vertiginosa con el comercio electrónico.

El mundo de las ciencias de la información podría sumarse también a este desarrollo. La pregunta es: ¿para qué deberían utilizarse unos teóricos objetos informativos, bibliográficos, catalográficos, indexatorios, clasificatorios, etc.? Quizá la respuesta sea la relativa consecución, a través del www, de viejas utopías bibliotecarias como la disponibilidad universal de las publicaciones, el intercambio globalizado, formatos universales de catalogación, etc.

DTDs sgml-xml en aplicaciones
orientadas a objetos

La diferencia fundamental entre la orientación a objetos y los lenguajes de etiquetas como sgml o xml —de los cuales fácilmente podría pensarse que se “inclinan” a la orientación a objetos— reside en el concepto de comportamiento.

Una parte importante de la orientación a objetos se basa en la especificación de su comportamiento. Sgml y xml especifican sólo su estructura —entiéndase por objetos el documento y sus elementos—. La diferencia entre sgml y xml se basa en cómo la especifican y sobre todo en para qué, excluyendo intencionadamente el comportamiento de dichos objetos para dar a los desarrolladores la máxima flexibilidad a la hora de utilizar esos datos. Por lo tanto, para transformar un sistema sgml o xml en un modelo orientado a objetos se necesitaría especificar su comportamiento.

La existencia de una buena DTD sgml implica que la mayor parte del análisis y diseño que se requiere para desarrollar estas aplicaciones ya está hecha y almacenada. Se supone que las estructuras de datos han sido definidas en la forma en que un desarrollador las requiere, y sólo hay que especificar el comportamiento de los objetos. En otras palabras, decir lo que los elementos-objeto del documento, y éste como elemento, van a hacer.

Una aplicación sgml orientada a objetos —existen varias de este tipo, la mayoría escritas en Smalltalk— puede automatizar ese proceso de la siguiente forma:

  1. Leyendo la DTD y declarando una clase para cada tipo de elemento. Los atributos de cada clase serán aquellos declarados en la DTD para el elemento correspondiente y cualquier información Pcdata (Parseable character data) alojada en él.
  2. Después de haber declarado todas las clases hay que hacer que los miembros de cada una de ellas aparezcan, cuando menos, una vez. Un programa puede hacer esto leyendo la ocurrencia del elemento documento y creando un nuevo objeto para cada uno que se encuentre alojado en él.

Si una buena DTD omite deliberadamente la especificación del comportamiento de los elementos y, sin embargo, una aplicación orientada a objetos la requiere, ¿qué se debe hacer? Si se analizan los sistemas sgml-xml se descubre una serie de “funciones” que cabría esperarse de los elementos. Por ejemplo:

  • La posibilidad de establecer y leer los atributos de un elemento.
  • Mezclar o reemplazar valores de atributo. Algo muy importante en el desarrollo de sistemas sgml-xml es la capacidad de convertir los datos para aprovechar otras formas de etiquetado, por ejemplo RTF (Rich text format), Tex, esquemas de marcas usados por aplicaciones propietarias o incluso conjuntos de etiquetas definidos por otras DTDs. Es indudable que sería muy útil en un momento dado poder remplazar automáticamente el valor <LI>Granada por {\b 1.} Granada \n.
  • La posibilidad de consultar el estado de un objeto y poder actuar conforme a la respuesta. En una teórica aplicación construida con xml-ql, sería relativamente fácil pedirle a una base de datos que mostrara en pantalla todas las secciones de un documento que contuviera la palabra “prototipo”. Después sería muy útil poder conocer el estado de esas secciones, su conjunto de valores, para decidir la forma de editarlas, etc.

Las anteriores han sido tres funciones que podrían ser implementadas como comportamiento de los elementos a la hora de aproximar un entorno sgml-xml a la orientación a objetos. Pero, ¿qué implica para estos modelos la gestión de datos sgml-xml?

Implementar la primera categoría de métodos sería un asunto relativamente fácil. Para cada uno de los atributos de un objeto dado, se debería definir la manera de establecer los posibles valores de ese atributo y que los devolviera cada vez que fuera requerido para ello. Para enviar los contenidos textuales de un elemento-objeto, ese método debería ser recursivo, puesto que la mayoría de los elementos sgml-xml están formados por múltiples subelementos.

Si se quiere mezclar o reemplazar valores de atributo con el contenido de un objeto, puede recurrirse a la solución que adoptan Perl y C: las cadenas de formato. Si los atributos de un elemento están representados por una serie de símbolos específicos, pueden combinarse en una cadena que presente otros en las posiciones de los valores de atributo que se quieren reemplazar o mezclar. Si <> representa el contenido textual de un elemento y <p> representa el valor de su atributo Name, entonces la cadena {\b <p>}: {\i <>} formatearía la salida del elemento con códigos RTF que indican que el valor p debe ir en negrita, seguido de dos puntos, un espacio y el texto del elemento en cursiva.

Esta cadena pasaría como un parámetro al objeto cuando un mensaje requiriese sus contenidos. El problema es que los elementos sgml-xml en la mayoría de los casos están compuestos por subelementos. Esa es la razón de que sea más lógico almacenar la cadena del ejemplo como una variable, que puede ser referenciada por todos los objetos de una clase para cada tipo de elemento.

En cuanto a la tercera cuestión, en la tabla I se muestran cuatro métodos que pueden implementarse en un elemento sgml-xml con el fin de responder a una consulta sobre su estado.

 

 

Se podría pensar en usar funciones para el ejemplo anterior, pero en realidad también pueden ser métodos. Así, con DocClass no se está indicando a la aplicación que devuelva un valor relativo a un estado, sino que se está ejecutando un método definido como parte de un objeto-elemento, mediante el cual se le pide que retorne un determinado valor de estado.

Por último comentar algunas cuestiones relativas a la herencia. Cuando clases diferentes tienen métodos o atributos en común, sería redundante especificar las mismas para cada nueva clase una y otra vez. Aquí es donde interviene la herencia, permitiendo definir los atributos y comportamiento de una clase y luego los de otra al especificar que “la nueva va a tener los atributos y comportamiento de esta otra pero con estos cambios”. En general esto significa que se define una clase básica con los atributos y comportamiento que todas tienen en común y luego se deriva de ella el resto de las clases.

Objeto sgml-xml

A veces es muy difícil definir qué clases tienen algo en común, qué es lo que tienen y la estructura jerárquica más eficiente para aplicar la herencia. Para un sistema que representa documentos sgml-xml se puede definir una clase básica abstracta como objeto sgml-xml y diseñada exclusivamente para derivar clases de ella. Esto facilita la implementación de métodos heredables, puesto que lo único que hay que hacer es añadírselos a la clase básica, que no tiene ocurrencias reales pues es abstracta.

Eledocsgml-xml y Elesgml-xml. El nodo raíz de la estructura arbórea de un documento Eledocsgml-xml puede tener atributos que no posean sus subelementos Elesgml-xml y viceversa (por ejemplo, un atributo superelemento, padre, etc.). Por eso se derivan del objeto sgml-xml esas dos clases, Eledocsgml-xml y Elesgml-xml, a las que se puede definir con nuevos métodos y atributos que no interfieran entre sí.

Estas dos clases son también abstractas, no van a tener ocurrencias reales sino que van a servir para derivar nuevas clases basadas en las declaraciones DTD. Esto subraya la ventaja fundamental de usar DTDs para crear sistemas orientados a objetos ya que, tratando los diferentes elementos sgml-xml como miembros de diferentes clases, se pueden definir atributos y comportamientos especializados para cada uno de ellos. Además, al hallarse en una estructura jerárquica, pueden heredar de sus superelementos atributos y comportamiento para poder así reutilizar el código.

Pcdata. Esta clase, derivada de Elesgml-xml, no es abstracta sino concreta, por lo que tiene ocurrencias. Éstas conforman la mayor parte de los nodos hojas en la estructura arbórea de un documento.

Xml o SOX

Se ha mencionado varias veces el término esquema (del inglés schema) utilizado como cuasisinónimo de estructura. Alude en concreto al diseño de un sistema de base de datos descrito en el lenguaje formal que soporte el sistema de gestión (Dbms). En los sistemas relacionales, el esquema definiría los registros, sus campos y las relaciones entre ambos.

Ciertos documentos electrónicos pueden ser concebidos como bases de datos dotadas de un diseño arbóreo y jerárquico. Un buen ejemplo es cualquier documento xml. Pues bien, SOX pretende definir su estructura, contenido y semántica.

En este sentido SOX constituye una alternativa a las DTDs xml orientada, sobre todo, al desarrollo de aplicaciones. Lo que aporta a xml es un tipo de dato intrínseco, un mecanismo para su tipificación mediante el cual puede extenderse para que el usuario defina nuevos tipos, un modelo de contenido basado en el concepto de “átomos estructurales”, un sistema de herencia entre elementos, un mecanismo de nombre localizador tipificado (URL, URN, URI, etc.), y la posibilidad de anidar documentación técnica en los documentos.

Las ventajas de SOX son:

  • Facilita el mapeado de estructuras de datos xml. Mapear se utiliza aquí en el sentido de establecer conexiones lógicas entre dos entidades. En general, desde que el usuario especifica un concepto hasta que es traducido a un lenguaje comprensible por el ordenador, tiene que pasar por una serie de niveles intermedios. Cada uno contiene la misma cantidad de información que el superior, pero se encuentra algo más cerca del código máquina. Este proceso de traducción de un nivel a otro se denomina mapeado y podría decirse que el nivel de SOX es ligeramente inferior que el de xml.
  • Expresa directa y explícitamente las abstracciones de dominio y las relaciones comunes.
  • Permite que el documento sea reutilizado tanto a nivel de diseño como de programación.

Esquema SOX

En un documento sgml-xml la DTD define qué elementos pueden anidarse dentro de él. La validación es un proceso que puede hacerse mediante el análisis automático de su DTD. Sin embargo el análisis sólo comprueba la corrección estructural y no la semántica.

“Planeamos presentar lenguajes más potentes que puedan describir no sólo la estructura de un documento, sino su semántica de tal forma que no sólo se pueda automatizar a un nivel superior su validación, sino también el proceso del documento y el razonamiento sobre sus contenidos” Tim Berners-Lee y Dan Connolly.

Estos autores hablan de un sistema que pueda especificar no solamente la estructura de un documento sino también su contenido, su semántica, para poder desarrollar después aplicaciones capaces de analizar este contenido —lo que se corresponde con el término inglés parsing, que es dividir el lenguaje en pequeños componentes analizables lingüísticamente—. Desde un punto de vista informático se trata de dividir el código fuente en pequeños componentes analizables. Los compiladores, por ejemplo, tienen que analizar este código para ser capaces de traducirlo a código objeto. Del mismo modo, cualquier aplicación que procese instrucciones complejas debe ser capaz de analizarlas. El parsing tiene dos facetas: la léxica y la semántica. La primera divide las cadenas de caracteres en componentes llamados tokens basándose en la puntuación y otras claves. El análisis semántico intenta determinar el significado de la cadena de caracteres.

Xml ofrece sus DTDs como medio formal de definición de la sintaxis y estructura de los documentos. La experiencia ha demostrado que las DTDs no funcionan a la hora de definir también su contenido o la semántica. Además existe el problema de que la sintaxis de las DTDs xml es incompatible con la de los documentos xml, lo que incrementa la dificultad de conseguir que aplicaciones heterogéneas puedan interactuar. Por eso se plantea la necesidad de una estructura o esquema sobre el que se puedan validar a un nivel superior los documentos xml.

SOX se propone no sólo como una sintaxis alternativa a las DTDs sgml-xml sino como un lenguaje capaz de estructurar e integrar información heterogénea.

Objetivos de SOX

  1. Las declaraciones construidas deben poder traducirse en etiquetas y relaciones entre ellas que marquen la estructura informativa de un documento y, por lo tanto, su contenido.
  2. Los documentos, comparados con las DTDs xml, deben facilitar el desarrollo de aplicaciones y reducir las dificultades de interacción entre ellas.
  3. Debe permitir que los datos de los documentos SOX puedan mapearse en estructuras de datos de bases de datos relacionales, lenguajes comunes de programación y lenguajes de definición de interfaces como: Java, IDL (Interface definition language), COM, C y C++. El resultado debe darse en forma de código aprovechable.
  4. Autorizar la reutilización del documento tanto para el diseño como para la programación.
  5. SOX debe ser capaz de expresar directa y explícitamente abstracciones de dominio y las relaciones comunes entre ellas como por ejemplo subtipo/supertipo.
  6. Debe soportar la generación de componentes de aplicación común (estructuras de datos de programación) directamente desde documentos SOX.

SOX, más expresivo que las DTDs xml

Elementos base: SOX proporciona cuatro tipos parametrizados. También permite la creación de clases complejas de elementos para describir los patrones de almacenamiento que se adecúen más a las aplicaciones que se quieran construir. Podrían definirse patrones como tuplas, triplas, datos encolumnados, documentos comerciales, asientos bibliográficos, asientos catalográficos, índices, resúmenes, etc.

La parametrización permite reutilizar la misma estructura con un modelo de contenido diferente (átomos estructurales distintos) en otros documentos. La posibilidad de extender los elementos base permite incluir nuevos atributos o especializar en mayor grado los existentes.

Tipos de datos escalares, enumerativos y de formato. Los primeros se derivan del tipo de datos intrínseco, número básico, y especifican la cantidad de dígitos, posiciones decimales, rango de valores mínimos y máximos, máscaras, etc. Los enumerativos pueden derivarse de cualquier dato intrínseco (no sólo del número básico) y especifican una lista de valores válidos. Los tipos de datos de formato pueden derivarse de cualquiera de los intrínsecos y especifican una máscara.

SOX tiene una relación de tipos de datos intrínsecos escalables —binarios, booleanos, caracteres, fecha, número, tiempo— que se usan normalmente en muchos entornos de programación. Los datos definibles por el usuario (extendidos) deben derivarse, si se aplica lo que se ha leído hasta ahora sobre orientación a objetos, partiendo de la especificación de los intrínsecos, de unos parámetros de escalabilidad o de una enumeración de valores posibles y un formato léxico.

Documentación: SOX permite anidar en la estructura de sus documentos la información técnica relativa a su código y siempre a nivel de programación. Los elementos definidos para acompañarla son “intro” y “explain” y, dentro de ellos, elementos html (html-4). De esta forma, cualquier persona que entienda html es capaz de escribir documentación SOX. Además se aplican las directrices del W3C para autores de html [Wai-pageauth] La importancia de la documentación técnica radica en que puede utilizarse para diseñar, implementar o probar nuevas aplicaciones.

http://www.w3.org/WAI/GL/

Simplificación de entidad: en xml algunos caracteres se reservan para usos especiales. Por ejemplo: < identifica el comienzo de una etiqueta de principio o de final. Si se quiere incluir en el contenido del documento debe haber una forma alternativa de representarlos. En xml se usan las entidades para este fin, para referirse a texto repetido o modificado muy a menudo y para hacer valer el contenido de archivos externos.

SOX mantiene un conjunto reducido de las funciones de las entidades xml. Éstas han sido redireccionadas, especializándolas en distintos elementos, introduciendo nuevas características del lenguaje —como la herencia entre elementos o atributos, los tipos de datos, etc.—, lo que anula la necesidad de especificar entidades paramétricas como en xml. Los elementos parameter y paramref pueden usarse para definir y referenciar este tipo de información del mismo modo que se usaba una entidad paramétrica en xml. En general se puede decir que las entidades SOX se dan para facilitar el mapeado desde/hacia las DTDs xml.

Enumeraciones: cualquier atributo o tipo de datos puede contener una lista de valores seleccionables. Xml tiene listas solamente para los atributos “nmtoken”.

Hipertexto: en este sistema se mantienen automáticamente URIs, URLs y URNs. El soporte para anchors html y xml linking se facilita mediante la herencia y especialización de los atributos de hipertexto.

Herencia: en SOX los elementos pueden heredar sus modelos de contenido y definiciones de atributo directamente de otros. Sin embargo, esto no es posible hacerlo con los métodos ya que, al igual que xml o sgml, tampoco especifica un comportamiento para los elementos y deja esta tarea a los desarrolladores de aplicaciones. Un elemento puede heredar también listas de atributos y su especialización permite refinar y restringir sus tipos de datos, listas de valores y aquellos establecidos por defecto. Además, es posible definir un atributo de modo que pueda ser heredado otro equivalente en el elemento padre o ancestro del actual. Por ejemplo, los nombres localizadores o namespaces pueden heredarse de elementos superordenados.

Soporte para nombres localizadores (namespaces): en el siguiente ejemplo se puede ver que el nombre localizador del documento SOX “memo” es un URL, pero en general podría ser cualquier otro tipo de referencia URI, URN, path de un archivo, query, etc., que ubicara al elemento en cuestión.

<schema name=”memo” namespace=“http://www.veosystems.com/schemas/memo.xml”>

Los nombres localizadores están completa y precisamente definidos. Lo que significa que cualquier objeto ubicado a través de él puede ser reutilizado en la construcción de un recurso SOX. En otras palabras, es posible importar a un documento, mediante un nombre localizador reconocible, cualquier elemento, atributo, tipo de datos, enumeración, entidad, nota, parámetro o instrucción de proceso.

Sintaxis y validación xml: un documento SOX es un documento xml válido que depende de una DTD SOX. Esto significa que puede ser procesado por un analizador xml, formateado de acuerdo a una hoja de estilo XSL y gestionado por una aplicación DOM (Document object model) o SAX 1.0 (Simple API for xml).

En la tabla II se ofrece una pequeña lista de analizadores, procesadores, APIs y otras herramientas de desarrollo que son compatibles con el nivel uno de la recomendación DOM.

 

Lo que no incluye SOX

  • Conector &: el software orientado a objetos y las bases de datos relacionales tienden a favorecer colecciones desordenadas en clases o tablas. Además, hay muchas aplicaciones de datos que, a diferencia de las de edición, no necesitan la especificación de la secuencia de los datos. La experiencia con el conector sgml “&” ha demostrado que los parsers —analizadores de modelos de contenido deterministas— tienen dificultades para manejar las combinaciones que necesitan los grandes grupos “and”. Por esta razón no se ha incluido en la primera versión de SOX, aunque se está discutiendo la posibilidad de hacerlo.
  • Puntualizaciones en validación: en xml hay dos categorías de documentos, los denominados bien formados, si obedecen la sintaxis xml —lo que significa que deben cumplir una serie de reglas de producción Ebnf (Extended backus-naur form) en las que se basa la sintaxis xml— y los válidos. Un documento xml bien formado lo es cuando atiende a las restricciones de su DTD.

    Para SOX sería útil la posibilidad de especificar cuándo un elemento está bien formado, y permitir que el procesador lo analice desde esa perspectiva, pudiendo volver después al modo validación cuando el elemento haya sido gestionado. Sin embargo, esto sería incompatible con xml y por lo tanto afectaría a uno de los objetivos de desarrollo de SOX. En consecuencia no se ha desarrollado una especificación extra de contenido bien formado.
  • Enlaces xml (XLink): no se ha incluido ningún soporte para el sistema de enlaces de este tipo porque se juzgó que esta especificación no se encontraba en un óptimo grado de desarrollo.
  • Punteros xml: se consideró la posibilidad de dar soporte a los punteros Xpointer como tipo de datos intrínseco, pero finalmente no se incluyeron, aunque se está estudiando esa posibilidad.

Ejemplo de documento SOX

El que se presenta aquí se ha obtenido del borrador SOX enviado al W3C. Se trata de un memorandum, y desde <schema...> hasta </schema>, el código pertenece al mismo documento pero se interrumpe a lo largo del apartado con los comentarios correspondientes a cada cuestión. La sangría marca la jerarquía de los elementos.

http://www.w3.org/TR/NOTE-SOX/

<schema name=”memorandum” amespace=”http://..../..../memorandum.xml”>

<h1>Tipo de documento memorandum</h1>

Todos los documentos SOX comienzan con el elemento raíz schema, y un encabezamiento donde se le da un título al documento. En este elemento raíz se puede establecer el nombre localizador del documento mediante: URL, URI, URN, path relativo, query, etc.

<h2>Definiciones</h2>

<intro>

<p>...</p>

<ul>

<li>...</li>

<li>...</li>

</ul>

</intro>

Las reglas para incluir documentación técnica asociada a un documento SOX son:

  • Se requiere un elemento <h1> al principio (<h1>tipo de documento memorandum</h1>).
  • En el esquema pueden aparecer elementos <h2> o <h3> como hijos (<h2>definiciones</h2>).
  • Los elementos <intro> aparecen siguiendo un elemento <h2> o <h3>.
  • Pueden aparecer anidados en <intro>: <h4>, <h5>, <h6> y un subconjunto muy amplio de elementos html.
  • Dentro de cualquier elemento que se quiera definir debe aparecer <explain>.
  • Anidado en <explain> puede aparecer un subconjunto de elementos html como <title>, <synopsis>, <help>, etc.

<h3>Tipo de elemento memorandum</h3>

<elementtype name=”memo”>

<explain>

<title>Documento Memorandum</title>

<synopsis>Ejemplo de memorandum simple.</synopsis>

<help>

<p>Agregar párrafos, listas e imágenes</p>

</help>

<p>Seis campos requeridos y un corpus.</p>

</explain>

Aquí se ha definido un tipo de elemento llamado “memo” que es el memorandum ejemplo que se encuentra definido encima y debajo de estas líneas. En la parte de arriba se encuentra el nombre del elemento y la documentación técnica relativa a él, marcada mediante etiquetas html. En la parte de abajo está el modelo de contenido de dicho elemento:

<model>

<sequence>

<element name=”a”/>

<element name=”de”/>

<element name=”cc”/>

<element name=”tema”/>

<element name=”archivo”/>

<element name=”fecha”/>

<element name=”corpus”/>

</sequence>

</model>

</elementtype>

El modelo de contenido del memorandum es una secuencia de siete elementos subordinados. Como se puede ver en el siguiente fragmento, el diseño de la mayoría de ellos sólo contiene simples cadenas de texto (<string/>):

<h3>Campos del memorandum</h3>

<elementtype name=”a”><model><string/></model></elementtype>

<elementtype name=”de”><model><string/></model></elementtype>

<elementtype name=”cc”><model><string/></model></elementtype>

<elementtype name=”tema”><model><string/></model></elementtype>

Pero el contenido especificado para los elementos “archivo” y “fecha” es ligeramente diferente. “Archivo” contiene un atributo “datatype” cuyo valor es “number”, lo que significa que el valor del contenido debe ser numérico. El tipo de datos del atributo “datatype” del elemento “fecha” es “date”, luego el contenido debe ser una fecha. Esto implica que debe corresponder a la definición de tipo de datos relativa a fechas.

<elementtype name=”archivo”>

<model><string datatype=”number”/></model>

</elementtype>

<elementtype name=”fecha”>

<model><string datatype=”date”/></model>

</elementtype>

El corpus del memorandum presenta una estructura más rica, que permite elegir entre párrafos, listas e imágenes, siendo el valor del atributo “occurs” el que especifica su ocurrencia mínima y máxima. Es decir, el número mínimo y máximo de veces que se pueden usar en el documento.

<elementtype name=”corpus”>

<model>

<choice occurs=”1,*”>

<element name=”parrafo”/>

<element name=”lista”/>

<element name=”imagen”/>

</choice>

</model>

</elementtype>

El modelo de contenido de un párrafo es una simple cadena de texto: <string/>.

<elementtype name=”parrafo”>

<model>

<string/>

</model>

</elementtype>

En la definición de este memorandum se especifica que se requiere un mínimo de tres items y un máximo de nueve para constituir una lista.

<elementtype name=”lista”>

<model>

<element name=”item” occurs=”3,9”/>

</model>

</elementtype>

En el siguiente ejemplo se equipara cada caso de ítem con un caso de párrafo ya definido (recuérdese el concepto de herencia).

<elementtype name=”item”>

<instanceof name=”parrafo”/>

</elementtype>

La imagen constituye un elemento vacío, dentro del cual se define un atributo obligatorio: “SRC”. Este atributo deberá ser un URI conforme al formato especificado en los tipos de datos.

<elementtype name=”image”>

<empty/>

<attdef name=”src” datatype=”URI”>

<required/>

</attdef>

</elementtype>

</schema>

Elementos

Los documentos SOX reproducen la declaración de tipo de elemento xml usando los componentes explícitos y sus atributos. Pueden definirse mediante “elementtype”, el atributo obligatorio “name” y un modelo de su contenido. En el ejemplo, este sistema se reduce a una cadena de caracteres simbolizada mediante la etiqueta <string/>.

<elementtype name=”referencia”>

<model>

<string/>

</model>

</elementtype>

El nombre puede ser cualquiera de un elemento xml válido, aunque debe ser único y por lo tanto diferente de los demás nombres de elementos definidos en el documento en cuestión. No definirlo correctamente puede suponer un error fatal que provocaría una parada del programa, es decir, reasignar nombres de elementos o referenciar elementos que no se hayan definido.

En cuanto al modelo de contenido, también es básicamente similar a los de xml, puesto que sirve para definir su estructura y composición. Esta definición se amplía al ser posible especificar el número máximo y mínimo de veces que un subelemento, denominado átomo en SOX, puede ser repetido.

Esto le concede al diseñador del esquema un control más preciso del que ofrece xml con sus indicadores de ocurrencia:

  • Nada, cuando el contenido debe ocurrir exactamente una vez.
  • ”*” puede ocurrir una o más veces.
  • ”?” ocurre exactamente una vez.
  • “+”el contenido lo hace una o más veces.

Es necesario recordar brevemente el modelo de contenido xml. En él se especifica qué puede contener un elemento, en qué orden y cuántas veces. Por ejemplo:

<!element seccion (titulo, resumen?, parraf

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1999/septiembre/xml_orientado_a_objetos.html