Xml orientado a objetos

Por Antonio de la Rosa

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.

Title: Object-oriented XML

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.

Objetos. Estructuras de objetos. Objetos en el www

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.

La causa se encuentra en que anteriormente, con los medios de programacin tradicionales, la

gestin de un gran sistema software era ms difcil que mantener otros tipos de estructuras
complejas como puentes o aviones.

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.

La programacin 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
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.

La identidad es un identificador inmutable (generalmente asociado al objeto en el momento de su

creacin) que lo caracteriza a todos los efectos. Si se considera como ejemplo de objeto el
registro bibliogrfico online de un recurso www se podra, eventualmente, utilizar como
identificador un DOI (Digital object identifier).

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.

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 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

Aqu www.doi.org es el directorio central. Su funcin es responder a la anterior peticin,

localizando la URL asociada al DOI en cuestin y envirsela de vuelta al usuario.

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

El comportamiento de un objeto es el conjunto de operaciones a las que puede ser sometido.

Siguiendo con el ejemplo anterior de asiento bibliogrfico, ste podra ser presentado en pantalla.
El comportamiento acta 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 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:

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

tp= ttulo paralelo [Marc 245 (NR) b, 246 (R)]

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:

a. La estructura de la superclase es heredada por la subclase. Los atributos y mtodos de la

primera tambin se hallan disponibles en la segunda, lo que permite que el cdigo se reutilice.

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.

Bases de datos multimedia en el www

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.

Las orientadas a objetos (Oodbms).

Los hbridos o bases de datos relacionales orientadas a objetos (Oordbms), como Illustra.

Un nmero creciente de bases de datos desarrolladas especficamente, 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 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.

Actualmente, cuando las grandes compaas estn almacenando y publicando masivamente

informacin 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 autntica 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 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.

Es necesario puntualizar algunos trminos:

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.

Oodb (Object oriented database): coleccin de objetos persistentes definida por un

modelo de objetos.

Lenguaje DB: una sintaxis para representar y manipular esa coleccin.

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:

Los elementos de texto tienen un tamao extremadamente variable.

Los subelementos se comparten en muchas ocasiones.

Frecuentemente existe la necesidad de navegar a travs de relaciones jerrquicas.

El uso de sgml, y sobre todo de xml (y sus especificaciones), est aumentando

espectacularmente en la gestin 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 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

El problema fundamental es que xml todava no ha alcanzado su madurez, y existe mucha

confusin en cuanto a cmo 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 bsicos, imgenes, etc.
Sin embargo xml est permitiendo desarrollar actualmente tipos de objetos mucho ms ricos.

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.

Un lenguaje de interrogacin xml facilitara la gestin de grandes colecciones de datos y la

extraccin de informacin relevante. Adems incrementara en gran medida la precisin de las
bsquedas, pues se podran realizar sobre la estructura jerrquica de los documentos y
dispondran de ciertas facilidades heredadas de las especificaciones XLL (eXtensible linking
language, enlaces) y XSL (eXtensible style language, presentacin). De hecho, un lenguaje como
ste supondra, incluso, una mejora en las actuales tentativas de interrogacin a texto completo.

Tecnologas 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, estn alcanzando una importancia
fundamental en el desarrollo de aplicaciones www.

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.

Se podra empezar mencionando dos tecnologas muy influyentes en el desarrollo de internet.

Por un lado, la interfaz que introdujo el concepto de pginas dinmicas, CGI (Common gateway
interface), y por otro el lenguaje que hace posibles los objetos tridimensionales en la Red, Vrml
(Virtual reality modeling language).

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.

El mundo de las ciencias de la informacin podra sumarse tambin a este desarrollo. La

pregunta es: para qu deberan utilizarse unos tericos objetos informativos, bibliogrficos,
catalogrficos, indexatorios, clasificatorios, etc.? Quiz la respuesta sea la relativa consecucin, a
travs del www, de viejas utopas bibliotecarias como la disponibilidad universal de las
publicaciones, el intercambio globalizado, formatos universales de catalogacin, etc.

DTDs sgml-xml en aplicaciones

orientadas a objetos

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.

Una parte importante de la orientacin a objetos se basa en la especificacin de su

comportamiento. Sgml y xml especifican slo su estructura entindase por objetos el
documento y sus elementos. La diferencia entre sgml y xml se basa en cmo la especifican y
sobre todo en para qu, excluyendo intencionadamente el comportamiento de dichos objetos
para dar a los desarrolladores la mxima 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 necesitara
especificar su 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:

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 sera muy til en un momento dado poder remplazar automticamente 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 terica aplicacin construida con xml-ql, sera relativamente fcil pedirle a una
base de datos que mostrara en pantalla todas las secciones de un documento que
contuviera la palabra prototipo. Despus sera 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 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.

