María y Félix tienen una empresa de asesoría empresarial. Cada uno de esos trabaja en sus despachos, pero cada uso a su manera.
A María le gusta el sistema operativo Windows y trabajaba con una base de datos de documentos jurídicos. En cambio, Félix, es un enamorado del sistema operativo GNU/Linux y el software. Trabaja con Sistemas de Gestión de la Información de código abierto.
Dado que trabajaban con sistemas diferentes, se plateaba el problema de cómo podían compartir información manteniendo la infraestructura informática con la que trabaja cada uno.
Consultaron el problema a Juan, un técnico en administración de sistemas informáticos en red, y este les dijo que no había ningún problema si para el intercambio de información usaban lenguajes de marcas. Estos permiten el intercambio de información entre sistemas heterogéneos basándose en algunos de los estándares más conocidos.
María había salido a dar un paseo por el puerto, como todos los domingos por la mañana iba acompañada de su marido José Ramón y su hijo.
Mientras les veía jugar, estaba pensando que al día siguiente tenía que hablar con Juan, el técnico que se encargaba de resolver los problemas de informática de la empresa. Había estado pensando si existiría algún modo de poder mantener la estructura de datos de cada uno de los documentos que comparte con Félix. Además de asegurar que todos los documentos del mismo tipo mantienen la misma estructura, es decir, de homogeneizar y validar dichas estructuras.
Un lenguaje de marcas o lenguaje de marcado es una forma de codificar un documento que, junto con el texto, incorpora etiquetas o marcas que añaden información adicional acerca de la estructura del texto o su presentación.
Cada lenguaje de marcas debe establecer su vocabulario y su sintaxis. El vocabulario serán todas las marcas o etiquetas que podemos utilizar. La sintaxis establecerá las reglas de construcción del lenguaje: ¿Qué marcas están relacionadas? ¿Qué marcas se usan conjuntamente?, ¿Las marcas tienen un orden específico?, etc.
Uso de etiquetas: Los lenguajes de marcas emplean etiquetas para delimitar y describir partes específicas del contenido. Por ejemplo, en HTML,
indica un párrafo.
Estructura jerárquica: Los documentos se organizan en una estructura de árbol, donde los elementos pueden contener otros elementos, reflejando relaciones padre-hijo.
Separación de contenido y presentación: Especialmente en lenguajes descriptivos se busca separar la información del documento de su presentación visual, permitiendo una mayor flexibilidad en su representación.
Legibilidad y facilidad de edición: Al estar basados en texto plano, los documentos en lenguajes de marcas son fácilmente legibles y editables con herramientas simples, como editores de texto.
Portabilidad e interoperabilidad: Los documentos marcados pueden ser interpretados por diversos sistemas y plataformas, facilitando el intercambio de información entre diferentes aplicaciones.
Extensibilidad: Lenguajes de propósito general permiten la creación de etiquetas personalizadas, adaptándose a necesidades específicas de distintos dominios.
Interoperabilidad entre sistemas: Gracias a su formato estandarizado y legible por humanos y máquinas, los lenguajes de marcas permiten el intercambio de información entre diferentes plataformas y aplicaciones, independientemente de su tecnología subyacente. Esto simplifica la integración de sistemas y la colaboración entre organizaciones.
Estructuración y organización de datos: Los lenguajes de marcas permiten representar datos de manera jerárquica y estructurada mediante etiquetas y atributos. Esta organización facilita la interpretación y el análisis de la información por parte de sistemas automatizados, como los algoritmos de inteligencia artificial.
Escalabilidad y rendimiento: Los lenguajes de marcas, al ser ligeros, son adecuados para procesar grandes volúmenes de datos en tiempo real. Esto mejora el rendimiento de los sistemas y permite escalar las operaciones sin comprometer la eficiencia.
Integración Semántica: El uso de tecnologías como RDF y OWL en el marco de la Web Semántica permite representar metadatos y relaciones entre datos, facilitando su integración y reutilización.
No hay que confundir los lenguajes de marcas con lenguajes de programación. No son lo mismo, normalmente los lenguajes de marcas no tiene funciones aritméticas o variables, como poseen los lenguajes de programación. Históricamente, el marcado se usaba y se usa en la industria editorial y de la comunicación, así como entre autores, editores e impresores.
Es cierto que con la expansión de algunos lenguajes de marcas de propósito general y con la intención de tener lenguajes derivados de todo tipo, se han llegado a desarrollar lenguajes de marcas con instrucciones procedimentales como con el lenguaje XSLT.
Aunque en la práctica, en un mismo documento pueden combinarse varios tipos diferentes de lenguajes de marcas, estos se pueden clasificar en tres grupos:
Lenguajes de marcas orientados a presentación: Sirven para marcar el formato del texto. Se utilizan para maquetar la presentación de documentos. Utiliza elementos como espaciados, tabulados, párrafos, paginado, etc. Son los utilizados generalmente por los procesadores de texto y codifican cómo ha de presentarse el texto. Por ejemplo: marcando el paginado de un documento, si el texto será tabulado al inicio de cada párrafo o que se debe dejar un espacio entre caracteres determinado. Generalmente, las marcas se ocultan al usuario, lo que permite obtener un efecto WYSIWYG.
Lenguajes de marcas procedimentales: En estos lenguajes las marcas añaden instrucciones que el procesador de textos debe ejecutar para mostrar el resultado esperado. Se suelen usar también para la presentación de documentos, pero en este caso, dentro de un marco procedural. Las marcas añaden instrucciones como: activan y desactivan la negrita, activan y desactivan la cursiva, seleccionan las fuentes definidas en la tabla de fuentes, establece el tamaño de la fuente, establece el color del texto según la tabla de colores, etc. Entre los ejemplos más comunes encontramos a: TeX, Postcript, PDF, RTF, troff, nroff .
Lenguajes de marcas descriptivos o semánticos: Utilizan marcas para describir los fragmentos de texto, pero sin especificar cómo deben ser representados, o en qué orden. Este tipo no define qué se debe hacer con un trozo o sección del documento como hace los lenguajes de marcas procedimentales, sino que indican qué es esa información. Es decir, describen qué es lo que se está representando. Describen las diferentes partes del documento, pero sin especificar cómo deben representarse. Dentro de este grupo podemos distinguir:
Orientados a datos: La descripción se hace sobre la información contenida. Se suelen utilizar lenguajes de propósito general que permitan la creación de nuestros propios vocabularios o lenguajes de serialización donde solamente se marcan las estructuras jerárquicas de la información. Ejemplo de estos lenguajes son: SGML, XML, JSON, YAML.
Orientados a documentos: La descripción se hace teniendo en cuenta que el resultado esperado será la presentación en pantalla, papel u otro medio. Ejemplo de estos lenguajes son: HTML, XSLT, XSL-FO, Markdown, reStructuredText, AsciiDoc, OpenDocumentFormat, WikiText, LaTeX, etc.
What you see is what you get. Lo que ves es lo que obtienes.
Algunos ejemplos de lenguajes de marcado agrupados por su ámbito de utilización son:
Documentación electrónica
RTF (RichTextFormat): Formato de Texto Enriquecido, fue desarrollado por Microsoft en 1987. Permite el intercambio de documentos de texto ente distintos procesadores de texto.
LaTex: Su objetivo es la creación de ecuaciones matemáticas complejas.
DocBook: Permite generar documentos separando la estructura lógica del documento de su formato. De este modo, dichos documentos, pueden publicarse en diferentes formatos sin necesidad de realizar modificaciones en el documento original.
Tecnologías de Internet
HTML (HyperTextMarkupLanguage): Su objetivo es la creación de páginas web.
XHTML (eXtensible HyperText Markup Language): Ya en desuso, su objetivo también era las páginas web.
CSS (CascadingStyleSheets): es decir, Hojas de Estilo en Cascada se utilizan pare definir los estilos de los documentos web.
RSS (Really Simple Syndication): Permite la difusión de contenidos web.
Atom: También permite la difusión de contenidos web.
WikiDoc: Permite la creación de páginas wiki en servidores preparados para soportar este lenguaje.
JSON (JavaScriptObjectNotation): es un formato de intercambio de datos abierto para representar estructuras de datos simples y compleja.
Otros lenguajes especializados
MathML (Mathematical Markup Language): Su objetivo es expresar el formalismo matemático de tal modo que pueda ser entendido por distintos sistemas y aplicaciones.
VoiceXML (Voice eXtended Markup Language): tiene como objetivo el intercambio de información entre un usuario y una aplicación con capacidad de reconocimiento de habla.
MusicXML (Music eXtended Markup Language): Permite el intercambio de partituras entre distintos editores de partituras.
SGML (Standard Generalized Markup Language) es un metalenguaje estándar ISO (ISO 8879:1986) para definir lenguajes de marcado generalizados que describen la estructura y semántica de documentos electrónicos. Como precursor de HTML y XML, SGML proporciona un marco para crear DTD que especifican qué etiquetas y atributos son válidos en un documento particular. En SGML, los elementos se definen en un DTD y pueden incluir parámetros de procesamiento, enlaces múltiples y entidades genéricas, lo que confiere gran flexibilidad pero también complejidad.
Su sintaxis admite variantes de marcado (con o sin delimitadores < y >) y optimizaciones como minimización de etiquetas, adaptándose a distintos entornos de procesamiento britannica.com. A pesar de su potencia, SGML no alcanzó amplia adopción fuera de sectores específicos (publicaciones científicas, militares, gubernamentales) debido a la complejidad de sus herramientas y parsers. La necesidad de simplificar SGML condujo al desarrollo de XML como un subconjunto más ligero y fácil de procesar, conservando la filosofía de la descripción semántica.
SGML sigue siendo relevante en ciertos flujos de trabajo de publicación donde la validación estricta y la longevidad de los documentos son críticas, gracias a su robusta definición de metadatos.
La evolución de HTML más allá de SGML, especialmente desde HTML 5, refleja la transición de la web hacia formatos de marcado más sencillos y centrados en la usabilidad. Aun así, comprender SGML proporciona una base conceptual valiosa para entender los principios de otros lenguajes de marcado como XML y HTML. Su legado persiste en estándares derivados como DocBook y el sistema TEI, que aún emplean DTD basados en SGML para documentar textos complejos.
La definición formal y agnóstica de plataforma de SGML subraya la importancia de la interoperabilidad y la independencia tecnológica en el tratamiento de documentos.
XML
XML (eXtensible Markup Language) es un lenguaje de marcas diseñado para almacenar y transportar datos de forma estructurada y legible tanto por humanos como por máquinas . Establecido por el W3C en 1998 como un perfil simplificado de SGML, XML define una sintaxis clara de etiquetas anidadas y atributos que describen la semántica de la información.
A diferencia de HTML, XML no tiene un conjunto fijo de etiquetas; en cambio, los desarrolladores definen sus propias etiquetas según el dominio de datos que estén modelando . La estricta sintaxis de XML requiere un único elemento raíz, atributos entre comillas y el cierre explícito de todas las etiquetas para garantizar documentos bien formados .
Los esquemas XML (XSD) y los Document Type Definitions (DTD) permiten validar la conformidad estructural y tipográfica de los documentos, asegurando la integridad de los datos. XML es ampliamente utilizado en servicios web (SOAP), configuraciones de aplicaciones, formatos de interconexión como RSS y Atom, y estándares de intercambio empresarial (XBRL).
La tecnología XML incluye transformaciones XSLT, que convierten documentos XML en otros formatos como HTML o PDF mediante plantillas declarativas.
El modelo de objetos XML (DOM) permite navegar y manipular programáticamente la estructura del documento en lenguajes como JavaScript y Java.
Con la incorporación de namespaces, XML puede combinar vocabularios diversos en un solo documento sin colisiones de nombres, vital para aplicaciones complejas. Aunque más verboso que formatos alternativos como JSON o YAML, XML sigue siendo un estándar en entornos donde la validación rigurosa y la extensibilidad son cruciales.
El uso de XML se extiende a áreas como telecomunicaciones (SOAP), finanzas (FIXML) y procesamiento de documentos técnicos (DITA), demostrando su flexibilidad.
Su amplio soporte en bibliotecas y herramientas de todas las plataformas garantiza la interoperabilidad entre sistemas heterogéneos en la empresa.
HTML
HTML (HyperText Markup Language) es el lenguaje de marcado estándar para crear y estructurar el contenido de las páginas web . Fue desarrollado por Tim Berners-Lee en 1991 como parte de la arquitectura de la World Wide Web y estandarizado por el W3C en 1997.
HTML utiliza etiquetas delimitadas por corchetes angulares (< y >) para definir elementos como encabezados, párrafos, enlaces e imágenes. Cada etiqueta de inicio, por ejemplo <h1>, debe cerrarse con una etiqueta de fin correspondiente, como </h1>, o bien autoconcluirse en versiones modernas como HTML 5.
El modelo de objetos del documento (DOM) resultante permite que los scripts de JavaScript modifiquen dinámicamente la estructura y el contenido durante la ejecución. HTML 5, la revisión más reciente, introdujo nuevos elementos semánticos como y <nav>, mejorando la accesibilidad y el SEO. Además, HTML 5 soporta multimedia nativo con etiquetas <video> y <audio>, eliminando la necesidad de complementos externos para reproducir contenido multimedia.
Los atributos permiten añadir metadatos a los elementos, como class, id y data-*, facilitando la integración con CSS y frameworks de JavaScript . La interoperabilidad y compatibilidad hacia atrás de HTML garantizan que páginas antiguas sigan siendo legibles en navegadores modernos.
Los documentos HTML pueden validarse mediante DTDs o esquemas específicos para asegurar la conformidad con los estándares. La combinación de HTML con CSS para el estilo y JavaScript para la lógica de cliente constituye el pilar fundamental del desarrollo webfront-end.
Gracias a su simplicidad y amplio soporte, HTML continúa siendo la base de casi todos los sitios y aplicaciones web actuales.
CSS
CSS (Cascading Style Sheets) es un lenguaje de hojas de estilo diseñado para describir la presentación y el diseño de documentos escritos en HTML o XML . Fue desarrollado inicialmente por Håkon Wium Lie en 1994 y estandarizado por el W3C en 1996 para separar el estilo de la estructura del contenido.
CSS utiliza reglas basadas en selectores que apuntan a uno o más elementos del DOM, definiendo propiedades como color, font-size y margin. La especificidad de los selectores y el modelo de cascada determinan qué estilos prevalecen cuando varias reglas apuntan al mismo elemento.
La sintaxis básica consiste en un selector seguido de un bloque de declaraciones encerrado entre llaves, por ejemplo:
h1 {
color: red;
font-size: 2em;
}
Las hojas de estilo pueden enlazarse externamente mediante la etiqueta > en HTML, insertarse en la cabecera con <style>, o aplicarse en cada elemento con el atributo style.
CSS 3 introdujo módulos avanzados como flexbox, grid layout, transiciones y transformaciones 2D/3D, ampliando significativamente las capacidades de diseño responsivo. Los media queries permiten adaptar el estilo según las características del dispositivo, como el ancho de pantalla o la orientación, facilitando diseños adaptativos. Variables personalizadas (--var) y funciones nativas (calc(), var()) ofrecen mayor dinamismo en las hojas de estilo modernas.
La compatibilidad entre navegadores sigue siendo un reto, por lo que a menudo se utilizan prefijos específicos o herramientas de postprocesamiento como Autoprefixer. CSS puede integrarse con preprocesadores como SaaS o Less para utilizar características de programación como mixins, anidamiento y herencia.
Gracias a su capacidad de separar contenido y presentación, CSS es esencial para el desarrollo de interfaces web modernas y mantenibles .
JSON
Introducción
JavaScript Object Notation (JSON) es un formato de intercambio de datos abierto y basado en texto, que utiliza una notación de pares clave–valor y arrays para representar estructuras de datos simples y complejas.
Fue diseñado originalmente por Douglas Crockford a principios de los 2000 como una alternativa ligera a XML para aplicaciones web, y desde entonces se ha convertido en un estándar internacional (ECMA-404, ISO/IEC 21778:2017).
JSON adopta una sintaxis muy parecida a la de los literales de objeto y array de en, pero es independiente del lenguaje, lo que permite su uso en prácticamente cualquier entorno de programación moderno.
Su sintaxis es extremadamente concisa, limitándose a {}, [], :, , y comillas dobles para definir objetos y listas; carece de etiquetas verbosas y no admite comentarios, lo que favorece la interoperabilidad y la interpretación unívoca.
Además, JSON define un conjunto de tipos de datos primitivos —números, cadenas, booleanos y null— junto con estructuras compuestas de objetos y arrays, sin diferenciar entre enteros y flotantes para mayor simplicidad.
La especificación actual permite Unicode completo en cadenas y recomienda el uso de UTF-8 para el intercambio, garantizando compatibilidad internacional sin barreras de codificación.
Características
Legible por humanos: Su notación de pares clave–valor y listas anidadas resulta intuitiva.
Ligero y compacto: Ausencia de etiquetas verbosas; sólo usa {}, [], :, , y comillas dobles.
Basado en JavaScript: Aunque independiente, hereda la sintaxis de literales de objeto y array de en.
Sin comentarios ni formatos de presentación: Solo describe estructura y valores: objetos, array, cadenas, números, booleanos y null.
Usos
JSON es el lenguaje de facto para APIs REST y comunicación cliente-servidor en la web moderna, gracias a su ligereza y al soporte nativo en JavaScript (métodos <acronym title="JavaScript Object Notation">JSON</acronym>.stringify() y <acronym title="JavaScript Object Notation">JSON</acronym>.parse()). Asimismo, se emplea ampliamente en configuración de herramientas build y frameworks (por ejemplo, package.json en Node.js) y en almacenamiento de datos en NoSQL como MongoDB.
Su universalidad ha llevado a la creación de bibliotecas en todos los lenguajes de programación populares (Python, Java, Ruby, Go, etc.), lo que facilita la interoperabilidad entre sistemas heterogéneos sin necesidad de pasarelas o transformaciones complejas.
Intercambio de datos en aplicaciones web: Comunicación cliente-servidor (AJAX, APIs REST).
Serialización de objetos en múltiples entornos: Convertir estructuras de datos a texto para almacenamiento o transmisión en Ruby, Python, Java, etc.
Configuración sencilla: A veces usado en ficheros de configuración cuando no se requieren comentarios.
Sintaxis y ejemplos
Una estructura JSON básica podría describir una persona así:
Aquí vemos objetos anidados, arrays de cadenas, uso de formato de fecha y configuración de preferencias, ilustrando la versatilidad de JSON para serializar configuraciones y datos de usuario.
YAML
Introducción
YAML (YAML Ain’t Markup Language) es un lenguaje de serialización de datos diseñado para ser legible por humanos, basado en Unicode y orientado a la interoperabilidad entre lenguajes de programación ágiles como Python o Ruby. Originalmente acuñado como “Yet Another Markup Language” en 2001, evolucionó hacia el acrónimo recursivo actual para enfatizar su propósito de datos, no de presentación.
Su filosofía prioriza la sencillez visual mediante indentación significativa en lugar de delimitadores explícitos, y añade funcionalidades como anclajes (&) y referencias (*) para evitar la repetición de estructuras complejas.
YAML preserva tres tipos básicos de nodos: escalares (cadenas, números, booleanos, fechas), secuencias (listas ordenadas) y mapeos (diccionarios clave–valor).
La ausencia de llaves y corchetes, sustituida por la indentación, hace el código más limpio, aunque exige cuidado para mantener la consistencia en los espacios.
Soporta etiquetas explícitas para tipado —por ejemplo !!str, !!int— y extensiones como anclajes/referencias, lo que es muy útil para definir configuraciones DRY (Don’t Repeat Yourself) en entornos como Kubernetes o Ansible.
Características
Human-friendly: Usa indentación significativa para anidar, evitando llaves y corchetes.
Superset de JSON: Todo JSON válido es YAML válido, pero YAML ofrece más tipos (fechas, null implícito, etc.).
Etiquetas y tipos integrados: Soporta enteros, flotantes, booleanos, fechas y más mediante etiquetas.
Referencias y anclajes: Permite reutilizar fragmentos de datos con & y *, facilitando la DRY (Don’t Repeat Yourself).
Usos
YAML se ha convertido en estándar de facto para archivos de configuración en infraestructuras modernas: Docker Compose (docker-compose.yml), CI/CD con Travis CI, Helm charts de Kubernetes y playbooks de Ansible, entre otros. Su claridad permite que incluso no desarrolladores editen configuraciones sin gran curva de aprendizaje.
También se emplea en serialización de objetos para transmisión de mensajes y registros legibles, así como en especificaciones de APIs (OpenAPI v2) y plantillas de despliegue en la nube, donde la legibilidad humana acelera la colaboración entre equipos.
Archivos de configuración: Kubernetes, Travis CI, Docker Compose, Ansible, etc.
Intercambio de mensajes: Formatos de registros y mensajería en red.
Persistencia de objetos: Serialización en aplicaciones donde la claridad manual es prioritaria.
Aquí vemos un mapeo persona con claves anidadas y una secuencia hobbies; las comillas son opcionales, salvo cuando la cadena contiene caracteres especiales.
Un ejemplo más completo, con anclajes y referencias:
En este YAML, el bloque credenciales_db se define una sola vez con &credenciales y luego se reutiliza en base_de_datos con *credenciales, evitando duplicación de información.
Markdown
Introducción
en es un lenguaje de marcado ligero creado en 2004 por John Gruber y Aaron Swartz para facilitar la redacción de texto enriquecido en archivos de texto plano usando símbolos comunes como # y *. No incluye instrucciones de estilo visual (tamaño, color), sino que se enfoca en la semántica: encabezados, listas, enlaces, etc.
Dada su popularidad, en 2014 surgió CommonMark, una especificación formal que resuelve ambigüedades de la sintaxis original y ofrece un test suite para garantizar implementación coherente entre parsers.
La sintaxis básica de Markdown es minimalista: usa # para encabezados, * o - para listas, **texto** para negrita y *texto* para cursiva, manteniendo la legibilidad del texto sin procesar. Markdown no pretende definir estilos detallados; esa capa se deja a CSS o al motor de renderizado, conservando la separación entre contenido y presentación.
Muchas extensiones (GitHub Flavored Markdown, Markdown Extra, MultiMarkdown) amplían la sintaxis básica con tablas, tareas, enlaces internos y comentarios en línea, adaptándose a necesidades de documentación técnica y colaboración en repositorios.
Características
Sintaxis sencilla y legible: Usa caracteres ASCII comunes (#, *, [], etc.) para dar formato mientras mantiene la legibilidad sin procesar.
en: Hay numerosas extensiones para tablas, tareas, anclajes, etc.
Separación de contenido y estilo: Se enfoca en la estructura semántica (encabezados, listas, enlaces) dejando el estilo visual al CSS o al motor de renderizado
Usos
Markdown es omnipresente en la documentación de proyectos de software (archivos README en GitHub, GitLab, Bitbucket), blogs estáticos (Jekyll, Hugo) y plataformas de notas (Obsidian, Typora, hackmd.io). Su facilidad de edición en cualquier editor de texto y el soporte en visores WYSIWYG lo convierten en una herramienta versátil para escribir desde entradas de blogs hasta presentaciones.
Asimismo, muchos foros y sistemas de comentarios (Stack Overflow, Discourse, Reddit) adoptaron variantes de Markdown por su equilibrio entre potencia y sencillez, permitiendo a usuarios con distintos niveles técnicos formatear contenido sin conocer HTML.
Documentación de proyectos: README Markdown GitHub, GitLab, Bitbucket.
Blogs y artículos: Jekyll, Hugo, Hexo, y plataformas como Ghost.
Notas y presentaciones: Obsidian, Typora, hackmd.io.
Sintaxis y ejemplos
Encabezados
# Título nivel 1
## Título nivel 2
Los encabezados usan de 1 a 6 #;
Estilo en línea
Este es un párrafo con **negrita**, *cursiva* y ~~tachado~~.
Las decoraciones en línea emplean **, * y ~~ respectivamente.
Listas
- Item de lista
- Item de lista
1. Subítem numerado
1. Subítem numerado
- Item de lista
Enlaces
[Enlace a Google](https://www.google.es)
Imágenes
Bloques de código
``<code>js
// Bloque de código JavaScript
console.log("Hola, mundo");
``
A finales de los años 60, para poder introducir anotaciones dentro de documentos electrónicos, surgen unos lenguajes informáticos, distintos de los lenguajes de programación, orientados a la gestión de información. Con el desarrollo de los editores y procesadores de texto surgen los primeros lenguajes informáticos especializados en tareas de descripción y estructuración de información: los lenguajes de marcas. Paralelamente, también, surgen otros lenguajes informáticos orientados a la representación, almacenamiento y consulta eficiente de grandes cantidades de datos: lenguajes y sistemas de bases de datos.
Los lenguajes de marcas surgieron, inicialmente, como lenguajes formados por el conjunto de códigos de formato que los procesadores de texto introducen en los documentos para dirigir el proceso de presentación (impresión) mediante una impresora. Como en el caso de los lenguajes de programación, inicialmente estos códigos de formato estaban ligados a las características de una máquina, programa o procesador de textos concreto y, en ellos, inicialmente no había nada que permitiese al programador (formateador de documentos en este caso) abstraerse de las características del procesador de textos y expresar de forma independiente a éste la estructura y la lógica interna del documento.
Ejemplo de código de como sería un lenguaje de marcas anterior a GML. Las etiquetas son ficticias.
Dado el siguiente documento:
<times 14><color verde><centrado> Este texto es un ejemplo para mostrar
la utilización primitiva de las marcas</centrado></color></times 14>
<color granate><times 10><cursiva>Para realizar este ejemplo se utilizan
etiquetas de nuestra invención. </cursiva> Las partes importantes del
texto pueden resaltarse usando la <negrita>negrita</negrita>, o el
<subrayar>subrayado</subrayar></times 10></color>
Al imprimirlo se obtendría:
Este texto es un ejemplo para mostrar la utilización primitiva de las marcas
Para realizar este ejemplo se utilizan etiquetas de nuestra invención. Las partes importantes del texto pueden resaltarse usando la negrita, o el subrayado
Posteriormente, se añadieron como medio de presentación a la pantalla. Los códigos de estilo de visualización anteriores ya no aparecen, y se emplean otros medios para marcados, diferentes a la inclusión a mano de cadenas formateadoras, por lo que ahora ese proceso se automatiza y es suficiente con pulsar una combinación de teclas, o un botón, para lograr los resultados requeridos. Aunque esto es sólo una abstracción, para su uso interno, las aplicaciones siguen utilizando marcas para delimitar aquellas partes del texto que tienen un formato especial.
Este marcado estaba exclusivamente orientado a la presentación de la información, aunque pronto fueron conscientes de las posibilidades del marcado y se le dieron nuevos usos que resolverían una gran variedad de necesidades, apareció el formato generalizado.
Uno de los problemas que se conocen desde hace décadas en la informática es la falta de estandarización en los formatos de información usados por los distintos programas.
Para resolver este problema, en los años sesenta IBM encargó a Charles F. Goldfarb la construcción de un sistema de edición, almacenamiento y búsqueda de documentos legales. Tras analizar el funcionamiento de la empresa llegaron a la conclusión de que para realizar un buen procesado informático de los documentos había que establecer un formato estándar para todos los documentos que se manejaban en la empresa. Con ello se lograba gestionar cualquier documento en cualquier departamento y con cualquier aplicación, sin tener en cuenta dónde ni con qué se generó el documento. Dicho formato tenía que ser válido para los distintos tipos de documentos legales que utilizaba la empresa, por tanto, debía ser flexible para que se pudiera ajustar a las distintas situaciones.
El formato de documentos que se creó como resultado de este trabajo fue GML, cuyo objetivo era describir los documentos de tal modo que el resultado fuese independiente de la plataforma y la aplicación utilizada.
El formato GML evolucionó hasta que en 1986 dio lugar al estándar ISO 8879 que se denominó SGML. Éste era un lenguaje muy complejo y requería de unas herramientas de software caras. Por ello su uso ha quedado relegado a grandes aplicaciones industriales.
En 1989/90 Tim Berners-Lee creó el World Wide Web y conociendo SGML, se encontró con la necesidad de organizar, enlazar y compatibilizar gran cantidad de información procedente de diversos sistemas. Para resolverlo, a partir de la sintaxis SGML, creó un lenguaje de descripción de documentos llamado HTML, siendo una combinación de dos estándares ya existentes:
ASCII: Es el formato que cualquier procesador de textos sencillo puede reconocer y almacenar. Por tanto es un formato que permite la trasferencia de datos entre diferentes ordenadores.
SGML: Lenguaje que permite dar estructura al texto, resaltando los títulos o aplicando diversos formatos al texto.
HTML es una versión simplificada de SGML, ya que sólo se utilizaban las instrucciones absolutamente imprescindibles. Era tan fácil de comprender que rápidamente tuvo gran aceptación logrando lo que no pudo SGML, siendo un rotundo éxito en la World Wide Web. HTML se convirtió en un estándar general para la creación de páginas web. Además, tanto las herramientas de software como los navegadores que permiten visualizar páginas HTML son cada vez mejores.
El HTML es hoy día el tipo de documento más empleado en el mundo. Su sencillez era tal que cualquier persona podía escribir documentos en este formato, sin apenas necesidad de conocimientos de informática. Esta fue una de las razones de su éxito, pero también condujo a un cierto caos. El crecimiento exponencial de la web en los años 90 produjo documentos en cantidades ingentes pero mal estructurados, problema agravado aún más por la falta de respeto por los estándares, por parte de diseñadores web y fabricantes de software.
American Standard Code for Information Interchange o Código Estadounidense Estándar para el Intercambio de Información), es un código de caracteres de 7 bits para representar los caracteres del alfabeto latino, tal como se usa en inglés moderno. No estarían representados caracteres como la “ñ”.
<html>
<head>
<title>Ejemplo de código HTML</title>
</head>
<body bgcolor="#ffffff">
<p><b>1 de Octubre de 2015</b></p>
<p><b>Bienvenido al modulo de "Lenguajes de Marcas y Sistemas de Gestión de Información"</b></p>
<p>En este curso aprenderás, entre otras cosas:<br/>
<ul>
<li>Las ventajas que ofrece XML </li>
<li>La creación de documentos bien formados </li>
<li>La creación de DTD</li>
</ul>
</p>
</body>
</html>
Al publicarlo en un navegador, obtendríamos el siguiente resultado:
Elaboración propia. Víctor Gómez. Ejemplo de documento HTML(CC0)
Como respuesta a problemas surgidos en torno al HTML, el W3C establece, en 1998, el estándar internacional XML, un lenguaje de marcas puramente estructural que no incluye ninguna información relativa al diseño, que permite crear etiquetas adaptadas a las necesidades (de ahí lo de "extensible"). Está convirtiéndose con rapidez en estándar para el intercambio de datos en la Web. A diferencia de HTML las etiquetas indican el significado de los datos en lugar del formato con el que se van a visualizar los datos.
Utilizar un esquema para definir de forma exacta las etiquetas y los atributos.
La estructura y el diseño son independientes.
En realidad XML es un conjunto de estándares relacionados entre sí y que son:
XSLT, eXtensible Style Language Transformations. Permite definir hojas de estilo para los documentos XML e incluye capacidad para la transformación de documentos.
XML Linking Language, incluye Xpath, Xlink y Xpointer. Determinan aspectos sobre los enlaces entre documentos XML.
XML Namespaces. Proveen un contexto al que se aplican las marcas de un documento de XML y que sirve para diferenciarlas de otras con idéntico nombre válidas en otros contextos.
XML Schemas. Permiten definir restricciones que se aplicarán a un documento XML. Actualmente los más usados son las DTD.
El World Wide Web Consortium, abreviado W3C, es un consorcio internacional que produce recomendaciones para la World Wide Web.
El navegador es una plataforma para el desarrollo de aplicaciones.
El navegador es un visor de páginas.
Fin de la guerra de los navegadores y etiquetas propietarias.
El problema de la 'no compatibilidad' y las diferencias entre navegadores ha alcanzado un punto en el que la solución es difícil.
También llamado vínculo o hipervínculo, es un elemento de una página web que permite ir a un punto específico del mismo o de otro documento electrónico.
Al día siguiente, cuando habla con Juan, sus dudas quedan disipadas. Resulta que hay varias posibilidades para asegurar una normalización en el formato de los documentosXML.
Juan comienza por describir la estructura de un documento XML y Félix y María descubren que puede ser un poco más compleja que la que habían estado usando hasta entonces para generar sus documentos.
El lenguaje de marcado extensible XML, por su nombre en inglés eXtensible Markup Language, es un lenguaje de marcas derivado de SGML (ISO 8879). Originalmente diseñado para la publicación electrónica a gran escala, XML también se utiliza para el intercambio de datos y el almacenamiento.
XML es un metalenguaje que permite definir lenguajes de marcas derivados de él. Fue desarrollado por el World Wide Web Consortium (W3C).
XML es una simplificación del lenguaje SGML que elimina muchas de sus características más complejas, con el objeto de facilitar la manipulación de los documentos escritos en alguno de sus dialectos de una forma homogénea.
Desde su lanzamiento en 10 de febrero de 1998, ha sido utilizado para la creación de multitud de lenguajes derivados en distintas áreas. Se utiliza como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable.
XML y sus lenguajes derivados han sido criticados por su nivel de detalle, complejidad y redundancia. La manipulación de documentos XML en lenguajes de programación o bases de datos puede ser difícil, especialmente cuando se utilizan documentos XML altamente estructurados. Además, han surgido lenguajes como JSON y YAML, más sencillos y compactos, que han hecho que XML no sea la única alternativa para el intercambio de datos. Pese a tecnologías como JSON, que ha ganado popularidad en el intercambio de datos, especialmente en aplicaciones web debido a su simplicidad y eficiencia, XML mantiene su relevancia en escenarios donde en la precisión en la estructura de datos y la validación son cruciales.
El lenguaje XML es un metalenguaje que nos sirve para crear otros lenguajes derivados. Normalmente, estos lenguajes derivados no los crean los desarrolladores de software, sino grandes compañías u organizaciones como W3C. En cambio, sí que es común que los desarrolladores declaren sus propias estructuras XML para el intercambio de datos.
Texto plano y marcado.
Los documentos XML son creados en texto plano (sin formato). XML es un lenguaje de marcado. El marcado en XML se realiza mediante etiquetas que se añaden a la información para estructurarla. Estas etiquetas permite "interpretar" la estructura que le queremos otorgar a nuestra información.
Dependiendo de si las etiquetas las declaramos nosotros para estructurar nuestra información o usamos un lenguaje derivado ya inventado, usaremos un vocabulario de creación propia o un vocabulario de un lenguaje derivado de XML.
En esta unidad utilizaremos XML directamente para estructurar los ejercicios que se nos planteen y no lenguajes derivados.
En XML, el marcado se realiza mediante etiquetas y estas están contenidas entre los símbolos de ángulos, los caracteres "<" y ">". Por ejemplo en:
<nombre>
También podemos añadir caracteres o conjuntos de caracteres especiales mediante entidades. Las entidades las marcaremos entre los símbolos de "&" y ";" por ejemplo la entidad " que representa el símbolo de comillas dobles.
"
El marcado puede ser tan rico como se quiera. Puede ser interesante detectar necesidades futuras y crear documentos con una estructura fácilmente actualizables. A continuación se muestra un ejemplo de documento XML.
Los documentos XML pueden tener comentarios, El texto o código comentado no será interpretado por el intérprete XML. Los comentarios se utilizan para documentar los documentos XML y facilitar revisiones y modificaciones en dichos documentos.
Para establecer un comentario utilizaremos las cadenas "". En el interior de estas cadenas pondremos escribir nuestros comentarios utilizando cualquier carácter, excepto dos guiones seguidos. Los comentarios los podemos ubicar en cualquier posición en el documento XML salvo antes de la declaración XML o dentro de una etiqueta. Un comentario puede ocupar varias líneas.
<!-- Comentario -->
<!--
Comentario
-->
Estructura de un documento XML.
Los documentos XML están estructurados por dos partes:
prólogo (opcional): Muestra información útil para el intérprete.
ejemplar (obligatorio): Contiene la información estructurada propiamente dicha.
El prólogo, preámbulo o encabezado es utilizado por el intérprete XML mostrando los datos que necesita para interpretar correctamente el documento XML. Es una parte opcional, es decir, un documento XML puede ser interpretado aunque no tenga prólogo. En caso de existir, el prólogo debe preceder al ejemplar. Su inclusión facilita el procesado de la información del ejemplar. A continuación hemos resaltado el prólogo de un documento XML.
Podemos ver destacado el prólogo formado por las dos primeras líneas. En primer lugar, tenemos la declaración XML con los atributos version y encoding. En la segunda línea tenemos la declaración de tipo de documento en la que nos indica que el elemento raíz será el elemento alumno.
Un prólogo puede estar formado por una o varias de estas líneas:
Declaración XML: Es opcional, pero si existe debe ser la primera línea del documento XML. Si no es la primera línea se genera un error que impide que el documento sea procesado. La declaración XML puede tener tres atributos:
Versión (version): Este atributo es obligatorio. Aunque hubo una versión 1.1 normalmente siempre utilizaremos la versión 1.0 de XML que es la más estandarizada.
<?xml version="1.0" encoding="UTF-8" ?>
Codificación (encoding): Este atributo es opcional, pero en caso de aparecer debe ser el segundo en orden después del atributo version. Determina el conjunto de caracteres que se utiliza en el documento. En la actualidad ya se ha normalizado el uso de la codificación UTF-8 (Unicode Transformation Format-8-bits). Otra codificación que podemos encontrar es la iso-8859-1 (Latin-1) que permite el uso de tildes o caracteres como la ñ. UTF-8 soporta más caracteres y permite la visualización correcta de estos en más sistemas o lugares que iso-8859-1. A no ser que por algún motivo no sea posible el uso de UTF-8, la recomendación es siempre utilizar UTF-8, que recordemos es la codificación de caracteres seleccionada por defecto.
Estándares ISO y códigos de país más importantes
Estándar ISO
Código de país
UTF-8 (Unicode)
Conjunto de caracteres universal
ISO -8859-1 (Latin-1)
Europa occidental, Latinoamérica
ISO -8859-2 (Latin-2)
Europa central y oriental
ISO -8859-3 (Latin-3)
Sudoeste de Europa
ISO -8859-4 (Latin-4)
Países Escandinavos, Bálticos
ISO -8859-5
Cirílico
ISO -8859-6
Árabe
ISO -8859-7
Griego
ISO -8859-8
Hebreo
ISO -8859-9
Turco
ISO-8859-10
Lapón. Nórdico, esquimal
EUC-JP
Japonés
Autonomía (standalone): Este atributo es opcional, pero en caso de aparecer debe ser el último tras los atributos version y encoding. Informa de si el documento necesita de otro archivo para su interpretación. Si el documento es independiente y no necesita de documentos externos marcaremos este atributo como standalone=”yes”. Si necesita de algún documento externo para completar su declaración marcaremos el atributo como standalone=”no”.
Declaración del tipo de documento (DOCTYPE): Es una línea opcional y define qué tipo de documento estamos creando para ser procesado correctamente. Toda declaración de tipo de documento comienza por la cadena DOCTYPE, el nombre del elemento raíz del documento XML y se cierra con un ángulo ">". Si queremos validar nuestro documento XML frente a un esquema de reglas DTD entonces necesitamos utilizar esta declaración.
<!DOCTYPE colegio >
<!DOCTYPE colegio SYSTEM "colegio.dtd" >
Instrucciones de procesamiento: Son líneas opcionales e indican al intérprete distintas acciones para procesar el documento.
El ejemplar o contenido es la parte obligatoria de un documento XML. Contiene la información propiamente dicha del documento XML. Al menos debe contener un elemento al que llamaremos elemento raíz. Aunque lo normal es que esté formado por este elemento raíz y que dentro de él se declaren una serie de elementos anidados formando una determinada estructura que nos facilite la comprensión de la información contenida. Esta estructura jerárquica creada a partir del elemento raíz se puede representar gráficamente como un árbol de nodos.
En realidad, el ejemplar es el elemento raíz y sus elementos descendientes. Este elemento raíz debe estar nombrado en la declaración de tipo de documento (!DOCTYPE).
Podemos ver destacado el ejemplar formado por el elemento alumno. Este elemento alumno es el elemento raíz y contiene toda la información de forma estructurada mediante el anidamiento de los elementos: nombre, apellidos, anno_nac y nota_media.
Nótese que el elemento alumno se abre en la tercera línea y se cierra en la octava. De esta forma indicamos que el elemento alumno es el elemento padre del resto de elementos.
En el ejemplo anterior tenemos dos niveles de anidamiento. En primer lugar, tenemos el elemento raíz biblioteca que tiene por hijos los elementos: título, editorial y autoría. Este último elemento autoría, a su vez, es padre de varios elementos autor. Cada nivel de anidamiento requerirá de un nivel de tabulado o indentado.
A la hora de estructurar nuestra información debemos hacer un proceso de reflexión. Debemos pensar en las distintas entidades de información y como atomizar estas para poder tener un acceso lo más granular posible. Es decir, tenemos que ir refinando cada entidad de información en subentidades hasta llegar a un detalle que nos sea práctico a la hora de manejar dicha información. No hay una regla fija que nos indique cuanto hay que refinar, esto lo dará la experiencia y el desarrollo de ejercicios previos.
Para estructurar la información, XML cuenta con elementos. Estos son los distintos bloques de información que tienen entidad propia y en los que podemos dividir nuestra información para definir la estructura de un documento XML. Estos tienen la peculiaridad de que pueden contener a su vez otros subelementos. Estableciendo una jerarquía elemento padre y elemento/s hijo/s. De modo que podemos construir un árbol de elementos partiendo de una elemento raíz e ir refinando y desgranando su información en subelementos más pequeños y estos a su vez, si es necesario, seguir refinándolos hasta llegar a un nivel de detalle adecuado al problema que se nos plantee. A estos elementos finales que contienen texto alfanumérico y ya no contienen más elementos hijos se les suele llamar elementos terminales, elementos de contenido textual o simplemente elementos simples.
El marcado de los elementos en XML se realiza mediante etiquetas. Normalmente, delimitando con dos etiquetas: una etiqueta de apertura y una etiqueta de cierre. Existe la posibilidad de que un elemento tenga contenido vacío, en ese caso especial, se utiliza una única etiqueta que llamamos etiqueta de contenido vacío. Diferenciamos estas etiquetas si nos fijamos en si la etiqueta contiene o no la barra y si la contiene la tiene al inicio o al final de la etiqueta.
Para indicar un elemento terminal usamos las etiquetas de apertura y cierre como en el ejemplo de <nombre>Ana</nombre>.
Para indicar un elemento padre usaremos las etiquetas como en el ejemplo de <alumno> ... </alumno para contener a sus elementos hijos.
Para indicar un elemento de contenido vacío usaremos la etiqueta como en ejemplo de <mujer />.
<!-- Etiqueta de apertura de un elemento padre -->
<alumno>
<!-- Elemento simple con etiquetas de apertura y cierre -->
<nombre>Ana</nombre>
<!-- Elemento vacío con etiqueta de contenido vacío -->
<mujer />
</alumno>
<!-- Etiqueta de cierre de un elemento padre -->
Los identificadores de las etiquetas han de ser autodescriptivos, lo que facilita el trabajo que se hace con ellas, es decir, que ilustren su contenido. Por ejemplo, si estamos con datos relativos a un libro, su identificador de etiqueta no debería ser caracteristica, ya que es demasiado ambiguo, deberíamos utilizar etiquetas como título, isbn, páginas, etc. La estructura de elementos y sus identificadores nos muestra la estructura semántica del documento.
Elementos.
Los elementos ha de cumplir las siguientes normas:
Un documento XML debe tener un único elemento raíz. Este hecho hace que un documento XML se pueda representar como una estructura jerárquica en forma de árbol invertido.
Al anidar elementos (introducir unos dentro de otros) hay que tener en cuenta que no puede cerrarse un elemento que contenga algún otro elemento que aún no se haya cerrado.
Los elementos deben estar delimitador por etiquetas, ya sean de apertura y cierre o de contenido vacío.
Un elemento puede contener texto (elemento terminal), uno o varios elementos (elemento padre) o ambas cosas a la vez (elemento de contenido mixto). Este último caso no es recomendable de usar por los problemas que puede ocasionar en su declaración o la dificultad de manipular su contenido.
Los identificadores de las etiquetas de inicio y de cierre de un mismo elemento han de ser idénticos, respetando las mayúsculas y minúsculas. Además, deben cumplir el resto de requisitos de los identificadores:
Deben ser una única palabra.
Son sensibles a letras minúsculas y mayúsculas (case sensitive).
Pueden formarse con cualquier combinación de números y letras, pero el primer carácter debe ser siempre una letra o un guión bajo (_).
Se pueden usar signos de puntuación, excepto las comillas simples y dobles, apostrofes, dólar, y punto y coma. Pueden contener el carácter dos puntos (:) pero su uso se reserva para definir espacios de nombres.
No puede haber saltos de línea o espacios en blanco antes del identificador de etiqueta.
No puede haber comentarios dentro de las etiquetas.
Las letras no inglesas (á, Á, ñ, Ñ, etc.) están permitidas. Pero, al igual que el carácter guion medio (-) y el punto (.), se recomienda no utilizarlos para reducir posibles incompatibilidades o errores en programas que no los interpreten bien.
No puede comenzar por xml, ya que su uso está reservado para otros propósitos. Tampoco sus variantes (XML, XmL, xML, etc.).
El contenido de los elementos no puede contener la cadena "]]>" por compatibilidad con SGML. Además, no se pueden utilizar directamente los caracteres mayor que (>), menor que (<), ampersand (&), dobles comillas (") y apostrofe o comillas simples (‘). En su lugar se deben usar las entidades: > < & " y '.
Este es un error muy común y bastante errado. Es importante no mezclar la información que nos aportan los enunciados de los ejercicios con la estructura que creamos nosotros al declarar elementos y sus identificadores. Por ejemplo, si queremos clasificar los países por sus continentes, podemos cometer el siguiente error:
En este caso estamos utilizando erróneamente el nombre de los continentes como identificador de los elementos.
Si nos fijamos en el elemento pais su identificador se generaliza y sirve para todos los países. Su contenido se concreta en cada uno de los respectivos países: España, Portugal, etc. Con esto tenemos separación entre estructura, ya que el elemento pais es un elemento genérico que podemos reutilizar; y la información que solo se utiliza como contenido de los elementos.
Si intentamos hacer lo mismo que hacíamos con pais con continente nos damos cuenta de que no tenemos un elemento terminal para poner el nombre del continente. Por lo que podemos hacer la siguiente estructura separando el nombre del continente del listado de elementos pais añadiendo los elementos nombre y paises. Esta estructura es reutilizable para otros ejemplos.
Cuando tengamos que declarar una secuencia de elementos todos iguales podemos cometer este error. Por ejemplo, si tenemos una aula y tenemos que listar a los alumnos. En estos casos no podemos numerar a los alumnos directamente en el identificador de la etiqueta. Si lo hacemos tendríamos elementos diferentes y no podríamos reutilizar las reglas que posteriormente declararemos.
En caso de necesitar un número de orden lo indicaríamos con un atributo en el elemento alumno.
Elemento no atómicos
Siguiendo con el ejemplo anterior, sería incorrecto no separar a los alumnos en elementos individuales y ponerlos todos juntos en el mismo elemento separados con una coma o un espacio en blanco.
Si vas a incluir información similar en distintas partes del documento XML, trata de usar la misma estructura de elementos. Es decir, lo correcto es reutilizar estructuras siempre que sea posible.
Además, siguiendo con el ejemplo, si tenemos profesores y alumnos, como ambos tienen nombre, podemos reutilizar la etiqueta nombre en ambas estructuras, ya que por su ubicación son distinguibles.
En este caso, no hay problema en reutilizar los elementos nombre y apellidos, puesto que en la jerarquía uno se encuentra en /aula/profesores/profesor/nombre y el otro en /aula/alumnos/alumno/nombre.
Los atributos son parejas clave-valor con el formato identificador="valor".
Los identificadores de los atributos han de cumplir las mismas reglas que los identificadores de los elementos. Además, no pueden contener el carácter menor que (<).
El valor de un atributo se debe delimitar entre comillas dobles (") o comillas simples ('). Dentro de dicho valor no se pueden usar las mismas comillas que se usan como delimitador. Los atributos deben tener obligatoriamente un valor asignado.
Un atributo está asociado a un único elemento, por lo que el atributo debe ser una propiedad del elemento al que pertenezca. Los atributos se declaran exclusivamente en la etiqueta de apertura después del identificador del elemento (o bien en la etiqueta de contenido vacío).
En el ejemplo anterior hemos declarado el atributo moneda en el elemento precio, ya que es una propiedad de este. Aunque esta información también la podríamos haber declarado como elemento hermano.
Un elemento puede tener más de un atributo. Los atributos de un elemento deben separarse con espacios en blanco y no pueden tener el mismo identificador. Atributos de distintos elementos sí que pueden tener el mismo identificador. El orden en los atributos de un elemento no es significativo.
No hay una regla fija de cuando usar atributos. En el entorno en el que estamos trabajando nosotros a nivel académico y utilizando el lenguaje XML directamente para implementar estructuras de información para el intercambio de datos suele ser habitual utilizar fundamentalmente elementos, dejando los atributos para información muy concreta como metadatos, identificadores, categorización y magnitudes. Es decir, información que aclare la semántica del elemento al que pertenece. Intentaremos evitar el uso de atributos o procurar no abusar de ellos.
Pretenderemos que la estructura, el significado (semántica) recaiga sobre los elementos.
Crearemos elementos en los siguientes casos:
Estructuras complejas que se pueden dividir en otras más sencillas.
Estructuras con más de un valor o secuencias de valores.
Información que se supone será utilizada por los usuarios o se modificará con frecuencia.
Crearemos atributos en los siguientes casos:
Metadatos: información interna de los sistemas que rara vez usan los usuarios. Por ejemplo: código, visible, prioridad, etc
Identificadores: que sirvan para hacer búsquedas únicas. Por ejemplo: DNI, Matrícula, etc
Categorizaciones: que sirvan para hacer búsquedas por categorías o filtrado. Solo suelen tomar unos cuantos valores fijos. Por ejemplo: ubicación, departamento, nivel, grupo, etc.
Magnitudes: que aporten la magnitud a cantidades numéricas para que el tratamiento de los números sea más sencillo y no sea necesario manipular los textos, para quitarles las unidades, antes de realizar cálculos. Por ejemplo: moneda (euro, dólar, ...), unidades (m, kg, km, km/h, ...)
Como se observa en el ejemplo, los atributos se definen y dan valor dentro de una etiqueta de inicio o de elemento vacío, a continuación del identificador del elemento o de la definición de otro atributo, siempre separado de ellos por un espacio.
Los valores de los atributos tienen que definirse entre comillas simples o dobles. Estos valores van precedidos del identificador del atributo y un signo de igual (=).
Cuando unimos diferentes documentos XML, los vocabularios definidos en ellos, pueden producir solapamiento al utilizar identificadores iguales. Los espacios de nombres tratan de evitar las ambigüedades que podrían surgir en caso de que haya elementos o atributos con el mismo identificador.
Los espacios de nombres permiten definir la pertenencia de los elementos y los atributos de un documento XML al contexto de un vocabulario XML determinado. Los espacios de nombres, también conocidos como XML namespaces, asignan un prefijo a un conjunto de elementos y atributos de un vocabulario específico, permitiendo que los elementos y atributos de diferentes vocabularios coexistan en el mismo documento sin causar conflictos.
Al declarar un espacio de nombres utilizaremos unos identificadores únicos llamados Uniform Resource Identifier (URI). Estos Identificadores Uniformes de Recursos son los mismos que utilizamos en el protocolo HTTP para identificar de forma unívoca los archivos que forman parte de un sitio web. Al declarar espacios de nombres no es necesario que el recurso al que apunta una URI exista.
La declaración de un espacio de nombres la realizaremos con el atributo xmlns seguido de dos puntos (:) y el prefijo que vayamos a usar. A este identificador que acabamos de crear le asignaremos una URI.
xmlns:colegio="http://micolegio.es/notas"
Al definir el prefijo hay que tener en cuenta que no se pueden utilizar espacios ni caracteres espaciales y que no puede comenzar por un número.
A la hora de utilizar este prefijo utilizaremos los identificadores anteponiéndoles el nuevo prefijo.
Los espacios de nombres son un concepto que XML comparte con otros lenguajes de programación que le permite ampliar la nomenclatura de sus identificadores y facilitar la importación de recursos ya creados. Fueron una novedad de XML que no estaba presente en SGML. De modo que cuando XML heredó DTD como sistema para declarar sus esquemas y vocabularios, este no estaba preparado para manejar los espacios de nombres. Es decir, como veremos más adelante, DTD no está preparado para declarar adecuadamente los espacios de nombres.
Vamos a unir dos documentos XML que tienen sus respectivos vocabularios ya creados. Veremos que existe un identificador nombre, que se utiliza en ambos contextos y nos va a ocasionar una colisión.
Necesitamos que nuestros documentos XML tengan un formato estándar para facilitar el intercambio de información. Cumpliendo con estos estándares podemos comunicarnos con todos aquellos sistemas que los tengan implementados. Gracias al estándar podemos establecer el formato de los mensajes en nuestro trabajo de desarrolladores del software. Se podrá desarrollar software que intercambie información sin tener que crear un formato de mensajes por cada vía de comunicación que tengamos.
Elaboración propia. Validación en NetBeans(CC BY-NC-SA)
Un documento XML bien formado debe cumplir con todas las normas que establece W3C y que hemos ido viendo en esta unidad. Un resumen podría ser el siguiente:
Si existe declaración XML, esta debe ocupar la primera línea del documento.
La declaración XML debe cumplir con las reglas de versión, codificación y autonomía.
Si existe declaración de tipo de documento, su valor debe ser el mismo que el del identificador del elemento raíz.
Debe existir un único elemento raíz.
Los identificadores de los elementos y de los atributos deben estar bien construidos.
Los elementos deben estar bien estructurados: correctamente anidados y correctamente cerrados.
Los atributos deben estar bien ubicados en su elemento correspondiente, no pueden repetir identificador dentro del mismo elementos, estar separados con espacios y su valor debe escribirse entre comillas simples o dobles.
Los caracteres especiales deben representarse utilizando entidades.
Si existen espacios de nombres, estos se deben declararse correctamente y usarse según sus reglas .
Si un documento XML, además de estar bien formado (estándar XML), cumple con las reglas indicadas en su documento de gramática, será un documento XML válido.
Recordemos que XML es un metalenguaje con el que podemos crear nuestros propios vocabularios. Además, hemos visto cuándo un documento XML estaba bien formado, es decir, que cumplía con el estándar XML. Con eso nos aseguramos que podemos usar librerías XML o procesadores XML y no será necesario implementar nosotros/as mismos/as un software específico para cada vía de comunicación.
Pero qué hay del vocabulario y la sintaxis que hemos creado, cuando queremos implementar un software que envíe o reciba información, necesitamos que los mensajes tengan un formato concreto y que su estructura quede fijada. En un primer momento, tendríamos que desarrollar un software que realizará este trabajo y este software sería distinto para cada vía de comunicación que usásemos.
Elaboración propia. Validación en NetBeans(CC BY-NC-SA)
Para evitar esto existen unos lenguajes que nos permiten declarar las gramáticas (vocabulario y sintaxis) que hemos construido. Estos lenguajes nos ahorran el trabajo de tener que desarrollar un software específico. Tan solo tendremos que indicarle las reglas que queremos que se cumplan en nuestros documentos XML. Un documento de estas reglas gramaticales podrá ser utilizado por todos documentos XML que usemos para una determinada vía de comunicación. Si un documento XML, además de estar bien formado, cumple con las reglas indicadas, será un documento válido.
Estos lenguajes para declarar gramáticas están formados por una relación precisa de qué elementos pueden aparecer en un documento y dónde, así como el contenido y los atributos del mismo. Garantizan que los datos del documento XML cumplen las restricciones que se les haya impuesto.
Cuando trabajamos con XML podemos definir gramáticas (vocabularios y sintaxis) mediante los lenguajes:
DTD, derivado del DTD que se usa para validar documentos SGML.
XML Schema, es un lenguaje con sintaxis XML desarrollado por el W3C.
Relax-NG, es otro lenguaje de esquemas XML más sencillo que el anterior y que, además de la sintaxis XML, dispone de una sintaxis alternativa llamada Compacta.
Schematron, su función es más de validación lógica. Se puede usar para validaciones lógicas que XSD no cubre.
DTD (Document Type Definition)
Qué valida: La estructura y los elementos permitidos de un documento XML.
Cómo se usa: Puedes declarar el DTD internamente en el XML o enlazarlo externamente.
Ventaja: Simple y ampliamente soportado.
Limitación: No soporta tipos de datos complejos ni espacios de nombres (namespaces).
Qué valida: Estructura, tipos de datos, restricciones, y namespaces en los documento XML. Lenguaje: XML Schema Definition (XSD), que es en sí un tipo de XML. Ventaja: Muy poderoso y flexible. Uso común: Validación avanzada de documentos XML.
RELAX NG (Regular Language for XML Next Generation)
Qué valida: Valida estructura como XSD, con una sintaxis más compacta y fácil de leer. Lenguaje: Puede expresarse en XML o en una sintaxis compacta. Ventaja: Más simple que XSD pero muy potente.
Ejemplo de código (formato Compacto):
element alumno {
attribute codigo { text },
element nombre { text },
element apellidos { text },
element anno_nac { xsd:gYear },
element nota_media { xsd:decimal }
}
Qué valida: Su función es más de validación lógica, Permite reglas personalizadas complejas (por ejemplo, relaciones entre elementos). Lenguaje: Usa patrones en XML y expresiones XPath. Ventaja: Se puede usar para validaciones lógicas que XSD no cubre.
Ejemplo de código:
Vamos a validar estas reglas:
Que el atributo codigo exista.
Que anno_nac sea un año válido (mayor a 2000).
Que nota_media esté entre 0.0 y 10.0.
Que nombre no esté vacío.
<sch:schema xmlns:sch="http://purl.oclc.org/dsdl/schematron">
<sch:pattern id="validacion-alumno">
<sch:rule context="alumno">
<sch:assert test="@codigo">
El atributo 'codigo' es obligatorio.
</sch:assert>
<sch:assert test="string-length(normalize-space(nombre)) > 0">
El nombre no debe estar vacío.
</sch:assert>
<sch:assert test="number(anno_nac) > 2000">
El año de nacimiento debe ser mayor a 2000.
</sch:assert>
<sch:assert test="number(nota_media) >= 0 and number(nota_media) <= 10">
La nota media debe estar entre 0 y 10.
</sch:assert>
</sch:rule>
</sch:pattern>
</sch:schema>
Elaboración propia. Editor con documento XML(CC BY-NC-SA)
Para trabajar en XML es necesario editar los documentos y luego procesarlos, por tanto, tenemos dos tipos de herramientas:
Editores XML
Una característica de los lenguajes de marcas es que se basan en la utilización de ficheros de texto plano por lo que basta utilizar un editor de texto para construir un documento XML, es importante que el editor no permita formatear el texto, para que no introduzca "código basura" en nuestro documento.
Para crear documentos XML complejos e ir añadiendo datos es conveniente usar algún software de edición XML. Estos nos ayudan a crear estructuras y etiquetas de los elementos usados en los documentos, colorean las etiquetas para diferenciarlas más cómodamente y además algunos incluyen ayuda para la creación de otros elementos como DTD, hojas de estilo CSS o XSLT, ...
Para interpretar el código XML se puede utilizar cualquier navegador. Los procesadores de XML permiten leer los documentos XML y acceder a su contenido y estructura. Un procesador es un conjunto de módulos de software entre los que se encuentra un parser o analizador de XML que comprueba que el documento cumple las normas establecidas para que pueda abrirse. Estas normas pueden corresponderse con las necesarias para trabajar solo con documentos de tipo válido o solo exigir que el documento esté bien formado, primeros se conocen como validadores y los segundos como no validadores. El modo en que los procesadores deben leer los datos XML está descrito en la recomendación de XML establecida por W3C.
La mayoría de estos procesadores XML se encuentran implementados en librería de lenguajes de programación y son utilizados en el desarrollo de aplicaciones. Algunos ejemplos de estas librerías que implementan procesadores XML son:
Según Juan, el método más sencillo para intentar normalizar los documentos con los que trabajan, consiste en definir unas gramátiacas que han de cumplir los documentos que generan, estos se llaman Definición de Tipo de Documento. Además, aunque no es un lenguaje XML, tiene una sintaxis sencilla y fácil para que ella y Félix puedan comprenderla y utilizarla.
Una Definición de Tipo de Documento o DTD («Document Type Definition») es una descripción de una gramática (vocabulario y sintaxis) con la que podemos validar documentos XML.
Con un DTD podremos establecer las siguientes características en una gramática:
La jerarquía de los elementos.
El orden y cardinalidad de los elementos.
El tipo de contenido permitido para los elementos. Tanto si son elementos padre como elemento terminales.
Los atributos asociados a cada elemento.
Tipos de datos y valores por defectos de los atributos.
Integridad referencial de los tipos de datos ID e IDREF.
Su función es la descripción de la estructura de datos, para usar un diseño común y mantener la consistencia entre documentos XML que utilicen el mismo DTD. De esta forma, dichos documentos XML pueden ser validados.
¿Cuáles son los inconvenientes de los DTD?
No soportan espacios de nombres.
No definen tipos para los datos para los elementos. Solo permite elementos terminales con información textual o vacíos.
Los tipos de datos de los atributos son restringidos, basicamente: texto, lista restringida, identificadores y tokens.
La Declaración de Tipo de Documento se debe realizar entre los corchetes de la expresión:
<!DOCTYPE identificador [ ... ]>
Donde, <span><strong>identificador</strong></span> corresponde con el elemento raíz del documento XML.
Existen dos formas de definir el DTD que describirá la gramática de los documentos XML que usaremos para el intercambio de información. Se puede realizar la definición dentro del documento XML o en un fichero separado. La ubicación de este fichero deberá ser conocida por el documento XML.
DTD interno
Contiene las declaraciones que pertenecen exclusivamente a un documento y no es posible compartirlas. Se localizan dentro de unos corchetes que siguen a la declaración de tipo del documento. En este caso, en la declaración XML habría que indicar que este documento es independiente con el atributo: standalone="yes".
Se puede proporcionar una ayuda extra al analizador de XML, si a través de la declaración de documento XML <?xml ... ?> presente en el prólogo, se indica que el documento es independiente y que todo lo que necesita está contenido en el mismo. Para ello basta con añadir el atributo standalone=”yes”, como puede verse a continuación:
El valor por defecto del atributo standalone es no, es decir, en caso de omitir el atributo es como si se pusiera standalone="no".
DTD Externo
Es posible separar la declaración DTD, guardándola en un fichero diferente. Este fichero suele tener con extensión .dtd y suele situarse en el mismo directorio que el documento XML. Habitualmente son declaraciones que pueden ser compartidas entre múltiples documentos XML que pertenecen al mismo tipo. En este caso, en la declaración XML el atributo de autonomía standalone debe ponerse a no, ya que es necesario el fichero externo para la correcta interpretación del documento. En este caso, en la declaración XML se podría indicar que este documento es independiente con el atributo: standalone="no". Pero como es el valor por defecto de dicho atributo, no es necesario.
Con ello el procesado del documento será más lento, puesto que antes de procesar el documento el procesador ha de obtener todas las entidades. Ahora los corchetes pierden sentido, para localizar las declaraciones DTD.
Siguiendo con el anterior ejemplo de película, podemos separar la declaración DTD en un primer archivo que llamaremos pelicula.dtd y contendrá el contenido de los corchetes:
<!ELEMENT pelicula (titulo)>
<!ELEMENT titulo (#PCDATA)>
El documento XML ahora tendrá el contenido siguiente. En donde le indicamos que el archivo pelicula.dtd se encuentra en la ruta indicada después de la instrucción SYSTEM. Como hemos indicado anteriormente, no es necesario indicar en la declaración XML el atributo, standalone="no", ya que es el valor que toma por defecto:
Cabe una posibilidad híbrida de uso cuando utilizamos un documento DTD externo y a la vez añadimos ciertas declaraciones DTD de forma interna. En este caso el atributo standalone debería tener el valor no, porque, aunque se tengan declaraciones internas, se necesitará de ficheros externos para completar las declaraciones DTD. Al ser su valor por defecto no hace falta indicarlo.
Un ejemplo podría ser los siguientes documentos.
Documento DTD con algunas declaraciones externas:
<!ELEMENT pelicula (titulo)>
Documento XML con algunas declaraciones internas:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE pelicula SYSTEM "pelicula.dtd" [
<!ELEMENT titulo (#PCDATA)>
] >
<pelicula>
<titulo>Titanic</titulo>
</pelicula>
Las ventajas de incluir una DTD externa son las siguientes:
Si la DTD que se va a incluir es compartida por muchos documentos XML, es preferible que se encuentre en un archivo independiente, ya que si hay que hacer algún cambio en la DTD, solo tendrá que hacerse en un archivo y no en cada XML en el caso de tener una DTD incrustada en el mismo documento XML.
La DTD puede ubicarse en un servidor web, de forma que cualquier persona con acceso a Internet puede validar el documento XML que está creando, lo que garantiza que todos los documentos XML usan la última versión de la DTD. Para declarar que nuestra DTD está en un servidor de Internet basta con especificarlo en el DOCTYPE de la siguiente forma:
DTD externo privado
<!DOCTYPE pelicula SYSTEM "http://cine.org/pelicula.dtd">
DTD externo público
También cabe la posibilidad de publicar la declaración DTD para un uso abierto. Esto puede ser útil para dar a conocer a nuestros clientes o proveedores el formato con el que se pueden comunicar con nuestros sistemas.
<!DOCTYPE pelicula PUBLIC "filmoteca" "http://cine.org/pelicula.dtd">
Siendo filmoteca el identificador público del DTD.
Los documentos XML se representan en forma de árboles con el nodo raíz como elemento inicial. En esta estructuras en forma de árbol podemos clasificar a los elementos en: elementos padres y elementos terminales. Tanto unos como los otros pueden tener atributos.
Los tipos de elementos terminales son aquellos elementos que se corresponden con hojas de la estructura de árbol. Estos elementos terminales pueden contener texto o estar vacíos. Pero no pueden continuar la jerarquía con otros elementos hijos.
Estos elementos terminales los declararemos de la siguiente forma:
<!ELEMENT identificado contenido>
El <strong>identificador</strong> será el nombre que tiene dicho elemento.
El <strong>contenido</strong> será el tipo de contenido que puede tener dicho elemento. Los posibles valores son:
(#PCDATA): Valores alfanuméricos. Puede ser vacío. Los paréntesis son obligatorios. PCDATA (Parser Character Data), indica que los datos son analizados en busca de etiquetas para comprobar que el elemento no contiene elementos hijos, es decir, solo puede contener datos de tipo alfanuméricos. No puede contener los símbolos: (<), ([), (&), (]), (>).
<!ELEMENT nombre (#PCDATA)>
Esta regla DTD validaría el siguiente código XML como correcto, ya que contiene texto o texto de tamaño cero.
<nombre />
<nombre>Paco</nombre>
EMPTY: Indica que el elemento debe ser obligatoriamente vacío, es decir, que no puede tener contenido de ningún tipo.
<!ELEMENT nombre EMPTY>
Esta regla DTD validaría el siguiente código XML como correcto, porque los elementos están vacíos.
<nombre></nombre>
<nombre />
ANY: Permite que el contenido del elemento sea cualquier cosa (texto y/o otros elementos). No es recomendable usar este tipo de elemento porque genera contenido mixto. Común en archivos orientados a documento, pero de difícil manejo en documento para el intercambio de información.
Esta regla DTD validaría los siguientes códigos XML como correctos, porque el elemento puede contener texto u otros elementos, en cualquier orden y cantidad.
<alumno>
<nombre>Paco</nombre> es un alumno de <curso>1 DAW</curso>.
</alumno>
El <strong>identificador</strong> será el nombre que tiene dicho elemento padre.
En <strong>secuencia_hijos_con_sus_cardinalidades</strong> se deberá declarar la estructura de hijos que tiene dicho elemento padre.
Secuencias
(,) Operador secuencia ordenada: (A, B, C): Indica que los elementos siguen el orden estricto indicado.
Por ejemplo: En este caso se ha definido un elemento agenda que está formado por un elemento nombre seguido de un elemento teléfono y por último un elemento direccion.
<!ELEMENT agenda (nombre, telefono, direccion)>
<!-- VÁLIDO -->
<agenda>
<nombre>Paco</nombre>
<telefono>950102030</telefono>
<direccion>Calle Mayor, 1</direccion>
</agenda>
<!-- INCORRECTO: No mantienen el orden estricto -->
<agenda>
<nombre>Paco</nombre>
<direccion>Calle Mayor, 1</direccion>
<telefono>950102030</telefono>
</agenda>
(|) Operador elección (A | B | C): Indica que hay que elegir un único elemento de entre todos los elementos separados por este operador. Si queremos mezclar el operar de secuencia ordenada y el de elección, este último debe ir entre paréntesis.
En el ejemplo siguiente, el documento XML tendrá un elemento cliente que estarán formados por un elemento nombre seguido por un elemento DNI o CIF, pero no los dos a la vez:
<!ELEMENT cliente (nombre, (DNI | CIF) )>
<!-- VÁLIDO -->
<cliente>
<nombre>Paco</nombre>
<dni>10203040-A</dni>
</cliente>
<!-- VÁLIDO -->
<cliente>
<nombre>Paco</nombre>
<cif>A-10203040</cif>
</cliente>
<!-- INCORRECTO: No hay opción, aparecen los dos -->
<cliente>
<nombre>Paco</nombre>
<dni>10203040-A</dni>
<cif>A-10203040</cif>
</cliente>
<!-- INCORRECTO: No hay opción, no aparece ninguno -->
<cliente>
<nombre>Paco</nombre>
</cliente>
Cardinalidad
(?) Operador opción (0-1): Indica que el elemento no es obligatorio. Su cardinalidad es cero o uno.
En el siguiente ejemplo el elemento dirección es opcional, puede aparecer o no.
(+) Operador (1-N) uno-o-más: Indica que el elemento debe aparecer una o muchas veces. Si se repite el elemento, los elementos deberán aparecer seguidos.
En el siguiente ejemplo el elemento teléfono puede aparecer una o muchas veces, pero al menos una:
(*) Operador (0-N) cero-o-más: Indica que el elemento puede no aparecer cero, aparecer una vez o muchas veces. Si se repite el elemento, los elementos deberán aparecer seguidos.
En el siguiente ejemplo el elemento teléfono puede no aparecer, aparecer una sola vez o muchas veces:
Estos elementos mixtos pueden contener texto, elementos en cualquier orden y cantidad. Por lo que en la declaración debemos poner siempre #PCDATA como primer elemento de la lista estricta de restricciones y posteriormente todos los elementos que podría contener separados con la barra (|) de opcionalidad. Importante también incluir un asterisco como cardinalidad cero o muchos para que podamos utilizar cualquier texto o elementos cero o muchas veces.
Como se comentó el contenido ANY ya se indicó que no es recomendable utilizar contenido mixto en documentos XML orientados al intercambio de información, ya que, generarían estructuras heterogéneas difíciles de manipular.
elemento: serán el identificador del elemento al que pertenece el atributo que estamos declarando.
identificador: será el nombre con el que queremos declarar al atributo.
tipo_atributo: indicaremos el tipo de dato que usará el atributo. No son los típicos tipos de datos de los lenguajes de programación. Son tipos de datos más restringidos.
modificador_atributo: indica una característica del atributo.
Estos cuatro parámetros son obligatorios. Si queremos declarar más de un atributo en un mismo elemento, podemos declararlos seguidos e indicando el identificador del elemento solo la primera vez. También cabe la posibilidad de declarar los atributos por separado. Si un elemento tiene más de un atributo, se pueden expresar en forma de lista de atributos:
Al igual que los elementos, no todos los atributos son del mismo tipo, los más destacados son:
Enumeración, es una lista de valores estrictamente definidos. El atributo solo puede tomar uno de los valores de los listados dentro del paréntesis y separados por el operador barra (|). Los valores de la lista no pueden tener espacios en blanco. Tampoco hay que delimitarlos con comillas.
Ejemplo (Para probar los ejemplos, dejar solo un elemento raíz y comentar el resto):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fecha [
<!ELEMENT fecha (#PCDATA)>
<!ATTLIST fecha dia_semana (lunes|martes|miércoles|jueves|viernes|sábado|domingo) #REQUIRED>
]>
<!-- VÁLIDO -->
<fecha dia_semana="viernes" >10-10-2010</fecha>
<!-- INCORRECTO: Sensible a mayúsculas -->
<fecha dia_semana="Viernes" >10-10-2010</fecha>
<!-- INCORRECTO: No está en al lista -->
<fecha dia_semana="finde" >10-10-2010</fecha>
CDATA, (Character Data): se utiliza cuando el valor de un atributo son caracteres alfanuméricos, es decir: letras, números, espacios en blanco y símbolos. Puede ser vacío.
Ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE fecha [
<!ELEMENT fecha (#PCDATA)>
<!ATTLIST fecha dia_semana (CDATA) #REQUIRED>
]>
<!-- VÁLIDO -->
<fecha dia_semana="viernes">10-10-2010</fecha>
<!-- VÁLIDO -->
<fecha dia_semana="fin de semana">10-10-2010</fecha>
<!-- VÁLIDO -->
<fecha dia_semana="">10-10-2010</fecha>
ID, permite declarar el valor del atributo como un identificador único. El identificador del atributo puede repetirse en el documento XML, pero su valor no. Es decir, se comprobará que el valor que se utiliza es único en todos los atributos del mismo tipo (ID) en el documento. El valor que le podemos asignar no puede empezar por un número, ni contener caracteres especiales distintos a (:), (_), (-) , (.) . Tampoco pueden contener espacios en blanco. En caso de querer usar una numeración debemos añadirle al menos una letra al inicio de estos números. Este tipo de dato solo puede tener los modificadores: #IMPLIED y #REQUIRED.
Ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE alumno [
<!ELEMENT alumno EMPTY>
<!ATTLIST alumno codigo ID #IMPLIED>
]>
<!-- VÁLIDO -->
<alumno codigo="A2001"></alumno>
<!-- INCORRECTO: Comienza por núḿero -->
<alumno codigo="2001"></alumno>
<!-- INCORRECTO: Tiene espacios en blanco -->
<alumno codigo="A 2001"></alumno>
IDREF, permite hacer referencia a un identificador de tipo ID. En este caso, el valor del atributo ha de corresponder con el de un identificador de un elemento existente en el documento. Es decir, se comprueba que el valor al que referencia esté declarado en el documento.
IDREFS, permite hacer referencias a identificadores de tipo ID. Pueden ser varios separados por espacios en blanco. Por ello, los atributos de tipo ID no pueden contener espacios en blanco. El valor del atributo deberá ser la lista de identificadores que queramos referenciar. Todos estos identificadores deben estar declarados en el documento.
NMTOKEN, permite declarar el valor del atributo como un identificador no único, es decir, un identificador que se puede repetir. Normalmente, se utiliza con características que pueden categorizar a los elementos como: nivel, ubicación, tipo, color, etc. El valor que le podemos asignar puede contener números, letras y los caracteres (:), (_), (-) , (.) . Caracteres como *, $, %, &, ?, @, ... no serán válidos. No pueden contener espacios en blanco.
Ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE alumno [
<!ELEMENT alumno EMPTY>
<!ATTLIST alumno nivel NMTOKEN #IMPLIED>
]>
<!-- VÁLIDO -->
<alumno nivel="1ESO"></alumno>
<!-- INCORRECTO: Tiene espacios en blanco -->
<alumno nivel="1 ESO"></alumno>
NMTOKENS, Permite una lista de identificadores no únicos. Sigue las reglas del tipo de dato NMTOKEN. La lista se valores debes separarse con espacios en blanco.
Ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE alumno [
<!ELEMENT alumno EMPTY>
<!ATTLIST alumno matricula NMTOKENS #IMPLIED>
]>
<!-- VÁLIDO -->
<alumno matricula="Matemáticas Fisica_Química"></alumno>
<!-- INCORRECTO: No puede ser vacía -->
<alumno matricula=""></alumno>
<!-- INCORRECTO: Tiene caracteres no permitidos -->
<alumno nivel="Matemáticas Fisica&Química"></alumno>
Modificadores de los atributos
#IMPLIED, determina que el atributo es opcional. Es decir, el atributo puedo aparecer o no aparecer en el elemento.
#FIXED "valor", permite definir un valor fijo para un atributo. No se podrá modificar dicho atributo.
Ejemplo:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE alumno [
<!ELEMENT alumno (#PCDATA)>
<!ATTLIST alumno nacionalidad NMTOKEN #FIXED "Española">
]>
<!-- VÁLIDO -->
<alumno nacionalidad="Española">Ana</alumno>
<!-- VÁLIDO -->
<alumno>Ana</alumno>
<!-- INCORRECTO: No se puede cambiar es fija -->
<alumno nacionalidad="Portuguesa">Ana</alumno>
Valor por defecto "valor": asigna un valor por defecto a un atributo. El atributo tendrá ese valor a no ser que en el documento se le asigne otro valor diferente. El atributo se considera como opcional y puede no aparecer.
Cuando se incluyen ficheros binarios en un fichero, ¿cómo le decimos qué aplicación ha de hacerse cargo de ellos? La respuesta es utilizando notaciones, estas se usan para definir formatos distintos al XML.
Con las notaciones podemos especificar el formato de entidades externas que no pueden ser analizadas por un procesador XML. Habitualmente, las notaciones se utilizan para ficheros binarios, pero también se pueden utilizar para ficheros de texto. Las notaciones pueden ser públicas o privadas, dependiendo si las queremos compartir o no. La sintaxis para declarar notaciones es:
<!-- Notación privada -->
<!NOTATION identificador SYSTEM "identificador-aplicación" >
<!-- Notación pública -->
<!NOTATION identificador PUBLIC "identificador_público" "identificador_aplicación">
identificador: nombre de la notación que estamos declarando.
identificador_público: denominación de la URI que puede ser compartida.
identificador_aplicación: es el identificador del programa encargado de procesar el tipo de fichero. El identificador de aplicación suele ser el tipo MIME asociado a ese formato.
Por ejemplo, una notación llamada gif donde se indica que se hace referencia al formato de los archivos .gif para que nuestro sistema operativo lo maneje.
<!-- Notación privada -->
<!NOTATION gif SYSTEM "image/gif">
<!-- Notación público -->
<!NOTATION gif SYSTEM "GIF 1.0" "image/gif">
Este ejemplo tenemos dos notaciones, una privada para los archivos de extensión .gif y otra pública para los archivos .jpg. Tras las declaraciones de estas notaciones las usamos en un atributo. Cuando utilizamos notaciones en un atributo debemos indicar la palabra NOTATION y posteriormente un enumerado indicando la lista estricta de notaciones que permitiremos.
Las entidades nos permiten definir constantes en un documento XML. Cuando se usan dentro del documento XML se delimitan entre "&" y ";", por ejemplo <strong>></strong>. Al procesar el documento XML, el intérprete sustituye la entidad por el valor que se le ha asociado en el DTD. No admiten recursividad, es decir, una entidad no puede hacer referencia a ella misma.
Las entidades se clasifican en los siguientes subgrupos:
Generales
Internas
Predefinidas
Declaradas por el usuario
Externas
Privadas
Públicas
Paramétricas
Internas
Externas
Privadas
Públicas
Generales internas:
Predefinidas en XML: Son las entidades declaradas en el lenguaje XML que utilizan para evitar que el procesador del lenguaje no procese etiquetas, entidades o valores de atributos erróneamente. Existen cinco entidades predefinidas:
Entidad
Representación
<
Signo menor que, <
>
Signo mayor que, >
"
Comillas dobles, ''
'
Apóstrofe o comilla simple, '
&
Et o ampersand, &
Declaradas por el usuario: Podemos definir nuestras propias entidades usando la estructura:
<!ENTITY identificador "valor_entidad">
identificador es el nombre que recibe la entidad.
"valor_entidad" es el valor que toma dicha entidad.
Como con las entidades internas predefinidas, hacemos referencia a ellas con &identificador;
Ejemplo:
<!ENTITY LMSGI "Lenguajes de marcas y sistemas de gestión de información">
<!-- USO -->
<modulo>&LMSGI;</modulo>
Generales Externas Privadas
Permiten establecer una relación entre un documento XML y el contenido de otro documento a través de una URI.
Se declaran de la siguiente forma:
<!ENTITY identificador SYSTEM "URI">
Ejemplo:
Si tenemos un archivo con el siguiente contenido:
<nombre>Ana</nombre>
<apellidos>Amate</apellidos>
Lo podemos utilizar en nuestro documento XML con:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE alumno [
<!ENTITY DATOS SYSTEM "entidades_datos_alumno.xml">
<!ELEMENT alumno (nombre, apellidos)>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT apellidos (#PCDATA)>
]>
<alumno>&DATOS;</alumno>
Generales Externas Públicas
Permiten establecer una relación entre un documento XML y el contenido de otro documento a través de una URI pública.
La declaración de una entidad externa pública se declara:
<!ENTITY identificador PUBLIC "identificador_público" "URI">
Los valores son iguales a los anteriores, solo se añade PUBLIC y un identificador público para denominar a esa URI que puede ser compartida.
Generales Externas no procesables (públicas o privadas)
En las notaciones externas, el contenido de los ficheros es analizado por los procesadores XML, por lo que deben seguir la sintaxis XML. Cuando es necesario incluir ficheros con formatos binarios, es decir, ficheros que no se analicen, se utiliza la palabra reservada NDATA en la definición de la entidad y habrá que asociar a dicha entidad una notación.
<!-- Privado -->
<!ENTITY identificador SYSTEM "URL" NDATA tipo>
<!-- Público -->
<!ENTITY identificador PUBLIC "identificador_público" "URL" NDATA tipo>
Dentro de las entidades generales, tenemos entidades procesables y no procesables.
Generales
Externas
Procesables
No procesables
Las procesables son todas aquellas que estén escritas en texto plano y se pueden incorporar al documento directamente.
Las entidades no procesables serán entidades externas (públicas o privadas) que no estén escritas en texto plano y no puedan ser procesadas en XML.
El ejemplo típico de estas entidades son aquellas que hacen referencias a archivos binarios de imágenes con formatos: jpg, gif, png, etc.
Continuamos con el ejemplo que vimos en el apartado de notaciones y le añadimos el archivo de la imagen en el atributo fotografía.
Deberemos crear una entidad por cada acceso a archivo externo que necesitemos. Como el archivo que queremos usar es de formato .jpg no lo podemos procesar de modo que lo indicamos con NDATA y con el identificador de notación que le corresponda a ese tipo de archivo jpg. También necesitamos la declaración de la entidad correspondiente al los archivos jpg. El atributo formato_fotografía no sería necesario, pero ya que lo elaboramos en el ejemplo anterior lo mantendremos.
Paramétricas Internas
Permiten dar nombres a bloques de código DTD y hacer referencia a ellas a lo largo del mismo. Son especialmente útiles cuando varios elementos del DTD comparten listas de atributos o especificaciones de contenidos. Se denotan con:
Permiten incluir o ignorar partes de la declaración de un DTD. Para ello se usan las instrucciones INCLUDE e IGNORE:
INCLUDE, permite que se vea esa parte de la declaración del DTD. Su sintaxis es:
<![INCLUDE [Declaraciones visibles]]>
Por ejemplo:
<![INCLUDE [<!ELEMENT nombre (#PCDATA)>]]>
IGNORE, permite ocultar esa sección de declaraciones dentro del DTD. La forma de uso es:
<![IGNORE [Declaraciones ocultas]]>
Por ejemplo:
<![IGNORE [<!ELEMENT clave (#PCDATA)>]]>
El uso de las secciones condicionales suele estar ligado a entidades paramétricas.
También llamado componente léxico es una cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación. Ejemplos de tókenes podrían ser palabras clave (if, else, while, int, ...), identificadores, números, signos, o un operador de varios caracteres, (por ejemplo, := "':+"' ).
Félix, quien considera que la normalización de los documentos XML que manejan en la empresa va a ser un duro trabajo para María, él y otros trabajadores inexpertos, plantea la posibilidad de que se encargue de ello algún trabajador de la consultoría informática que dirige Juan.
Al final se va a encargar de ello Marina. Les explica que, en lugar de trabajar con DTD le parece mejor hacerlo con un lenguaje XML llamado XML Schema, el cual tiene, entre otras, la ventaja de permitir definir el tipo de datos de cada uno de los componentes de cada documento.
Los DTD permiten diseñar un vocabulario para ficheros XML, pero, ¿qué sucede cuando los valores de los elementos y atributos de esos ficheros han de corresponder a datos de un tipo determinado, o cumplir determinadas restricciones que no pueden reflejarse en los DTD? Para ello se definen XML Schemas, que se componen de elementos y atributos, al igual que los DTD.
¿También se definen en ficheros planos? Sí, ya que son documentos XML, pero en este caso la extensión de los archivos es .xsd, motivo por el cual también se les denomina documentos XML Schema Definition.
Declaración de esquemas
Los elementos y atributos XML que se utilizan para generar esquemas pertenecen al espacio de nombres XML Schema, con el URI: http://www.w3.org/2001/XMLSchema.
En este vocabulario se usa el prefijo <strong><xs:xxxxx></strong>, aunque también se usa <strong><xsd:xxxxx></strong> con menos frecuencia. En la práctica, cualquier prefijo puede ser usado, siempre que se use el mismo prefijo en todo el documento.
Por ejemplo: <strong><xs:element>, <xs:complexType>, <xs:string></strong>. Tenga cuidado en el protocolo, es http y no https.
Un esquema XML Schema tiene como elemento raíz, el elemento <b><xs:schema></b>. Este elemento contendrá las declaraciones de todos los elementos y atributos que puedan aparecer en un documento XML asociado. Este elemento tendrá un elemento hijo que será el elemento raíz del documento XML, que declararemos con <b><xs:element></b>.
La declaración de un esquema <b><xs:schema></b> suele tener el siguiente aspecto:
En el anterior fragmento: <code>xmlns:xs="http://www.w3.org/2001/XMLSchema" indica que los elementos y tipos de datos usados en el esquema vienen del espacio de nombres "http://www.w3.org/2001/XMLSchema. También especifica que los elementos y los tipos de datos que provengan de dicho espacio de nombres deben tener el prefijo <strong><xs:xxxx></strong>.
Una vez que tenemos creado un documento XML Schema, ¿cómo lo asociamos a un fichero XML?
El modo de asociar un esquema a un documento XML es con el vocabulario asociado al espacio de nombres de XML Schema Instancia: http://www.w3.org/2001/XMLSchema-instance.
Para que un documento XML siga las reglas definidas en un esquema, no disponemos de etiqueta <!DOCTYPE xxxxx > como en los documentos DTD, en su lugar, en el elemento raíz del documento XML utilizamos los atributos: xsi:schemaLocation o xsi:noNamespaceSchemaLocation. Estos atributos nos sirven para indicar la ubicación de nuestros esquemas con las reglas de validación.
Uso del atributo noNamespaceSchemaLocation
Ejemplo de documento .xml para xsi:noNamespaceSchemaLocation:
En este caso en el documento esquema.xsd al indicar un espacio de nombres (xmlns="http://www.educacion.es/doc") el documento XML también se deberá indicar ese mismo espacio de nombres en el atributo targetNamespace del elemento raíz del esquema XML.
Un documento XML asociado al esquema que se ha realizado anteriormente para estructurar la información personal sobre los alumnos de un centro educativo (apartado 3.1) puede ser:
Un elemento se utiliza para describir datos. Todos los elementos que se vayan a utilizar en el documento XML tienen que estar declarados en el esquema correspondiente. La declaración de elementos se realiza mediantes la sintaxis:
ref: el elemento al que hace referencia está declarado en otro lugar del esquema. No puede aparecer junto con "name" y ni si el elemento padre es
type: el tipo de dato del elemento. No puede aparecer si se usa ref.
minOccurs y maxOccurs (Opcionales): estos dos atributos indican el mínimo (minOccurs) y máximo (maxOccurs) número de ocurrencias del elemento. El valor por defecto en ambos casos es 1. Para indicar que el elemento puede aparecer un número ilimitado de veces, el atributo maxOccurs toma el valor “unbounded”. Para indicar que un elemento puede no aparecer, el atributo minOccurs toma el valor 0. Ninguno de los atributos se puede usar si el elemento padre es .
fixed: especifica un valor fijo para el elemento.
default: especifica un valor por defecto para el elemento.
Las declaraciones de elementos en XML Schema tienen una estructura diferente dependiendo de lo que se quiera representas:
Elementos terminales sin atributos
Sin restricciones.
No pueden contener otros elementos ni atributos solo contenido. El tipo de dato del elemento puede indicarse directamente con el atributo type o mediante una estructura xs:simpleType.
Esta estructura se utiliza si queremos declarar un elemento terminal sin atributos pero con alguna restricción en este tipo de dato. Para ello crearemos una estructura xs:simpleType - xs:restriction e indicaremos el tipo de dato base en el atributo del mismo nombre. Dentro de esta estructura vendrían las restricciones propiamente dichas que veremos más adelante. Dependiendo del tipo de dato del atributo base se podrán utilizar unas restricciones u otras, ya que por ejemplo las restricciones sobre texto no funcionan para contenido numérico. No podemos declarar el tipo de dato mediante type y xs:simpleType a la vez. En este caso no usamos el atributo type.
Pueden estar compuestos por otros elementos. Su contenido está definido entre las etiquetas de inicio y de cierre del elemento. Para ello se utiliza una estructura xs:complexType entre sus etiquetas de inicio y cierre se definen los elementos de tipo complejo. Estos elementos padres pueden tener las siguientes estructuras para contener a sus elementos hijos:
Secuencias ordenada (xs:sequence)
Permite mantener los elementos hijos ordenados de forma estricta. En orden en el que aparecen en la declaración será el orden estricto en el que deben aparecer. Si se altera dicho orden en el documento XML, el documento no será válido. Por ejemplo
Representa alternativas, hay que tener en cuenta que es una o-exclusiva. Especifica una lista concreta de elementos de los que solo puede aparecer uno.
Declara una lista de elementos que pueden aparecer en cualquier orden. Es decir, deben aparecer todos los elementos listados en el elemento xs:choice pero en cualquier orden. Normalmente, a los elementos declarados en esta agrupación se le suele acompañar de cardinalidad para poder hacer que sean opcionales o que se puedan repetir.
Definido dando valor true al atributo mixed del elemento <xs:complexType mixed="true">. Permite mezclar texto y elementos hijos. Los elementos hijos se definen con las opciones anteriores; xs:sequence, xs:choice o xs:all.
No debemos utilizar contenido mixto en los documentos XML orientados al intercambio de información, ya que dificultan el tratamiento de esta.
Elementos padre con atributos
Se verá en el siguiente apartado sobre atributos.
Elementos vacíos
No hay una estructura específica para los elementos vacíos. Bastará con no indicar el tipo de dato específico (xs:string, xs:integer, xs:decimal, ...) o una estructura de elementos no terminales (xs:sequence, xs:choice, xs:all). Debe recordarse que un elemento vacío sí puede contener atributos.
<xs:element name="asignatura">
<xs:complexType>
<!-- No debe incluirse la estructura <xs:simpleContent> <xs:extension base="xxxx"> -->
<xs:attribute name='codigo' type='xs:string'/>
</xs:complexType>
</xs:element>
Referencias a otros elementos
Tal y como ocurre en otros lenguajes, en un documento XML Schema podemos definir elementos de forma global y luego hacer referencias a ellos desde otros elementos mediante el atributo ref. Esto es muy útil si a lo largo de un documento se repiten determinados elementos, atributos o tipos de datos.
ref: el atributo referenciado se encuentra definido en otra parte del esquema. No puede aparecer al mismo tiempo que name.
type: tipo de dato del atributo, por ejemplo: xs:string, xs:decimal,... No puede aparecer al mismo tiempo que ref.
use : indica si la aparición del atributo es opcional (optional), obligatoria (required) o prohibida (prohibited). Por defecto toma el valor "optional".
default : valor que tomará el atributo al ser procesado si en el documento XML no hay ningún valor. Solo se puede usar con tipos de datos, cadena de caracteres. No puede aparecer al mismo tiempo que fixed.
fixed (opcional): valor fijo que toma el atributo. No puede aparecer al mismo tiempo que default.
Los atributos solo pueden aparecer en los elementos de tipo compuesto.
Atributos en elementos terminales
Si el atributo lo queremos declarar en un elemento terminal debemos crear una estructura xs:complexType, xs:simpleContent, xs:extension con su atributo xs:base. Por ejemplo:
Si el atributo lo queremos declarar en un elemento padre, el atributo irá después de cerrar la estructura xs:sequence, xs:choice o xs:all y antes de cerrar el elemento xs:complexType. Por ejemplo:
Son los distintos valores que puede tomar el atributo xs:type cuando se declara un elemento o un atributo y representan el tipo de dato que tendrá el elemento o atributo asociado a ese type en el documento XML.
Algunos de estos valores predefinidos son:
xs:string, se corresponde con una cadena de caracteres UNICODE. Puede contener caracteres, saltos de línea y tabulaciones.
XSD:
<xs:element name="poblacion" type="xs:string"/>
XML válido:
<poblacion>Aguadulce</poblacion>
xs:boolean, representa valores lógicos, es decir que solo pueden tomar dos valores, true o false.
XSD:
<xs:attibute name="cancelado" type="xs:boolean"/>
XML válido:
<vuelo cancelado="true">LK345</vuelo>
xs:integer, número entero positivo o negativo.
XSD:
<xs:element name="precio" type="xs:integer"/>
XML válido:
<precio>94</precio>
xs:positiveInteger, número entero positivo.
xs:negativeInteger, número entero negativo.
xs:decimal, número decimal, por ejemplo, 8,97.
XSD:
<xs:element name="precio" type="xs:decimal"/>
XML válido:
<precio>8,97</precio>
<precio>8</precio>
xs:dateTime, representa una fecha y hora absolutas. Tiene el siguiente formato: "YYYY-MM-DDThh:mm:ss. Sólo es válido si se especifican todos los componentes.
xs:duration, representa una duración de tiempo expresado en años, meses, días, horas, minutos segundos. El formato utilizado es: PnYnMnDTnHnMnS. Para indicar una duración negativa se pone un signo – precediendo a la P.
XSD:
<xs:element name="periodo" type="xs:duration"/>
XML válido:
<!-- Duración de 2 años, 4 meses, 3 días, 5 horas, 6 minutos y 7 segundos -->
<periodo>P2Y4M3DT5H6M7S</periodo>
<!-- Se pueden omitir los valores nulos, luego una duración de 2 años será -->
<periodo>P2Y</periodo>
<!-- Un ejemplo de duración negativa sería -->
<periodo>-P2D</periodo> indica un periodo de menos de dos días.
xs:time, hora en el formato hh:mm:ss.
xs:date, fecha en formato CCYY-MM-DD.
xs:gYearMonth, representa un mes de un año determinado mediante el formato CCYY-MM.
XSD:
<xs:element name="fecha" type="xs:gYearMonth"/>
XML válido:
<!-- Mayo de 2020--->
<fecha>2020-05-20T08:20:00</fecha>
XML NO válidos:
<!-- El año no puede dividirse -->
<fecha>20-05</fecha>
<!-- El mes es requerido -->
<fecha>2020</fecha>
<strong></strong>
xs:gYear, indica un año gregoriano, el formato usado es CCYY.
xs:gMothDay, representa un día de un mes mediante el formato -–MM-DD.
XSD:
<xs:element name="fecha" type="xs:gMonthDay"/>
XML válido:
<!-- 19 de Mayo -->
<fecha>--05-19</fecha>
XML NO válidos:
<!-- Los guiones delante del mes son obligatorios -->
<fecha>05-19</fecha>
<!-- Debe ser un día válido. No existe en 32 de mayo -->
<fecha>--05-32<fecha>
xs:gDay, indica el ordinal del día del mes mediante el formato - -DD, es decir el 4º día del mes será - -04.
xs:gMonth, representa el mes mediante el formato - -MM. Por ejemplo, febrero es - -02.
¿Cuáles son las restricciones que podemos aplicar sobre los valores de los datos de un elemento o atributo? Están definidas por las facetas o restricciones, que solo pueden aplicarse sobre tipos simples utilizando el elemento xs:restriction, que tiene como atributo "base" en el que se indica el tipo de dato a partir del cual se define la restricción.
Dentro de una elemento xs:restriction podemos añadir uno o varios de los elementos que veremos a continuación, siempre dependiendo del tipo de dato del atributo xs:base.
Restricción de cadenas de caracteres
enumeration: Restringe a un determinado conjunto de valores.
(max/min)(In/Ex)clusive: Límites superiores/inferiores del tipo de datos. Cuando son Inclusive el valor que se determine es parte del conjunto de valores válidos para el dato, mientras que cuando se utiliza Exclusive, el valor dado no pertenece al conjunto de valores válidos.
totalDigits, fractionDigits: número de dígitos totales y decimales de un número decimal.
pattern: Permite construir máscaras que han de cumplir los datos de un elemento. La siguiente tabla muestra algunos de los caracteres que tienen un significado especial para la generación de las máscaras.
Elementos para hacer patrones.
Patrón
Significado
[A-Z a-z]
Letra.
[A-Z]
Letra mayúscula.
[a-z]
Letra minúscula.
[0-9]
Dígitos decimales.
\D
Cualquier carácter excepto un dígito decimal.
(A)
Cadena que coincide con A.
A | B
Cadena que es igual a la cadena A o a la B.
Elementos para hacer patrones.
Patrón
Significado
AB
Cadena que es la concatenación de las cadenas A y B.
A?
Cero o una vez la cadena A.
A+
Una o más veces la cadena A.
A*
Cero o más veces la cadena A.
[abcd]
Alguno de los caracteres que están entre corchetes.
Elaboración propia. Víctor Gómez. Elementos simples y compuestos(CC BY-NC-ND)
En ocasiones necesitamos restringir los tipos de datos y en otras requerimos extender los tipos de datos para que se ajusten a nuestras necesidades. En este apartado vamos a indicar las dos diferentes maneras que existen de extender un tipo de datos simple:
Union. Consiste en combinar dos o más tipos de datos diferentes en uno único.
Lista. Permite crear una lista de valores de un tipo simple determinado. Este tipo puede ser directo como xs:string o xs:int o definido por nosotros. La lista se separa por espacios en blanco. El elemento xs:list creado podrá tomar la posición de un tipo de dato simple. Puede ser útil para crear una especie de xs:sequence pero para tipos de datos simples.
Una vez que hemos visto como crear un esquema XML vamos a ver el modo de incorporar cierta documentación (quién es el autor, limitaciones de derechos de autor, utilidad del esquema, etc.) al mismo.
Podemos pensar que un método para añadir esta información es utilizar comentarios <!-- -->. El problema es que los analizadores no garantizan que los comentarios no se modifiquen al procesar los documentos y por tanto, que los datos añadidos no se pierdan en algún proceso de transformación del documento.
En lugar de usar los comentarios <!-- -->, XML Schema tiene definido un elemento xs:annotation que permite guardar información adicional. Este elemento a su vez puede contener una combinación de otros dos que son:
xs:documentation, además de contener elementos del esquema XML puede contener elementos XML bien estructurados. También permite determinar el idioma del documento mediante el atributo xml:lang.
xs:appinfo, se diferencia muy poco del elemento anterior, aunque lo que se pretendió inicialmente era que xs:documentation fuese legible para los usuarios y que xs:appinfo guardase información para los programas de software. También es usado para generar una ayuda contextual para cada elemento declarado en el esquema.
La empresa Reggio tiene establecimientos por toda Italia, pero su sede central está en Cesena, al igual que el almacén donde se distribuye a todos los demás establecimientos.
Cada establecimiento tiene una tienda, así como un almacén, que pueden o no estar en la misma ubicación. Cuando se hace un pedido a la fábrica por parte de los establecimientos, estas reciben los artículos en su almacén, y la documentación (albarán y pago) se remite a la tienda.
Cada pedido debe tener los datos siguientes:
Datos del establecimiento que realiza el pedido (Nombre, dirección para envío y dirección almacén (si es la misma, solo aparecerá una).
Código de pedido (Cadena de caracteres formada por: Código establecimiento (1 letra y 2 números), número pedido (4 números), un guion y Año (dos números), por ejemplo: E180021-17
Nombre del empleado que realiza el pedido.
Fecha de pedido.
Tipo de envío (cuyos valores son: Normal o Urgente)
Respecto a los artículos del pedido, se guardarán los siguientes datos:
Código del artículo (formado por tres letras y 3 números, por ejemplo: ZZZ134.
Queremos elaborar un DTD y un XMLSchema que valide diferentes documentos XML, donde cada uno de ellos contiene información relativa a una familia.
Las condiciones que se deben establecer en los esquemas son las siguientes:
En una familia puede haber un padre y una madre, o bien un solo padre, o una sola madre o ninguno de ellos. También hay posibilidad de que sean dos padres o dos madres.
El elemento padre y el elemento madre puede aparecer en cualquier orden
Posteriormente a los padres aparecerán los hijos.
El orden de aparición de hijo o hija es indiferente.
Una familia tiene al menos un hijo/a.
Tanto el elemento padre, como madre, hijo o hija contienen los elementos: nombre, apellido (siempre dos), dni (opcional) y edad (opcional).
Limitar el tamaño de nombre y apellidos a una longitud de 30.
El atributo posición toma valores del 1 al 30
El atributo código de la familia está formado por Letra mayúsculas y dos números, un guión y dos números, por ejemplo P01-12.
Apartado 1 - Crea un documento xml bien formado cumpliendo los siguientes requisitos:
Se quiere almacenar información de varias personas (al menos una) De cada persona queremos almacenar: nombre, apellido, edad, dni, email, telefono, direccion, jefe y caracteristicas. (Todos los elementos aparecen en ese orden) persona tiene un atributo requerido idpersona que es único y tiene el formato DS-33 (dos letras - dos números) apellido puede aparecer 1 o 2 veces edad, jefe y caracteristicas son opcionales. Si aparece edad tendrá un valor entre 18 y 99 Si aparece jefe, será un elemento vacío y debe contener el atributo idjefe que toma el valor del identificador de una Persona (idpersona) Si aparecen caracteristicas tiene que tener obligatoriamente al menos 1 elemento de los siguientes: idioma, lenguajeprogramacion, aunque pueden aparecer más en cualquier orden idioma y lenguajeprogramacion contendrán un atributo opcional que indicará el nivel que posee la persona, que puede ser A1, A2, B1, B2, C1, C2. idioma contendrá el nombre del idioma, como por ejemplo “Inglés”, “Francés”, etc… y lenguajeprogramacion el nombre del lenguaje, como por ejemplo "Java", "HTML", ... nombre y apellido tienen una longitud comprendida entre 1 y 30 caracteres dni tiene formato 15.356.654-C telefono tiene formato 659-540-965 y debe comenzar por el número 6 o 9 hay que validar que el valor de email es una dirección de email correcta.
*** Como ampliación trata de implementar esto si puedes: *** (es lo más complejo)
telefono e email son opcionales pero debe aparecer al menos 1 de ellos y en cualquier orden)
RECOMENDACIONES:
Crea el xml con varias personas, un empleado con todos los elementos incluyendo los opcionales, otro sólo con los elementos obligatorios, otro con varios idiomas y lenguajes de programación alterando el orden. Modifica una de las personas cumpliendo la sección de ampliación.
Apartado 2 - Crea un documento DTD de forma que pueda validar correctamente cualquier documento xml que cumpla todas las condiciones anteriormente impuestas.
Todos los requisitos que no puedan ser implementados deben ser debidamente justificados, a través de comentarios en el código.
Apartado 3 - Crea un documento XSD de forma que pueda validar correctamente cualquier documento xml que cumpla todas las condiciones anteriormente impuestas.
Todos los requisitos que no puedan ser implementados deben ser debidamente justificados, a través de comentarios en el código.
Materiales desarrollados inicialmente por el Ministerio de Educación, Cultura y Deporte y actualizados por el profesorado de la Junta de Andalucía bajo licencia Creative Commons BY-NC-SA.
Antes de cualquier uso leer detenidamente el siguenteAviso legal
Ubicación: Toda la unidad Mejora (tipo 3): Unidad 1:
- Quitar el bloque SGI,
- Añadir la unidad 4, poner como anexo el apartado de XML Schema.
- Actualizar nombre, horas (24h), orientaciones, mapa conceptual y autoevaluación.
------
Debido a la entrada de la nueva normativa: Real Decreto 405/2023 de 29 de mayo y la Resolución de 26 de junio de 2024 de la Dirección General de Formación Profesional este módulo, Lenguajes de Marcas y Sistemas de Gestión de Información, a reducido su carga horaria un 25% pasando de 128h a 96h anuales. Esto hace que se tenga que reestructurar todo el módulo para poder abordarlo con el tiempo disponible. Por ello proponemos la siguiente reestructuración de unidades:
Primer cuatrimestre
Unidad 1 (RA1, RA4): antigua unidad 1 menos el apartado de SGI y antigua unidad 4.
Unidad 2 (RA2, RA3): antigua unidad 2 y antigua unidad 3.
Segundo cuatrimestre
Unidad 3 (RA5): Antigua unidad 5
Unidad 4 (RA6, RA7): Antigua unidad 6 más el apartado de SGI de la unidad 1 (RA7)
Téngase en cuenta que según el procedimiento de elaboración de materiales en su apartado 2.1.3.- Número de unidades esta reestructuración sería lo correcto. En nuestro caso 96h / 4 unidades = 24h/unidad, dentro del rango 20 - 30 horas por unidad. ( https://www.juntadeandalucia.es/educacion/gestionafp/documentacion/Procedimiento_AM_Actualizacin_de_Materiales/213_nmero_de_unidades.html )
Además de adecuar el número de unidades se revisarían los contenidos quitando los apartados que no aparecen en la nueva normativa y añadiendo los nuevos contenidos que esta refleje.
También habrá que actualizar las orientaciones del alumnado, el mapa conceptual y revisar las autoevaluaciones.
Ubicación: Todo el documento Mejora (Mapa conceptual): Cambios debidos al cambio en los contenidos.
Ubicación: Todo el documento Mejora (Orientaciones del alumnado): Cambios debidos al cambio en los contenidos.
.jpg "Charles F. Goldfarb, co-inventor of GML")
