ACTION-2: Send an email reporting about the mapping tool from XML to IDL, Java and ECMAScript

Hello everyone,

 

Here goes what Rodrigo and I could find out about the XML tool used in DOM recommendations to map from XML to IDL, Java and ECMAScript.

Our main source of information are the Production Notes in the DOM Level 1 Core W3C Recommendation (http://www.w3.org/TR/REC-DOM-Level-1/production-notes.html <http://www.w3.org/TR/REC-DOM-Level-1/production-notes.html> ).

 

I'll briefly explain what it is all about by using some key sentences in that document:

 

The DOM specification is written using XML. All documents are valid XML. In order to produce the HTML versions of the specification, the object indexes, the Java source code, and the OMG IDL and ECMA Script definitions, the XML specification is converted.

 

The tool currently used for conversion is COST by Joe English. COST takes the ESIS output of nsgmls, creates an internal representation, and then allows scripts, and event handlers to be run over the internal data structure. Event handlers allow document patterns and associated processing to be specified: when the pattern is matched during a pre-order traversal of a document subtree, the associated action is executed. This is the heart of the conversion process. Scripts are used to tie the various components together. For example, each of the major derived data sources (Java code etc.) is created by the execution of a script, which in turn executes one or more event handlers. The scripts and event handlers are specified using TCL.

 

We could also have used Jade, by James Clark. Like COST, Jade allows patterns and actions to be specified, but Jade is based on DSSSL, an international standard, whereas COST is not. Jade is more powerful than COST in many ways, but prior experience of the editor with Cost made it easier to use this rather than Jade. A future version or Level of the DOM specification may be produced using Jade or an XSL processor.

 

@@ Nacho: Let's take into account this Recommendation is from 1998

 

The complete XML source files are available at: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/xml-source.zip <http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/xml-source.zip>   What we found here are templates to generate the documentation and the mappings to the IDL, Java and ECMAScript and (in the definitions directory) the XML-ized definition of DOM interfaces for DOM core and HTML.

 

@@ Nacho: But the scripts used to generate the final results are missing or we have not found them

 

@@Nacho: In chapter 3 (Object Definitions) you can find an example of the XML that DOM team used (some sort of IDL XML-ized)

 

@@Nacho: In the Appendix C: IDL Definitions in the DOM Level 1 Core W3C Recommendation (http://www.w3.org/TR/REC-DOM-Level-1/idl-definitions.html <http://www.w3.org/TR/REC-DOM-Level-1/idl-definitions.html> ). They seem to be using omniidl to validate the IDL generated by COST (see Makefile). The IDL files in this zip are the different IDL interfaces for each DOM "element" (and they seem to be the ones in the definitions directory in the first zip file). The .hh and .cc seem to be the mapping to C++.

 

Summary: We have found XML-ized definitions for DOM interfaces, the templates to generate the documentation of DOM Recommendation and production notes about how they converted XML-ized defintions into the different mappings (and a reference to the parser used). We have not found the TCL scripts used to carry out the conversion. (Btw, today we would make it with an XSLT transformation, but the XSLT should be built almost from scratch) Maybe Cedric might help us to fill the gaps by contacting people related to the work around DOM.

 

Food for thought: Should we follow this approach? Does it make sense to use XML to define interfaces? Shouldn't we directly use IDL? Take into account that we only wanted to show previous experience of W3C working groups around IDL. Their approach might not necessarily be the best. 

 

Best regards,

 

Nacho

 

******************************************

Ignacio Marín Prendes

Coordinador de la Línea de Independencia de Dispositivo

Área de I+D+i

ignacio.marin@fundacionctic.org <blocked::BLOCKED::mailto:ignacio.marin@fundacionctic.org> 

www.fundacionctic.org <blocked::BLOCKED::blocked::http://www.fundacionctic.org> 

Fundación CTIC -Centro Tecnológico de la Información y la Comunicación-

Parque Científico y Tecnológico de Gijón

Edificio Centros Tecnológicos 

33203 Cabueñes - Gijón - Asturias

Teléfono: 984 29 12 12

Fax: 984 39 06 12

******************************************

Este e-mail y cualquiera de sus ficheros anexos son confidenciales y pueden incluir información privilegiada. Si usted no es el destinatario adecuado (o responsable de remitirlo a la persona indicada), agradeceríamos lo notificase o reenviase inmediatamente al emisor. No revele estos contenidos a ninguna otra persona, no los utilice para otra finalidad, ni almacene y/o copie esta información en medio alguno.

Opiniones, conclusiones y otro tipo de información relacionada con este mensaje que no sean relativas a la actividad propia de CTIC deberán ser entendidas como exclusivas del emisor.

--------------------------------------------

This e-mail is confidential and may contain legally privileged information. If you are not the intended recipient it may be unlawful for you to read, copy, distribute or otherwise make use of the information herein. If you have received this e-mail in error, please contact us immediately. Fundación  CTIC will accept no liability for the mistransmission, interference, or interception of any e-mail and you are reminded that e-mail is not a secure method of communication.