Si se quiere mezclar o reemplazar valores de atributo con el contenido de un objeto, puede

recurrirse a la solucin que adoptan Perl y C: las cadenas de formato. Si los atributos de un
elemento estn representados por una serie de smbolos especficos, 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 <>} formateara la salida del elemento con
cdigos 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 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.

En cuanto a la tercera cuestin, en la tabla I se muestran cuatro mtodos que pueden

implementarse en un elemento sgml-xml con el fin de responder a una consulta sobre su estado.

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.

Eledocsgml-xml y Elesgml-xml. El nodo raz de la estructura arbrea 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 mtodos y
atributos que no interfieran entre s.

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.

Las ventajas de SOX son:

Facilita el mapeado de estructuras de datos xml. Mapear se utiliza aqu en el sentido de

establecer conexiones lgicas 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 informacin que el superior, pero se encuentra algo ms cerca del
cdigo mquina. Este proceso de traduccin de un nivel a otro se denomina mapeado y
podra decirse que el nivel de SOX es ligeramente inferior que el de xml.

Expresa directa y explcitamente las abstracciones de dominio y las relaciones comunes.

Permite que el documento sea reutilizado tanto a nivel de diseo como de programacin.

Esquema SOX

En un documento sgml-xml la DTD define qu elementos pueden anidarse dentro de l. La

validacin es un proceso que puede hacerse mediante el anlisis automtico de su DTD. Sin
embargo el anlisis slo comprueba la correccin estructural y no la semntica.

Planeamos presentar lenguajes ms potentes que puedan describir no slo la estructura de un

documento, sino su semntica de tal forma que no slo se pueda automatizar a un nivel superior
su validacin, sino tambin 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 tambin su contenido, su semntica, para poder desarrollar despus aplicaciones
capaces de analizar este contenido lo que se corresponde con el trmino ingls parsing, que es
dividir el lenguaje en pequeos componentes analizables lingsticamente. Desde un punto de
vista informtico se trata de dividir el cdigo fuente en pequeos componentes analizables. Los
compiladores, por ejemplo, tienen que analizar este cdigo para ser capaces de traducirlo a
cdigo objeto. Del mismo modo, cualquier aplicacin que procese instrucciones complejas debe
ser capaz de analizarlas. El parsing tiene dos facetas: la lxica y la semntica. La primera divide
las cadenas de caracteres en componentes llamados tokens basndose en la puntuacin y otras
claves. El anlisis semntico intenta determinar el significado de la cadena de caracteres.

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.

6. Debe soportar la generacin de componentes de aplicacin comn (estructuras de datos

de programacin) directamente desde documentos SOX.

SOX, ms expresivo que las DTDs xml

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.

La parametrizacin 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
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.

Documentacin: SOX permite anidar en la estructura de sus documentos la informacin tcnica

relativa a su cdigo y siempre a nivel de programacin. Los elementos definidos para
acompaarla son intro y explain y, dentro de ellos, elementos html (html-4). De esta forma,
cualquier persona que entienda html es capaz de escribir documentacin SOX. Adems se aplican
las directrices del W3C para autores de html [Wai-pageauth] La importancia de la documentacin
tcnica radica en que puede utilizarse para disear, implementar o probar nuevas aplicaciones.

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.

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

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).

En la tabla II se ofrece una pequea lista de analizadores, procesadores, APIs y otras

herramientas de desarrollo que son compatibles con el nivel uno de la recomendacin 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. 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.

Puntualizaciones en validacin: en xml hay dos categoras de documentos, los

denominados bien formados, si obedecen la sintaxis xml lo que significa que deben
cumplir una serie de reglas de produccin Ebnf (Extended backus-naur form) en las que
se basa la sintaxis xml y los vlidos. Un documento xml bien formado lo es cuando
atiende a las restricciones de su DTD.

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.

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 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/

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

<h1>Tipo de documento memorandum</h1>

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:

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 prrafos, listas e imgenes</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 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>

El modelo de contenido del memorandum es una secuencia de siete elementos subordinados.

Como se puede ver en el siguiente fragmento, el diseo de la mayora de ellos slo 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 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>

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

<elementtype name=parrafo>

<model>

<string/>

</model>

</elementtype>

En la definicin de este memorandum se especifica que se requiere un mnimo de tres items y un

mximo 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 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/>

<attdef name=src datatype=URI>

<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:

Nada, cuando el contenido debe ocurrir exactamente una vez.

* puede ocurrir una o ms veces.

? ocurre exactamente una vez.

+el contenido lo hace una o ms veces.

