Resumen: SOX (Schema for object oriented xml) es una especificacin heredera de xml que
aporta algunas caractersticas de la orientacin a objetos. Trata de aumentar la
interoperabilidad de xml con algunos lenguajes de programacin. El artculo pretende, en
primer lugar, repasar las nociones de la orientacin a objetos y aplicarlas al entorno sgml-xml.
Despus analizar las afinidades y diferencias entre xml y SOX y sealar las posibilidades de este
ltimo. Finalmente, reseando los esfuerzos de Marc, las Aacr2 y algunos tipos de metadatos
para catalogar eficientemente los recursos www, especular sobre si SOX o la orientacin a
objetos podran tener algn papel en este sentido. En concreto se analiza la aplicacin de
algunas nociones como clases, objetos, jerarqua y herencia a la identificacin de los
documentos electrnicos (ya sea por medio de catalogacin tradicional ya mediante metadatos).
Podra, por ejemplo, heredar un captulo determinadas caractersticas de su elemento
contenedor: el documento?
Palabras clave: SOX (Schema for object oriented xml), Xml, Sgml, Orientacin a objetos,
Clases, Objetos, Herencia, Estructuras arbreas de datos, Marc, Aacr.
Abstract: SOX (Schema for object oriented xml) is one of xmls inheritor specifications that
endows xml with object orientation features. Also attempts to increase xmls 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 informacin, 1999,
septiembre, v. 8, n. 9, pp. 4-23.
Para gestionar con eficacia gran nmero de archivos, Unix estableci su famosa jerarqua:
directorios, subdirectorios, archivos..., en la que, generalmente, los archivos con temtica similar
se agrupan juntos en directorios que, a su vez, se sitan prximos a otros relacionados, etc.
Si se dibujara un esquema vertical de esta estructura jerrquica de archivos, subdirectorios y
directorios resultara una especie de rbol. Del mismo modo, si se aplicara el mismo esquema a
la organizacin interna de un documento sgml o xml se obtendra otra ordenacin arbrea. La
nica diferencia con el primero sera que los nodos son captulos, prrafos, etc., en lugar de
archivos o directorios. Sera posible integrar estas dos jerarquas en un solo esquema?
Un documento electrnico puede concebirse como una base de datos con su correspondiente
esquema y diseo interno. Sera factible integrar esa estructura en una mayor? La nica forma
de conseguirlo es utilizar un formato que permita, por un lado, el diseo de estructuras
jerrquicas arbreas y, por otro, el tratamiento de los nodos como objetos. Este formato puede ser
xml junto con las especificaciones que se estn 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.
Muchos de los conceptos subyacentes a la orientacin a objetos existen desde hace ms de treinta
aos y, sin embargo, la tecnologa orientada a objetos es una disciplina relativamente reciente
que ha surgido como respuesta a lo que se llam la crisis del software.
Esta situacin 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 supona que estaban diseados, se quedan obsoletos enseguida, etc.
La tecnologa orientada a objetos se puede encontrar en la bibliografa en ingls con las siglas
OT (Object technology) se concibi como la principal respuesta a ese problema. Al igual que
en cualquier disciplina moderna, la OT todava no tiene una estructura ni una nomenclatura
precisa. Hasta hace poco tiempo se confundan y superponan 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
ms o menos delimitado dentro de la OT.
De acuerdo con este punto de vista, la crisis del software se produjo porque este mapa era muy
difcil de crear con las viejas tcnicas y herramientas de programacin especialmente las
metodologas 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.
Basndose 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 informacin de cualquier tipo. En programacin orientada a objetos se cuenta con datos y
procedimientos (mtodos) para manipular dichos objetos. Teniendo en cuenta esto, objeto sera el
mecanismo bsico 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 bibliogrfico asignado a un sitio web, se
ve que puede englobar muchos campos de datos: nombre del autor, organizacin que lo
mantiene, nmero de enlaces, URL, etc. La informacin en cada uno de esos campos puede
cambiar. Es ms, teniendo en cuenta las caractersticas del www, con toda probabilidad lo har
muchas veces.
En un contexto sgml-xml, el estado sera el conjunto actual de los valores de sus atributos. En el
caso de un objeto compuesto por la combinacin de otros por ejemplo, un documento sgml o
xml compuesto de elementos la definicin anterior incluira los valores de los atributos de los
objetos que lo componen.
Algo muy importante en el desarrollo de una aplicacin 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 estticos no cambian mientras la
aplicacin est en funcionamiento, ya que se asignan cuando se crea el objeto y no suelen sufrir
alteraciones de estado. Por lo tanto la pregunta sera si pueden la automatizacin y la
orientacin a objetos influir en la dinamizacin de los datos sgml o 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 direccin pueden
ser redirigidos automticamente. Una agencia centraliza toda la informacin 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
ms delegaciones a imitacin de las agencias que gestionan el Isbn.
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 captulo en el libro. Este DOI podra asociarse
con una pgina o URL especficos en el directorio:
http://www.doi.org/10.1002/IsbnJ0-471-58064-3
En caso de que los identificadores semnticos (DOI por ejemplo) puedan ser cambiados a lo
largo de la vida del objeto, se asociaran tambin a ste identificadores en el mbito de
implementacin/programacin sin ningn significado.
http://www.doi.org
Booch define comportamiento como la forma en que un objeto acta y reacciona en trminos de
sus cambios de estado y su gestin de los mensajes. Definirlo significa escribir el cdigo para
que cada clase pueda responder a los mensajes enviados a los objetos de esa misma categora.
Una buena DTD (Document type definition) evita deliberadamente la definicin del
comportamiento de un elemento con el fin de dar a los desarrolladores la mxima flexibilidad
posible en el uso de los datos. Por lo tanto, la definicin del comportamiento de los elementos
(sgml, xml o SOX) es el primer paso para integrar esos elementos en sistemas orientados a
objetos y podra llevarse a cabo mediante una aplicacin externa. De este modo, usando la DTD
solamente como referencia, se podra mantener la integridad de los datos.
Clases. Es el patrn a partir del cual los objetos son creados. En otras palabras: un objeto no es
ms 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 categoras de objetos. Por
ejemplo, la clase forma podra contener los objetos: crculos, rectngulos, tringulos, etc. La
funcin de forma sera definir las propiedades comunes de crculos, rectngulos, tringulos, etc.
El uso que el entorno sgml-xml puede hacer de los conceptos clase y objeto es ms 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 desempean el papel de objetos. En
la seccin 4.102 de la norma ISO 8879 (sgml) se define tipo de documento como una clase que
posee caractersticas similares; por ejemplo peridicos, artculos, manuales tcnicos o
memorandum. Los tipos de elementos son definidos de forma similar, lo que unido al uso de los
atributos sgml-xml para identificar esas caractersticas 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 bibliogrfico para recursos web, se
debera definir una serie de elementos, atributos y relaciones. Para establecerlos se podran
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 podra hacer es: las clases definen tipos que se usan para especificar
variables, prototipos de funcin, etc. y asociarles informacin. As, en el registro bibliogrfico
citado, se hara la siguiente declaracin del tipo int: int t, tp, tc, seguida de la asociacin de
informacin a las variables:
tc= t+tp
Esto podra usarse, a efectos de programacin, para gestionar los registros de recursos www. Por
ejemplo:
tc= [245 00] Electronic journal of communication h [computer file]+[246 31] b Revista
electrnica de comunicacin.
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 caracterstica de un elemento
distinta de tipo o contenido. Sgml reconoce dos niveles de atributos: primarios y
secundarios.
Los primarios son los identificadores genricos. Atributos nicos para cada tipo declarado de
elemento. Los atributos adicionales que caracterizan a un elemento son considerados
secundarios.
Una aplicacin orientada a objetos construida sobre datos sgml o xml usara los identificadores
genricos para descubrir a qu clase pertenece el elemento-objeto en cuestin, y los atributos
secundarios como conjuntos de valores asociados a la ocurrencia actual del elemento-objeto.
Mtodos y mensajes. Es una determinada accin que se ejecuta cuando un objeto recibe un
mensaje. El concepto mtodo es muy similar al de procedimiento, funcin o rutina de los
lenguajes de programacin procedurales los tres se refieren a una seccin del programa que
cumple una tarea especfica. La nica diferencia es que en la programacin orientada a objetos
un mtodo siempre se asocia a una clase.
Cada una de ellas posee un conjunto de mtodos 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
mtodos mediante mensajes mandados al objeto en cuestin.
Herencia. Es el mecanismo por el cual una clase (subclase) se deriva de otra (superclase),
proceso que implica dos cuestiones:
b. Si la clase B se deriva de la clase A, cualquier objeto del tipo B pertenece tambin a la clase A.
Por estas dos razones la herencia sirve para reducir considerablemente la complejidad de un
sistema, ya que la inmensa mayora del cdigo puede relacionarse con las abstracciones de las
races de la jerarqua en lugar de hacerlo con las de cada una de las clases y subclases del
sistema.
ltimamente las bases de datos multimedia han empezado a enfrentarse a dos de los problemas
ms importantes que se les presentaban a los desarrolladores de recursos web: controlar la
proliferacin de informacin digital y generar pginas complejas e interactivas. En este sentido
hay cuatro tipos de bases de datos compitiendo por la atencin de los webmasters y los
productores multimedia:
Los tradicionales modelos relacionales (Rdbms) de Oracle, IBM, etc.
Los hbridos o bases de datos relacionales orientadas a objetos (Oordbms), como Illustra.
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 imgenes, vdeo,
sonido o datos espaciales, ya que no fueron diseados 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 alfanumrico es un
Blob, una masa confusa de bytes impermeable a la bsqueda, indexacin o comparacin, y
esencialmente relegada a la categora de informacin no procesada. La base de datos no la
gestiona y deja este proceso para las aplicaciones cliente especficas.
Las bases de datos relacionales distribuyen vnculos 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 informacin sobre las relaciones de
sus componentes junto a los datos.
Modelo de datos: es una representacin lgica de los datos, sus relaciones y sus
restricciones.
Modelo de objetos: combinacin del modelo de datos con otro de comportamiento de los
objetos basado en principios de la orientacin a objetos.
Dado que los Oodbms deben admitir la gestin de los datos por una parte y, por otra,
proporcionar un completo soporte para la orientacin a objetos, necesariamente son productos
complejos. Por ejemplo, el modelo de objetos no solamente define los datos sino tambin su
comportamiento. As pues, un Oodbms debe ofrecer mecanismos que permitan gestionar el
comportamiento de los objetos en la base de datos, incluyendo mdulos que gestionen la
evolucin del esquema, etc. Otro punto difcil es la generacin de ndices. Este sistema depende
en gran medida del uso de la herencia, lo que obliga a que se definan clases o jerarquas.
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 adicin de una
caracterstica: la persistencia. Es lo que permite que los objetos existan despus de que la
aplicacin que los procesa se haya detenido, de esa forma estn a disposicin del usuario cuando
se activa de nuevo.
sta es una caracterstica 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 estn ejecutando o no las aplicaciones que los procesan. Por lo
general se usan Rdbms para gestionar este tipo de recursos, ya que presentan mayores garantas
de madurez y estabilidad que los Oodbms.
Por otra parte, hay algunos aspectos de sgml-xml que hacen difcil, aunque no imposible,
comprimir en tablas un documento tpico:
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 estn diseadas para
manejar datos complejos y tender un puente entre el mundo sin estructura del texto libre y el
mundo rgidamente tabular de las bases de datos relacionales.
Lo que en la actualidad est uniendo a xml con el mundo de la orientacin a objetos son las
interesantes perspectivas de comercio electrnico que despierta el www. La respuesta lgica a la
hora de plantear un sistema de comercio electrnico va www es xml + Oodbms.
El W3C aprob la especificacin xml 1.0 en febrero del 98, y desde entonces los fabricantes de
Oodbms estn recibiendo con los brazos abiertos a los desarrolladores xml. Un ejemplo: Object
Design Inc. hospeda en sus pginas corporativas un sitio dedicado a recursos xml:
http://www.odi.com
Oracle, IBM e Informix apuestan ms bien por sistemas hbridos antes que por la orientacin a
objetos pura. Como ellos, muchas empresas estn anunciando ya la salida al mercado de nuevos
productos capaces de gestionar objetos xml. Sin embargo, en la mayora de los casos slo hay
anuncios. Un ejemplo es la empresa Poet Software Corp. con su producto Content management
suite, que utiliza el servidor Poets object server 5.0 database que facilita el intercambio entre
clientes y aplicaciones de objetos xml.
http://www.poet.com
La idea en la que se apoya la programacin orientada a objetos es que stos no slo contienen
datos, sino tambin metadatos o informacin sobre la clase a la que pertenecen y cmo deben ser
tratados. Xml opera de la misma forma, permitiendo que las aplicaciones intercambien objetos
que contienen informacin y metadatos DTDs o esquemas en general, como es el caso de SOX
.
Por ltimo, una de las caractersticas bsicas de xml es que, adems de ser legible por las
personas es fcilmente procesable para las aplicaciones. Los intentos previos para crear un
lenguaje simple para el intercambio de informacin 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 integracin entre Oodbms y xml o especificaciones SOX,
xml-ql en la actualidad no es una realidad, sino solamente un proyecto lgico.
Xml-ql?
Necesita este proyecto que se llegue a un acuerdo sobre un modelo de datos xml comn para
formular consultas a bases de datos? Si se considera a xml capacitado para ser el medio que haga
realidad la utopa del www como base de datos distribuida, es necesario conocer cmo se le va a
poder interrogar. Todo depende de la forma en que se entienda su esquema o estructura, ya sea
tabular (relacional) o arbrea (jerrquica y orientada a objetos).
El antes mencionado SQL es un lenguaje asentado y normalizado que se usa para la recuperacin
de datos relacionales. Xml presenta la informacin de una forma diferente pero no opuesta: el
modelo de datos es un rbol jerrquico de elementos y atributos. Por eso est aumentando el
inters en desarrollar un lenguaje de interrogacin que tenga en cuenta las caractersticas xml,
pero que tambin sea capaz de proporcionar las mismas funcionalidades que actualmente cubre
SQL.
Habra que preguntarse si este lenguaje puede basarse en la propuesta del W3C, el xml-ql.
De una forma u otra, mucho de lo que se encuentra en internet podra 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 tecnologas parcial o totalmente orientadas a objetos presentes en el web no es una
tarea fcil, sobre todo por el espectacular desarrollo que han alcanzado en los ltimos tiempos.
Despus habra que pasar a las aplicaciones www orientadas a objetos en el sentido estricto de la
palabra aplicacin. Como ejemplo se podran 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 continuacin habra que comentar los entornos en los que no se requiere interaccin con un
servidor para implementar algn tipo de comportamiento en el cliente. Aqu se nombraran
JavaScript y su competidor ms directo, VBScript de Microsoft. Hay que aclarar que ninguno de
los dos es un lenguaje orientado a objetos, puesto que no implementan caractersticas bsicas de
estos sistemas como la herencia o el polimorfismo. Sin embargo, JavaScript proporciona un
mecanismo muy simple que permite la creacin de estructuras de objetos, propiedades y
mtodos.
Despus sera 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 tecnologa Java que sera 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.
Tambin habra que mencionar las tecnologas OLE (Object linking and embedding) y Corba.
Xml y objetos
Xml puede ser considerado como un metalenguaje de naturaleza jerrquica y con una estructura
arbrea. Sin embargo tambin es posible usarlo en un entorno de programacin declarativa, el
cual, con la adicin de Java, se convierte en una especie de lenguaje orientado a objetos muy
ligero. Alternativamente, tambin puede ser visto como una sintaxis de serializacin.
Esto significa que una disciplina puede crear sus propios objetos de informacin usando xml, sus
especificaciones, o combinndolo con algunos lenguajes de programacin. Esto es lo que ya ha
sucedido en disciplinas como las matemticas (Mathml) o la qumica (CML, Chemical markup
language) y lo que est sucediendo actualmente a una velocidad vertiginosa con el comercio
electrnico.
La diferencia fundamental entre la orientacin a objetos y los lenguajes de etiquetas como sgml o
xml de los cuales fcilmente podra pensarse que se inclinan a la orientacin a objetos
reside en el concepto de comportamiento.
La existencia de una buena DTD sgml implica que la mayor parte del anlisis y diseo 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 slo
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 aplicacin sgml orientada a objetos existen varias de este tipo, la mayora 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 sern aquellos declarados en la DTD para el elemento correspondiente y
cualquier informacin Pcdata (Parseable character data) alojada en l.
2. Despus 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 especificacin del comportamiento de los elementos
y, sin embargo, una aplicacin orientada a objetos la requiere, qu se debe hacer? Si se analizan
los sistemas sgml-xml se descubre una serie de funciones que cabra esperarse de los
elementos. Por ejemplo:
Las anteriores han sido tres funciones que podran ser implementadas como comportamiento de
los elementos a la hora de aproximar un entorno sgml-xml a la orientacin a objetos. Pero, qu
implica para estos modelos la gestin de datos sgml-xml?
Implementar la primera categora de mtodos sera un asunto relativamente fcil. Para cada uno
de los atributos de un objeto dado, se debera 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 mtodo debera ser recursivo, puesto que la
mayora de los elementos sgml-xml estn formados por mltiples subelementos.
Esta cadena pasara como un parmetro al objeto cuando un mensaje requiriese sus contenidos.
El problema es que los elementos sgml-xml en la mayora de los casos estn compuestos por
subelementos. Esa es la razn de que sea ms lgico almacenar la cadena del ejemplo como una
variable, que puede ser referenciada por todos los objetos de una clase para cada tipo de
elemento.
Se podra pensar en usar funciones para el ejemplo anterior, pero en realidad tambin pueden ser
mtodos. As, con DocClass no se est indicando a la aplicacin que devuelva un valor relativo a
un estado, sino que se est ejecutando un mtodo 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
mtodos o atributos en comn, sera 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 bsica con los atributos y comportamiento que todas tienen en comn y luego se
deriva de ella el resto de las clases.
Objeto sgml-xml
A veces es muy difcil definir qu clases tienen algo en comn, qu es lo que tienen y la
estructura jerrquica ms eficiente para aplicar la herencia. Para un sistema que representa
documentos sgml-xml se puede definir una clase bsica abstracta como objeto sgml-xml y
diseada exclusivamente para derivar clases de ella. Esto facilita la implementacin de mtodos
heredables, puesto que lo nico que hay que hacer es aadrselos a la clase bsica, que no tiene
ocurrencias reales pues es abstracta.
Estas dos clases son tambin 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. Adems, al hallarse en una estructura
jerrquica, pueden heredar de sus superelementos atributos y comportamiento para poder as
reutilizar el cdigo.
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 arbrea de un
documento.
Xml o SOX
Se ha mencionado varias veces el trmino esquema (del ingls schema) utilizado como
cuasisinnimo de estructura. Alude en concreto al diseo de un sistema de base de datos descrito
en el lenguaje formal que soporte el sistema de gestin (Dbms). En los sistemas relacionales, el
esquema definira los registros, sus campos y las relaciones entre ambos.
Ciertos documentos electrnicos pueden ser concebidos como bases de datos dotadas de un
diseo arbreo y jerrquico. Un buen ejemplo es cualquier documento xml. Pues bien, SOX
pretende definir su estructura, contenido y semntica.
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 intrnseco, un mecanismo para
su tipificacin 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 documentacin tcnica en los documentos.
Permite que el documento sea reutilizado tanto a nivel de diseo como de programacin.
Esquema SOX
Xml ofrece sus DTDs como medio formal de definicin de la sintaxis y estructura de los
documentos. La experiencia ha demostrado que las DTDs no funcionan a la hora de definir
tambin su contenido o la semntica. Adems 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 heterogneas 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 slo como una sintaxis alternativa a las DTDs sgml-xml sino como un
lenguaje capaz de estructurar e integrar informacin heterognea.
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 interaccin 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 programacin y lenguajes de
definicin de interfaces como: Java, IDL (Interface definition language), COM, C y C+
+. El resultado debe darse en forma de cdigo aprovechable.
4. Autorizar la reutilizacin del documento tanto para el diseo como para la programacin.
5. SOX debe ser capaz de expresar directa y explcitamente abstracciones de dominio y las
relaciones comunes entre ellas como por ejemplo subtipo/supertipo.
Elementos base: SOX proporciona cuatro tipos parametrizados. Tambin permite la creacin de
clases complejas de elementos para describir los patrones de almacenamiento que se adecen
ms a las aplicaciones que se quieran construir. Podran definirse patrones como tuplas, triplas,
datos encolumnados, documentos comerciales, asientos bibliogrficos, asientos catalogrficos,
ndices, resmenes, etc.
Tipos de datos escalares, enumerativos y de formato. Los primeros se derivan del tipo de datos
intrnseco, nmero bsico, y especifican la cantidad de dgitos, posiciones decimales, rango de
valores mnimos y mximos, mscaras, etc. Los enumerativos pueden derivarse de cualquier dato
intrnseco (no slo del nmero bsico) y especifican una lista de valores vlidos. Los tipos de
datos de formato pueden derivarse de cualquiera de los intrnsecos y especifican una mscara.
SOX tiene una relacin de tipos de datos intrnsecos escalables binarios, booleanos, caracteres,
fecha, nmero, tiempo que se usan normalmente en muchos entornos de programacin. Los
datos definibles por el usuario (extendidos) deben derivarse, si se aplica lo que se ha ledo hasta
ahora sobre orientacin a objetos, partiendo de la especificacin de los intrnsecos, de unos
parmetros de escalabilidad o de una enumeracin de valores posibles y un formato lxico.
http://www.w3.org/WAI/GL/
Simplificacin 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, especializndolas en distintos elementos, introduciendo nuevas caractersticas
del lenguaje como la herencia entre elementos o atributos, los tipos de datos, etc., lo que
anula la necesidad de especificar entidades paramtricas como en xml. Los elementos parameter
y paramref pueden usarse para definir y referenciar este tipo de informacin del mismo modo
que se usaba una entidad paramtrica 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 automticamente URIs, URLs y URNs. El soporte para
anchors html y xml linking se facilita mediante la herencia y especializacin 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 mtodos 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 tambin listas de
atributos y su especializacin permite refinar y restringir sus tipos de datos, listas de valores y
aquellos establecidos por defecto. Adems, 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 podra ser
cualquier otro tipo de referencia URI, URN, path de un archivo, query, etc., que ubicara al
elemento en cuestin.
Los nombres localizadores estn completa y precisamente definidos. Lo que significa que
cualquier objeto ubicado a travs de l puede ser reutilizado en la construccin de un recurso
SOX. En otras palabras, es posible importar a un documento, mediante un nombre localizador
reconocible, cualquier elemento, atributo, tipo de datos, enumeracin, entidad, nota, parmetro o
instruccin de proceso.
Sintaxis y validacin xml: un documento SOX es un documento xml vlido 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 aplicacin DOM (Document object model) o SAX
1.0 (Simple API for xml).
Conector &: el software orientado a objetos y las bases de datos relacionales tienden a
favorecer colecciones desordenadas en clases o tablas. Adems, hay muchas aplicaciones
de datos que, a diferencia de las de edicin, no necesitan la especificacin 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 razn no se ha
incluido en la primera versin de SOX, aunque se est discutiendo la posibilidad de
hacerlo.
Para SOX sera til la posibilidad de especificar cundo un elemento est bien formado, y
permitir que el procesador lo analice desde esa perspectiva, pudiendo volver despus al
modo validacin cuando el elemento haya sido gestionado. Sin embargo, esto sera
incompatible con xml y por lo tanto afectara a uno de los objetivos de desarrollo de
SOX. En consecuencia no se ha desarrollado una especificacin extra de contenido bien
formado.
Enlaces xml (XLink): no se ha incluido ningn soporte para el sistema de enlaces de este
tipo porque se juzg que esta especificacin 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 intrnseco, pero finalmente no se incluyeron, aunque se est estudiando esa
posibilidad.
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 cdigo pertenece al mismo documento
pero se interrumpe a lo largo del apartado con los comentarios correspondientes a cada cuestin.
La sangra marca la jerarqua de los elementos.
http://www.w3.org/TR/NOTE-SOX/
Todos los documentos SOX comienzan con el elemento raz schema, y un encabezamiento donde
se le da un ttulo al documento. En este elemento raz 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 documentacin tcnica asociada a un documento SOX son:
Pueden aparecer anidados en <intro>: <h4>, <h5>, <h6> y un subconjunto muy amplio
de elementos html.
<elementtype name=memo>
<explain>
<title>Documento Memorandum</title>
<help>
</help>
</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 lneas. En la parte de arriba se encuentra el nombre
del elemento y la documentacin tcnica 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>
<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 numrico. 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 definicin
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 ms rica, que permite elegir entre prrafos,
listas e imgenes, siendo el valor del atributo occurs el que especifica su ocurrencia mnima y
mxima. Es decir, el nmero mnimo y mximo 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>
<elementtype name=parrafo>
<model>
<string/>
</model>
</elementtype>
<elementtype name=lista>
<model>
</model>
</elementtype>
En el siguiente ejemplo se equipara cada caso de tem con un caso de prrafo ya definido
(recurdese el concepto de herencia).
<elementtype name=item>
<instanceof name=parrafo/>
</elementtype>
La imagen constituye un elemento vaco, 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/>
<required/>
</attdef>
</elementtype>
</schema>
Elementos
Los documentos SOX reproducen la declaracin de tipo de elemento xml usando los
componentes explcitos 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 vlido, aunque debe ser nico y por lo tanto
diferente de los dems nombres de elementos definidos en el documento en cuestin. No
definirlo correctamente puede suponer un error fatal que provocara una parada del programa, es
decir, reasignar nombres de elementos o referenciar elementos que no se hayan definido.
En cuanto al modelo de contenido, tambin es bsicamente similar a los de xml, puesto que sirve
para definir su estructura y composicin. Esta definicin se ampla al ser posible especificar el
nmero mximo y mnimo de veces que un subelemento, denominado tomo en SOX, puede ser
repetido.
Esto le concede al diseador del esquema un control ms preciso del que ofrece xml con sus
indicadores de ocurrencia:
En la tabla siguiente se enumeran los tipos de datos primitivos de los esquemas XML, los
aspectos que se pueden aplicar a los tipos de datos y la descripcin del tipo de datos. Para
obtener descripciones de las facetas, consulte Aspectos de tipo de datos.
Las facetas solo pueden aparecer una vez en una definicin de tipo, excepto en enumeration y
pattern. Las facetas Enumeration y pattern pueden tener varias entradas y estn agrupadas juntas.
Tipo de
Facets Descripcin
datos
length, pattern,
maxLength, minLength,
string Representa cadenas de caracteres.
enumeration,
whiteSpace
boolean pattern, whiteSpace Representa valores booleanos, que son true o false.
enumeration, pattern,
totalDigits,
fractionDigits,
decimal minInclusive, Representa nmeros de precisin arbitraria.
maxInclusive,
maxExclusive,
whiteSpace
pattern, enumeration,
minInclusive,
minExclusive, Representa nmeros de punto flotante de 32 bits de
float
maxInclusive, precisin simple.
maxExclusive,
whiteSpace
pattern, enumeration,
minInclusive,
minExclusive, Representa nmeros de punto flotante de 64 bits de
double
maxInclusive, doble precisin.
maxExclusive,
whiteSpace
enumeration, pattern,
Representa una instancia de tiempo que se repite cada
minInclusive,
da.
minExclusive,
time
maxInclusive,
El patrn de time es hh:mm:ss.sss con un indicador
maxExclusive,
opcional de zona horaria.
whiteSpace
enumeration, pattern,
minInclusive, Representa una fecha de calendario.
minExclusive,
date
maxInclusive, El patrn de date es CCYY-MM-DD con un indicador
maxExclusive, opcional de zona horaria como el de dateTime.
whiteSpace
enumeration, pattern,
Representa un ao gregoriano. Conjunto de instancias no
minInclusive,
peridicas de un ao de duracin.
minExclusive,
gYear
maxInclusive,
El patrn de gYear es CCYY con un indicador opcional
maxExclusive,
de zona horaria como el de dateTime.
whiteSpace
length, pattern,
Representa datos binarios arbitrarios codificados en
maxLength, minLength,
base64Binary Base64. base64Binary es el conjunto de secuencias de
enumeration,
longitud finita de octetos binarios.
whiteSpace
length, pattern,
Representa un URI tal como se define en RFC 2396. Un
maxLength, minLength,
anyURI valor anyURI puede ser absoluto o relativo, y puede
enumeration,
tener un identificador de fragmento opcional.
whiteSpace
length, enumeration,
Representa un tipo de atributo NOTATION. Conjunto de
NOTATION pattern, maxLength,
QNames.
minLength, whiteSpace