The following section describes how to specify a presentation input script for the DesignComposer. Basically, such scripts are XML-like markup files; in fact, the Design Input Language (DIL) is nothing else than a XML subset.

The content of a DIL script consists in markups and plain text. Both data are mapped to the currently installed knowledge base, which is build up from a set of DCL files. Markups are mapped to design commands. Here a valid mapping has to fulfill two requirements: first, there must be a design command with the same name like the markup (case sensitive like XML !). Second, the attributes specified in the markup has to meet the required arguments of the design command. If one of these preconditions is not fulfilled, the mapping is not valid. If an invalid mapping is detected, the DC's error handler is activated which may ignore the error (and thus the markup) or alternatively stop, just depending on the kind of error handler which has been installed.

Plain text is always mapped to a specific text input node structure. Carriage returns are ignored; white space is always compressed to a single space sign.

Definition of an Attribute Assignment

Attribute assignments are done like in XML: just specify the arguments name and its value. Important is their meaning for the mapping between DIL and DCL described below.

name = (value | "value")

Definition of a DIL Markup

A DIL markup does always refer to a design command name. Its syntax is basically equal to a common HTML/XML markup. Other input commands may be contained within an input command, then a closing markup is required which is optional otherwise.

< name [ newScope = Boolean expression ] ( attribute assignment )* ] >
[ ( input command )* ]
</ name >

Details:

• name specifies the design command to be executed here. The command has to be member of one of the layout knowledge bases currently loaded, what typically means that it has to be specified in a DCL script file loaded before. If it is not, the input command is discarded; enclosed commands are processed.
• Attribute assignments are serve as arguments for the referred design command. For a valid mapping of an attribute to an argument, the names of the argument and the attribute have to be identical; furthermore, the attribute values type has to meet the requested argument type. This means, that when the argument is for example a number, the attribute value string has to represent a number as well. Further notes about attributes:
  • If an attribute name does not meet any argument name, it is not thrown away. Instead, it is forwarded as an additional, optional argument to the design command when processing is done. Here it may be accessed by the DC's attribute manager when local attributes are requested.
  • If no attribute is defined for an argument, this doesn't necessarily mean that the mapping between design command and markup fails. First, it is checked if the command defines a default value for this argument, only if it does not, the mapping fails.
  • The order the attributes are specified is of no meaning for the mapping process. Also, attributes may be specified multiple times in one markup; then all specifications are mapped, and the latest valid one is used.
  
  DEFAULT: -