Previous Up Next

Chapter 15  SIDL Backend


15.1  Introduction

This chapter introduces the SIDL backend associated with symbols that may originate from a SIDL file or the corresponding Extensible Markup Language (XML) representation. Unlike most of the other supported language bindings, the output from this backend is textual in nature. That is, it is the textual, human-readable form of the interfaces description. An alternative text form, XML that is, which is also supported is described in Chapter  16.

15.2  Purpose

The primary reason for having a SIDL backend is to provide a mechanism for generating human-readable text for interfaces that are written in conformant XML. It is important to emphasize that Babel requires the XML to conform to the SIDL DTD in order to benefit from this feature.

Generating SIDL provides a feature to collaborators who are interested in experimenting with the XML form of the interfaces. Such groups should find the more human-readable descriptions of the interfaces to be helpful for distribution and discussion.

15.3  Generated versus Original SIDL files

Generated SIDL files may differ from their original SIDL files in several respects in terms of content as well as layout. These differences are summarized below.

Packages.
The code generation is limited to one high-level package per generated file. In fact, the name of the generated file is currently defined to be the concatenation of the name of the highest-level package and .sidl.
Versioning.
The generation of requires statements is inferred from the symbols that actually appear in the associated interface descriptions. The intent is to provide a requires statement for only the highest level package needed of a given version. Consequently, requires and imports statements that were not necessary for resolving symbols will not appear. Also, fully qualified names will be shortened in the generated files due to the automatic generation of the associated requires statement(s). Finally, since an import and require statement can be used in a SIDL file and no distinction is made in the XML, only a require statement will appear in the generated file.
Implements.
Since there is no distinction between implements-all and implements in the XML version of the interfaces, the generated code outputs implements along with the inherited methods.
Comments.
Babel preserves only document, or doc, comments so any comments that do not conform will not appear in the generated file 1.
Whitespace.
Obviously there may be whitespace differences in the generated file. These include indentation, blank spaces and lines, and brace placement.

As an example, suppose we have a package in the file foo.sidl. The original file’s contents are:

SIDL
package foo version 1.0 { class A {} package bar version 2.0 { class B {} } }

The resulting contents of the generated SIDL file are:

SIDL
package foo version 1.0 { class A { } package bar version 2.0 { class B { } } }

Notice the differences in white space. To illustrate more features, further suppose we have a package in the file fooTest.sidl. The original file’s contents are:

SIDL
// An ignored comment require foo version 1.0; require foo.bar version 2.0; /** * Test of doc comment with XML special characters < & >. */ package fooTest version 0.1 { /** * Another doc comment for an empty class. */ class A extends foo.bar.B {} class B extends foo.A {} }

The resulting contents of the generated SIDL file are:

SIDL
require foo version 1.0; require foo.bar version 2.0; /** * Test of doc comment with XML special characters < & >. */ package fooTest version 0.1 { /** * Another doc comment for an empty class. */ class A extends foo.bar.B { } class B extends foo.A { } }

Here we see the exclusion of non-document comments and the retention of document comments. Refer to Section 6.2 and Appendix C for more information about document comments.

15.4  XML File Comparison

Testing has revealed that XML generated from the original SIDL file compared to XML generated from generated SIDL files have only minor differences. In fact, the differences are limited to specific metadata fields. Specifically, the date, source-url, and source-line entries can differ. The dates, however, will be the same if the “--suppress-timestamp” option was used when both XML files were generated. Similarly, the source-line entries will be the same if the package started on the same line in both the original and generated SIDL files. The latter can happen if, for instance, there are no non-doc comments in the original file.

15.5  Babel Command Line Options

To generate SIDL from a file using the default repository to resolve symbols, you should invoke Babel as follows 2:

% babel --exclude-external --text=SIDL file.sidl

or use the short form

% babel -E -tSIDL file.sidl

Alternatively, you can generate SIDL from XML symbols, again assuming the default repository is used to resolve symbols, by typing the following at the command line:

% babel --exclude-external --text=SIDL packagename

or use the short form

% babel -E -tSIDL packagename

1
For more information on comments and doc-comments, refer to Comments and Doc-Comments in Section 6.2.
2
For information on additional command line options, refer to Section 4.2.

Previous Up Next