Definir el formato que puede ser utilizado en un documento
Desde que surgieron los primeros lenguajes de marcación GML y SGML se generaron diversos mecanismos para definir como , cuales y cuantos elementos podían existir en determinado formato, los DTD's (Document Type Definitions) figuran entre los primeros mecanismos.
Uno de los DTD's que probablemente ya haya utilizado es el de HTML (lo puede observar en http://www.w3.org/TR/REC-html40 ), aunque no se haya percatado de esto, todo navegador ("Netscape", "Explorer", "KDE"...etc) esta diseñado alrededor de estos DTD's. Estos DTD's le permiten al navegador validar la información que reciben en HTML, esto es, si se encuentra un elemento <TITLE>, que otros elementos le pueden seguir ? que tipo de información puede contener ?, o bien, un elemento <IMG> que parámetros requiere ? se puede encontrar dentro de otros elementos como <H1> ?
Aunque el entrar en los detalles de DTD's para HTML sería excesivo (al menos que fuera a diseñar su propio navegador) con el surgimiento de XML se torna necesario conocer algunos detalles de los DTD's.
HTML es un estándar y por lo general es utilizado por los ya comunes navegadores ("Netscape ,"Explorer"), pero que ocurre cuando define información especifica de su empresa como:
<producto> <nombre modelo="xdfsdf"> <disponibilidad lugar="almacen"> Si </disponibilidad> <descripcion> 60 Watts Doble Canal </descripcion> </nombre> </producto> |
Es correcto que modelo puede ser atributo del elemento nombre ? El elemento disponiblidad puede tomar el valor Si ?, los DTD's definen este tipo de incógnitas. Esto no solo le permitirá mantener ciertos lineamientos sino eventualmente será requerido por las diversas aplicaciones | programas que utilicen esta información; si un navegador encuentra un elemento incongruente seguramente ya esta diseñado para lidiar con ese tipo de error , pero si es una aplicación | programa diseñada in-house de alguna manera u otra deberá reconocer incongruencias; cabe mencionar que los diversos "parsers" que hacen uso de Schemas y DTD's para reconocer estas incongruencias son conocidos como "Fully Validating Parsers".
Los "Document Type Definitions" (o "Data Type Definitions") son escritos en el formato Extended Backus Naur Form, sin embargo, este formato presenta varias deficiencias, una de las más obvias: expresividad , el siguiente DTD define las características del fragmento XML anterior:
<!ELEMENT producto (nombre+)>
<!ELEMENT nombre (disponibilidad, descripcion*)>
<!ATTLIST nombre
modelo CDATA #REQUIRED>
<!ELEMENT disponibilidad (#PCDATA)>
<!ATTLIST disponibilidad
lugar (almacen | exposicion | ambos) #IMPLIED
<!ELEMENT descripcion (#PCDATA)>
|
La primer linea indica que el elemento producto contiene uno o mas elementos llamados nombre.
La siguiente linea describe que el elemento nombre esta compuesto por un elemento llamado disponibilidad seguido de cero o más elementos llamados descripcion
Posteriormente <ATTLIST nombre indica que serán definidos los atributos del elemento nombre , en este caso modelo el cual es obligatorio (#REQUIRED) y esta compuesto por texto simple (CDATA).
La quinta linea define que el elemento disponibilidad estará compuesta por texto simple (PCDATA)
<ATTLIST disponibilidad empieza a definir los atributos del elemento disponibilidad, en este caso el único atributo es llamado lugar y esta restringido a los valores almacen, exposicion, ambos
Finalmente se indica que el elemento descripcion consta de texto simple (PCDATA)
Para emplear este DTD es necesario indicarlo en el documento XML, esto se hace en lo que es denominado Prologo , el fragmento XML anterior terminaría con la siguiente definición (asumiendo que el DTD fue nombrado producto.dtd):
<?xml version="1.0"?>
<DOCTYPE producto SYSTEM "producto.dtd">
<producto>
<nombre modelo="xdfsdf">
<disponibilidad lugar="almacen"> Si </disponibilidad>
<descripcion> 60 Watts Doble Canal </descripcion>
</nombre>
</producto>
|
La linea <DOCTYPE producto SYSTEM "producto.dtd"> declara que será utilizado el DTD producto.dtd que reside en el mismo directorio del documento en cuestión. Esto bien pudiera ver tomado un valor como: http://osmosislatina.com/xml/dtds/producto.dtd para indicar que el DTD residía en un sitio Web.
A partir de este punto es posible introducir este documento a un programa que haga uso de un "Parser" DOM,SAX,JDOM , y será mediante las funciones del "Parser" que será validada y manipulada la información del documento.
El concepto de "Namespaces" surge de la necesidad para combinar diferentes vocabularios en XML, es una forma de agrupar distintos elementos para poder ser utilizados en un solo documento, esto es, suponga que esta trabajando con sus proveedores | clientes y estos le facilitan su información en XML, debido a que están en la misma industria es muy probable ya utilicen elementos en común como <monitor> , <software> ...etc. si desarrolla un programa que haga uso de estos elementos comunes es mediante Namespaces que se elimina la ambigüedad que pueda surgir en el programa.
Si observa detalladamente
la definición del DTD anterior
notará que no es nada descriptiva, se utilizan términos como CDATA, PCDATA , abreviaciones para indicar cantidades: * (cero o más), + (uno o más), aunado a estas declaraciones poco amigables, los DTD's también poseen las siguientes restricciones:
No es posible agregar cierta lógica a las declaraciones, regresando al
DTD anterior
quizás sea conveniente definir que el elemento disponibilidad pueda contener otro elemento y no solamente texto ( PCDATA ), sin embargo, una definición como: <!ELEMENT disponibilidad (#PCDATA | (#PCDATA, ciudad+))> no es valida en DTD's.
No existe manera de indicar mayor restricción al procesar elementos de texto, esto es, la información esta en formato de fecha (05-21-2001) ? Formato monetario ($12.21)?
No existe apoyo para Namespaces , los cuales resultan cruciales conforme se empiecen a definir elementos (vocabularios) extensos.