Es necesario recordar brevemente el modelo de contenido xml. En l se especifica qu puede

contener un elemento, en qu orden y cuntas veces. Por ejemplo:

<!element seccion (titulo, resumen?, parraf

Enlace del artculo:

Tipos de datos XML primitivos

Otras versiones

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

duration enumeration, pattern, Representa una duracin de tiempo.

minInclusive,
minExclusive, El patrn de duration es PnYnMnDTnHnMnS, donde
maxInclusive, nY representa el nmero de aos, nM el nmero de
maxExclusive, meses, nD el nmero de das, T el separador de fecha y
whiteSpace hora, nH el nmero de horas, nM el nmero de minutos
 y nS el nmero de segundos.

Representa una instancia especfica de tiempo.

El patrn de dateTime es CCYY-MM-DDThh:mm:ss

donde CC representa el siglo, YY el ao, MM el mes y
DD el da, precedido por un carcter negativo (-) inicial
opcional para indicar un nmero negativo. Si se omite el
carcter negativo, se supone positivo (+). La T es el
separador de fecha y hora, y hh, mm y ss representan la
hora, minutos y segundos, respectivamente. Se pueden
enumeration, pattern,
utilizar dgitos adicionales para aumentar la precisin de
minInclusive,
los segundos decimales, si se desea. Por ejemplo, se
minExclusive,
dateTime admite el formato ss.ss... con cualquier nmero de
maxInclusive,
dgitos despus del separador decimal. Es opcional la
maxExclusive,
parte de segundos decimales.
whiteSpace
Esta representacin puede estar seguida inmediatamente
por una "Z" para indicar el horario universal coordinado
(UTC) o la zona horaria. Por ejemplo, la diferencia entre
la hora local y el horario universal coordinado, seguido
por un signo, + o -, seguido por la diferencia con
respecto a UTC representada como hh:mm (se requieren
los minutos). Si se incluye la zona horaria, tanto las
horas como los minutos deben estar presentes.

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

gYearMonth enumeration, pattern, Representa un mes gregoriano especfico de un ao

 minInclusive, gregoriano especfico. Conjunto de instancias no
minExclusive, peridicas de un mes de duracin.
maxInclusive,
maxExclusive, El patrn de gYearMonth es CCYY-MM con un
whiteSpace indicador opcional de zona horaria.

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

Representa una fecha gregoriana determinada que se

enumeration, pattern, repite, especficamente un da del ao, por ejemplo el
minInclusive, tres de mayo. Un gMonthDay es el conjunto de fechas
minExclusive, de calendario. Especficamente, es un conjunto de
gMonthDay
maxInclusive, instancias de periodicidad anual y de un da de duracin.
maxExclusive,
whiteSpace El patrn de gMonthDay es --MM-DD con un indicador
opcional de zona horaria como el de date.

Representa un da gregoriano que se repite,

especficamente un da del mes, por ejemplo el quinto.
enumeration, pattern,
Un gDay es el espacio de un conjunto de fechas del
minInclusive,
calendario. Especficamente, es un conjunto de
minExclusive,
gDay instancias de periodicidad mensual y de un da de
maxInclusive,
duracin.
maxExclusive,
whiteSpace
El patrn de gDay es ---DD con un indicador opcional
de zona horaria como el de date.

Representa un mes gregoriano que se repite cada ao.

enumeration, pattern,
Un gMonth es el espacio de un conjunto de meses del
minInclusive,
calendario. Especficamente, es un conjunto de
minExclusive,
gMonth instancias peridicas anuales de un mes de duracin.
maxInclusive,
maxExclusive,
El patrn de gMonth es --MM-- con un indicador
whiteSpace
opcional de zona horaria como el de date.
 Representa datos binarios arbitrarios codificados en
length, pattern, hexadecimal. hexBinary es el conjunto de secuencias de
maxLength, minLength, longitud finita de octetos binarios. Cada octeto binario se
hexBinary
enumeration, codifica como una tupla de caracteres que se compone
whiteSpace de dos dgitos hexadecimales ([0-9a-fA-F]) y representa
el cdigo del octeto.

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

Representa un nombre completo, que se compone de un

prefijo y un nombre local separados por un signo de dos
length, enumeration,
puntos. Tanto el prefijo como los nombres locales deben
QName pattern, maxLength,
ser un NCName. El prefijo debe estar asociado con una
minLength, whiteSpace
referencia a un identificador URI de espacio de nombres,
mediante una declaracin de espacio de nombres.

length, enumeration,
Representa un tipo de atributo NOTATION. Conjunto de
NOTATION pattern, maxLength,
QNames.
minLength, whiteSpace