 |
 |
|
|
La especificación DOM es un buen ejemplo de la potencia del XML: todos los documentos HTML, correspondencias con Java, correspondencias con el IDL OMG y las correspondencias con ECMA Script han sido generados desde un solo conjunto de ficheros fuente XML. Esta sección describe cómo se escribió esta especificación en XML, y cómo se crearon las diferentes obras derivadas.
Esta especificación está escrita completamente en XML, usando un DTD basado extensivamente en el DTD usado por el Grupo de Trabajo XML para la especificación XML. La principal diferencia entre el DTD usado por el Grupo de Trabajo XML y el DTD usado para esta especificación está en la adición de un modulo DTD para las especificaciones de las interfaces.
El modulo DTD para las especificaciones de las interfaces es una traducción muy poco estricta desde la especificación EBNF (Extended Backus-Naur Form, Forma Backus-Naur Extendida) de la sintaxis IDL OMG a la sintaxis DTD XML. Además de la traducción, se sumó la capacidad de describir las interfaces, creando así una forma limitada de programación literaria para definiciones de interfaces.
i bien el modulo DTD es suficiente para los propósitos del Grupo de Trabajo DOM, sus tipos son muy débiles, lo cual quiere decir que hay muy pocas restricciones en las especificaciones de los tipos (la información sobre el tipo se trata en efecto como una cadena opaca). En un DTD para la comunicación objeto a objeto probablemente serían beneficiosas algunas restricciones más fuertes sobre los tipos de datos.
La especificación DOM se escribió usando XML. Todos los documentos son XML válido. Para producir las versiones HTML de la especificación, los índices de objetos, el código fuente Java, y las definiciones IDL OMG y ECMA Script, la especificación fue convertida.
La herramienta usada para la conversión es COST, de Joe English. COST toma la salida ESIS de nsgmls, crea una representación interna, y entonces ejecuta scripts y manejadores de eventos sobre la estructura interna de datos. Los manejadores de eventos permiten que se especifiquen patrones de documentos y procesos asociados: cuando se encuentra un patrón durante un recorrido en preorden del sub-árbol del documento, se ejecuta la acción asociada. Este es el corazón del proceso de conversión. Los scripts se usan para enlazar entre sí las distintas componentes. Por ejemplo, cada uno de los fuentes de datos derivados principales (código Java, etc.), es creado por la ejecución de un script, que a su vez ejecuta uno o más manejadores de eventos. Los scripts y manejadores de eventos se especifican por medio de TCL.
La versión actual de COST ha sido modificada en algunos aspectos a partir de la versión disponible al público. En particular, ahora funciona correctamente bajo Windows 32-bits, usa TCL 8.0 y sigue correctamente las reglas de diferenciación entre mayúsculas y minúsculas de XML (aunque probablemente no podría manejar correctamente código en lenguaje nativo).
También podríamos haber usado Jade, de James Clark. Al igual que COST, Jade permite que se especifiquen patrones y acciones, pero Jade se basa en DSSSL, un estándar internacional, mientras que COST no lo hace. Jade es más potente que COST en muchos aspectos, pero la experiencia previa del editor con COST hizo más fácil de usar a éste que a Jade. Una futura versión o Nivel de la especificación DOM se podría producir usando Jade o un procesador XSL.
Los ficheros fuente XML completos están disponibles en: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/xml-source.zip
Como se ha dicho antes, todas las definiciones de los objetos están especificadas en XML. Las correspondencias con Java, IDL OMG y ECMA Script están todas generadas automáticamente a partir del código fuente XML.
Esto es posible porque la información especificada en XML es un superconjunto de lo que estas otras sintaxis necesitan. Esto es una observación general; se puede aplicar el mismo tipo de técnica a otras muchas áreas: a partir de una estructura rica, son posibles un procesamiento y conversión ricos. Para Java y el IDL OMG, es básicamente una cuestión de renombrar las palabras clave sintácticas; para ECMA Script el proceso es algo más desarrollado.
Una definición típica de objeto en XML se parece a algo de este estilo:
<interface name="foo">
<descr><p>Description goes here...</p></descr>
<method name="bar">
<descr><p>Description goes here...</p></descr>
<parameters>
<param name="baz" type="DOMString" attr="in">
<descr><p>Description goes here...</p></descr>
</param>
</parameters>
<returns type="void">
<descr><p>Description goes here...</p></descr>
</returns>
<raises>
<!-- Throws no exceptions -->
</raises>
</method>
</interface>
Como se puede ver, esto no es precisamente ahorrativo en palabras, pero tampoco lo es el IDL OMG. De hecho, cuando al principio la especificación se convirtió para usar XML, las definiciones IDL OMG se convirtieron automáticamente en el fuente XML correspondiente usando herramientas comunes de Unix para la manipulación de texto.
|
|