Google Search
[ french ]

Table des mati鑢es
1. Rationale
2. Defines
3. File extensions and proposed MIME types
4. The DIML syntax
4.1 DIML statements
4.2 Data injection markup
4.2.1 Accessing to variables Variables as strings Variables as scalar values Nesting implicit string conversions
4.2.2 Arrays Array substitution The [] array operator Relative access Array value vs scalar value of a variable Reading to current indexes of arrays Array calls in the "main body" Multidimensionnal arrays
4.2.3 Calibrating substituted strings When formatting attributes should be used The MAXLENGTH attribute The MINLENGTH attribute The DEFAULT attribute The NULL attribute The FORMAT attribute
4.2.4 Predefined variable names The %NULL% signal The %ERROR% variable The %CGI::...% variable set The %ENV::...% environment variables The %FORM::...% form entries
4.2.5 Defining variable from DIML side What for ? Setting variables as templates, the INLINE attribute The SET statement
4.3 Structural markup
4.3.1 The TEMPLATE element Template definition Attributes Template contents
4.3.2 Template calls Single call Array call Overriding repetition count limitation Rules for reusing templates or variables Nested iterations Simplfying access to local templates
4.4 Expressions
4.4.1 Conditionnal statements The IF...ELSIF...ELSE...ENDIF statement The "one shot" conditionnal syntax The multiline syntax Operators and variables in conditions For the future : the SWITCH...CASE statement
5. DIML document structure
5.1 Main body
5.2 Templates sections
5.2.1 Use of array calls in a template definition
6. Appendices
Appendix 1 : The ESSI Multidimensional Array Model
Appendix 2 : References
Appendix 3 : Hall of honors
 Latest News
 An application of the  WCT_NEWS  component
>> Top of page

Data Injection Markup Language

Language Specification

Author: V.G. FREMAUX
E.I.S.T.I. / Cergy, France
Eisti Advanced Research LaboratorY (EARLY)

Version: 1.0 / March 1999

0. Scope of this document

This specification results from an internal study within the Graduate School for Computer Sciences Engineering of Cergy, France, as a preparatory work for its laboratory & research center establishment. We do not know, at the time we start this writing, which kind of publication it will be used for, neither if it will be publicized some day.

However, we will assume it could be publicized in the future and will produce the largest documentation and specification we will be able to.

1. Rationale

The present specification introduces a new approach in the Web design languages domain. Most of the common scripting languages trends are to agglomerate code and presentational description. As for an example, in php scripts (that is true also within JScripts or ASP programs) the conditional writing of HTML statements results in a scrambled code where php syntax are mixed with HTML statement.

The result of this is that both the programmers and the designers keep unsatisfied of this situation. In a ideal world, would we likely imagine a productive cooperation between programmers and designers, each one knowing perfectly where are their common boundaries.

In this ideal world, we would suppose that programmers would be uniquely interested in the way systems are implemented and mechanism are conceived and optimized.

On the other hand, designers would appreciate that data dynamism and process should be definitively resolved, whatever complexity is involved in these processes. The main work of the designer should be properly speaking designing the interfaces.

So the scripting languages are inversely merely mixing the two techniques rather than attempting to isolate them.

From this confusion it results that mechanisms which could be standardized are being developped again and again, just because some aspects of presentation have changed, or because some details in functionality have been modified.

Our present proposal, as a server-side code extension to HTML, may constitute some solution to improve "programmer to designer" interface. We have implemented this extension in order to definitively separate the logic implementation of some client-server functionality and the graphic layout and style of the interface.

Posterior investigations have shown that Microsoft ODBC syntax development for IIS server have confirmed the first allegations of the ESSI syntax. For compatibility reasons, we decided to design the ESSI syntax as a super-ensemble of the Microsoft XTH syntax.

The present specification is finally a middle point between standard HTML concepts and XML document structuration. Documents based upon XML (and its associated XSL style language) become very complex quite soon, and developping XML structures need often a long analysis of the document set. DIML technique is a first step in information factorization that prefigure what XML can do but without its complexity.

2. Definitions

The ESSI extension
The ESSI (Enhanced Server-Side Includes) extension extends the power of the standard SSI techniques, adding a mean to mark where string variables issued from a script should be injected in an HTML fragment, and using new syntactic constructs to improve reusability of the HTML.
The ESSI technology allows the designer to define HTML templates that are used as structural components for the presentation of a document. Although style sheets where able to concentrate some style definition attributes, templates are a more powerful way to structure HTML code for reusability.
The ESSI definitions deals with breaking an HTML document into many independent fragments that could define an "informational entity" for layout.
For example, a common technique for designing wideband Web pages is to simulate frames from a combination of a dual zoned background and a table with suitable dimensions. This technique results in a single HTML source document where the code for the "page" follows code for the simulated sideframe. In fact, the designer always considers these two codes as being separate entities, although he has to merge both codes into a single file.
ESSI templates specifications allow to explicitly differentiate both definitions, store this definitions in two separate locations, and join them as a standard <!--#include ...--> statement. The main improvements of the ESSI technique are :
  • the ability to store HTML templates in the same file than the calling fragment.
  • furthermore, the ability to organize fragments independently from the physical files.
  • the dimensioned template definition that can be used to automatically iterate a layout rendering from records in a database or arrays generated in the calling script
These are right now the main improvements. Some other features should be added to templates from here to the end of this writing.
Data injection markup
Therefore, the ESSI extension defines a syntax for injecting strings from a script. The main underlying idea came from the typical CGI constructs being resumed in :
  1. parsing request string from a CGI call
  2. calculating, extracting, choosing data to be rendered, opening files, storing into database, emailing results...
  3. printing an HTML answer to the client
Thus, if all the variables to be printed have been defined, the last action can be assumed being a simple print sequence. Writing this printing sequence in the source script file does generally not allow to actually separate layout work from software encoding.
So we tried to define a simple syntax that standardizes data insertion into an ESSI template (or HTML fragment in an ESSI compliant file).
Our idea is that the printings do always result from reading a template file, injecting data where suitable, thus producing straight HTML code, and then printing the resulting HTML text back to the client. Our injection process will illustrate this concept.
Script API
Finally, The ESSI extension defines a common API for the handlers that process templates. This API is defined in order to hide some verification procedures, especially when rendering iterative templates, and to improve robustness of the implementation. This API will be described in an associated document.
ESSI processor
As we designed the system, the ESSI sources (containing HTML code and ESSI statements) should be processed before being served to the user agent. We will use an ESSI processor for this purpose.
We will produce test versions of the ESSI processor for C scripts, Perl and php implementations. Further tests will concern asp and vbscripts.
The ESSI processor parses the ESSI constructs, generates a pseudo HTML file with data fields markers, then replaces each mark with its suitable processed value, and finally sends back the HTML document for printing.

3. File extensions and proposed MIME type

ESSI technology deals essentially with extended HTML files in which templates are defined. These files should be processed by a server before being sent to a user agent.

The templates and HTML code should be written in files with an .dim or .diml extension. We will have some proposal for an optional MIME type in a next future.

4. The ESSI syntax

4.1 ESSI statements

For the ESSI processor to identify ESSI statements to parse, every ESSI statement will be included between a start and an end marker. The elected marker pair for ESSI statements is <% ... %>.

As a default, we assume that the overall ESSI statement markup forces a string conversion to be operated. When the statement is processed, it may return a value that will be always the string representation of the result of the parsing. If no value has to be returned, this implicit string conversion has no effect, and an empty string is returned by the parser.

ESSI statements are divided into two main classes :

the structural markups
The structural markups deals with templates. They will be used to tell where a template is defined, and where (and how) it should be used.
the data injection markups
The data injection markups are used to indicate where a variable should be injected, and set some layout limitations to force calibration of the strings.

4.2 Data injection markup

4.2.1 Accessing to variables Variables as strings

In most cases, symbolic variable names are used to call a variable value to be injected as a string in an HTML final document. An ESSI variable is an ASCII token (defined as a 'C' token) inserted within two '%' characters.

variable ::= %token%

and should be a matching result of the regexp :

identificateur ::= [^%*?.+"><\^\\\$]*

The above regexp pattern forbids usage of the variable mark '%' character, neither of the '*', '?', '.', '+', '^' and '$' metacharacters, neither of the special delimitors '"', '>', '<', and '\'.

example :


It will be assumed the token is a valid key of the ESSI input hash array. (See API definition for the ESSI processor).

Usually, variable are just "injected" in an HTML sequence. In this case, the variable is automatically converted into its string representation as implied by the overall ESSI statement markup. For example, consider a table row in which should be rendered some data from a catalog as an item name, a reference code and a unity price. An DIML sequence using injection syntax would be written like this:

<FONT COLOR="#800000"><%%ITEM_NAME%%></FONT>
<TD WIDTH=200>
<TD ALIGN=right>

For readability in large DIML source files, it is possible to insert separators between the symbolic name and the variable markers.


is then an equivalent to

<% %A_VARIABLE% %>

But in the three next expressions :

< %%A_VARIABLE%% >  

is illegal and not matched by the processor.

<% % A_VARIABLE % %> 

is legal but may in some implementations match the token ' A_VARIABLE ' with leading and training space.

< %% A_VARIABLE %% > is illegal and won't be matched by the processor.

Conversely, there MUST NOT be any separators between the ESSI mark characters ('<%' or '%>'). Variables as scalar values

The primary representation of a variable can be used within an ESSI statement, especially within logical expressions in conditional statements.

In such constructs, the single identifier can be used to designate the variable in the same representation it has in the calling CGI script. If this variable is a string (respectively an integer, a float, a boolean), than


should be substituted by this string value, or the equivalent string value (whether it is an integer, a float, a boolean...) while the unmarked identifier in :

<% if (test_value) ... end of ESSI statement %>

should represent the effective value of the internal variable identified by test_value.

Many script languages have defined a syntax to "print" the value of a variable. Here are some typical equivalents in some well-known languages of some typical variable call expressions :




<? echo "$VARIABLE"; ?>

Microsoft XTH


CGI Perl



printf("%matching_format", VARIABLE); Nesting implicit string conversions

The string resulting of an implicit conversion may in turn be considered as potentially containing DIML statements. The example below shows such a situation, after a template call has been substituted :

<% text of some template .. <%%VARIABLE%%> .. end of the template %>

In that particular situation, the outer expression is evaluated first (the surrounding template), and substituted as required. The resulting expression is than parsed again (for inner DIML statements) to calculate the final value for the statement.

The parsing continues until there is no more substitution to proceed, either because there are not more ESSI statements in the string.


As a consequence, the following declaration :

<% ESSI statement .. <% ESSI statement %> .. end of statement %>

is not allowed, but should be replaced by :

<% ESSI statement .. &lt;% ESSI statement %&gt; .. end of statement %>

4.2.2 Arrays Use of arrays in ESSI substitutions

Main goal of the ESSI extension is to provide a mean to completely separate the design of the pages from the logical part of a development. This is barely possible when the documents results from iterative writings, say, after requesting in a data base.

Generally the code for requesting, reading and processing data fields in a record needs the two part of the code to be closely mixed.

The array solution of the ESSI syntax is a walkthrough to this issue. The Array [] operator

When a variable is called using the array operator [] (example : %VARIABLE[]%) the variable is assumed being an iterative access to an array.

The array values are accessed in the same order the variable calls are evaluated. An index iteration is proceeded at the end of each template evaluation. Thus, in the same template, a array call keeps the same value. The example :

<TEMPLATE id="testTemplate">

constructs a table row containing the three same values %ARRAY[]% at the array current index. Relative data access in arrays

Sometimes it may be interesting to access an array somewhere else than where is pointing the current index. The ESSI syntax allows to access an array specifying a relative offset from the actual index.

The relative offset can be either a forward or backward seek, and is expressed as a position counter.


accesses to the past value in the ARRAY array. %ARRAY[+2]% accesses to the second next value in the ARRAY array. Any "out of bounds" call results in the %NULL% variable. Array value and scalar value of a variable

A variable name may be used simultaneously as a scalar and an array access. When this happens, the scalar value and array value are distinct and may not be confused.


adds one extra value to the content of

%variable[]% Reading current indexes of arrays

An array should store permanently its current index (within the scope of the process of one single document) to be able to retrieve subsequent values when it is injected again later in the template. A convenient way to keep trace of this index is to store it a scalar variable name related to the array.

To avoid confusion and preserve simplicity, we strongly recommend that any index be stored in variables which name is constructed on the array name basis, postpending a .

%ARRAY[]% should be driven by %ARRAY% index variable Use of arrays in the "main body"

Originally, arrays were associated to an iterative construction using ESSI templates. What happens if an array call is performed in the main body of an DIML source file ?

The simplest way to react is to access the array variable at the current index value that was left after the last template iteration. According to the rule that indexes iterates only after a template substitution, no iteration take place when the array is accessed inside the "main body" part of the document. Multidimensional arrays

In case of nested template calls, a variable entry might be used for scanning a multidimensional data structure. An example of this is when using a single variable name, say %CELL% to construct a table of technical data. In that particular case, it could be convenient to accept a multidimensional form to a variable as


With such a form, it should be possible to write a template for a table cell as :

<TEMPLATE ID=a_single_cell>
<TD><FONT COLOR="#000080><%%CELL[][]%%></FONT></TD>

which should be called by a "row" template such as :

<TEMPLATE ID=a_single_row>
<%template file=#line_label>
<%template file=#a_single_cell iterate=3>

where "line_label" should be a template giving the row labels in the table :

<TEMPLATE ID=#line_label>

Telling how the iteration works may be a bit complicated, and will induce implementation, but is an absolutely necessary definition to explore the most powerful syntactic expressions of the ESSI specification.

When an array variable is evaluated, the Processor starts calculating the rightmost index, based on the effective value of the "array current index" stored in an additional scalar variable associated with this array. This index is the simplest to calculate, but should be reset to 0 IF THERE ARE any upper index level (to scan a new line of an array when the surrounding template call iterates). This is a major change relative to the initial definition of the iteration rules. Conversely, if this index level is the outermost (leftmost bracket pair), the index value should not be reset to 0 to allow subsequent calls to template to keep on iterating from the last reached position (I told you it was somewhat complicated !!).

4.2.3 Calibrating substituted strings

The ESSI procedure allows accessing data without any presentational attributes. Thus, any layout and rendering attributes should be defined in the HTML code in the template files. Isolating design and data processing considerations can result in faulty renderings if the result string is longer than the maximum graphical length allowed for this information. This is a frequent cause of trouble in text processing applications using auto line wrap around features, or in Web auto-calibrating layout.

As a default, the data substitution is not calibrated (ie, the string obtained when data value is converted has no size limit, and will be substituted entirely).

It should be possible to control from the template some parameters of the string being inserted. This will result in additional attributes in a data injection statement. Some of these parameters are also used in template call statements. Where should be written the calibrating attributes

The calibrating attributes are modifiers that have direct influence on the way an expression is converted to it's string representation. Thus, it is assumed that the formatting attributes could be mentioned wherever it is useful.

The first use of formatting modifiers occurs in the single variable conversion :

%A_Variable MAXLENGTH=10 FORMAT=###.##%

However, the format modifiers should be also used in the final ESSI expression (as there is conceptually a last implicit string conversion of the final value of the statement. So the following is acceptable:

<%if (test) %variable FORMAT=#*.###E% else %alternate FORMAT=0*H% MAXLENGTH=6 %>

The MAXLENGTH attribute will be than distributed in both alternatives of the <%if ... %> statement. The MAXLENGTH attribute

Usage :
Template calls, Data Injection Statement, ESSI global statement

The MAXLENGTH attribute defines the maximum char length of the string that will be substituted to the injection statement. The MAXLENGTH's argument is a char count expressed as an integer. If the result of the substitution process is a string which length exceeds the MAXLENGTH specification, then the string will be chopped to match the required length.

This attribute may be used by a designer to protect a layout from inconsistent data. It may be difficult to exactly set this attribute, as many fonts do not use a single character width. The MINLENGTH attribute

Usage :
Template calls, Data Injection Statement, ESSI global statement

The MINLENGTH attribute defines the minimum char length of the string that will be substituted to the injection statement. The MINLENGTH's argument is a char count expressed as an integer.

The primary behavior for this parameter is to force adding non breaking spaces to the resulting string if its length is lower to the specified value. The substituted string will than have at least MINLENGTH characters, that could be translated as a pixel size when used on a fixed width font. The DEFAULT attribute

Usage :
Data Injection Statement, ESSI global statement

The DEFAULT attribute allows the user to define an alternate string to be substituted if the variable returns nothing (a blank string). The NULL attribute

Usage :
Data Injection Statement, ESSI global statement

The NULL attribute allows the user to define an alternate string to be substituted if the variable returns %NULL% (standing for an undefined or missing variable in the input array). The FORMAT attribute

Usage :
Data Injection Statement

The FORMAT attribute is defined to allow users to deal with numerical variables. The final action of the ESSI processor is always to print a string evaluation of the data being inserted. This attribute only adds some control on the way the conversion is performed.

Its value is a mask that indicates how the value in the variable should be printed. The mask should be quoted as there can be some literal spaces in it.

The usual symbols that should be used in a print mask are :

# - do not prints non significant zeros.

0 - forces a zero to be printed at that position if it were not
significant at that position, either the number.

. - indicates the position for the decimal point

. - indicates the position for the decimal period (latin representation)

e - when inserted at the end of the mask, indicates that the number
should be written in a scientific format, with a one significant
digit mantissa, and a conventional signed exponent part.

E - when inserted at the end of the mask, and followed by an
integer number, means that the variable should be printed in a scientific format with fixed exponent value. The exponent width is the number that follows the 'E' symbol.

H - when inserted at the end of the mask, stands for an hexadecimal representation.

* - only in use after a 0 or # mark as a "any number of" modifier


The format defaults to the standard string conversion of the "print" or "echo" primitive of the implementation language for the ESSI processor.

The default format will give the conversion below depending on the nature of the variable :

the variable is an integer : #*

the variable is a floating point number : #.#*E#*

4.2.4 Predefined variable names

Some special variable names are predefined, and are used to pass a signal to the ESSI parser. In case a predefined variable is detected, it will be not be directly substituted. A special processing will be made, resulting sometimes in no substitution at all. The %NULL% signal

A processor can temporarily use a %NULL% signal to indicate that an expected hash entry cannot be found. The parser will substitute an alternate string if it is defined by the NULL attribute of a variable call. The default string value to be substituted is "" (the blank string).

You should notice that the %NULL% signal is equivalent to a %NULL% entry in the input hash that defaults to "".

The %NULL% special variable will evaluate in order :

 a NULL attribute in the variable call

 a NULL entry in the input hash array

 the empty string The %ERROR% variable

A parsing operation may result in an error situation especially when the FORMAT attribute is defined, and the representation cannot be converted. Sometimes the error may even occur when the script tries to compute the variable. The content of the %ERROR% should at least match the following pattern.

error_code : error message The %CGI::...% variables

The %CGI::...% variable calls group centralizes direct calls to CGI standard interface variables such as REMOTE_HOST, USER_AGENT, QUERY_STRING etc, allowing a designer to include some of these information in the document, or a software developer to perform some test from the remote end. The %ENV::...% environement variables

The %ENV::...% set of variables allows a direct binding to the other environment variables. This will give designers direct access to these variables to compose the final document, and will allow smart debugging in complex procedures. The %FORM::...% form entries

The %FORM::...% set of variables allows a direct binding to form entries, when the document is issued from a CGI complying request. This will give designers direct access to these variables to compose the final document, and will allow smart debugging in complex procedures.

4.2.5 Defining variables from DIML side What for ?

Defining variables is a necessary feature to allow hiding some constructs to the designer. As an example, consider a CGI function call that needs to be activated through a Javascript function in order to hide explicit printing of the request string in the client widgets.

The typical case above could be written like this :

function FormLaunch(formname, actioncode)
document.form[formname].action.value = actioncode;
<FORM NAME="CgiCall" ACTION="/cgi-bin/cgiCall.exe" METHOD=POST>
... form items ...
<INPUT TYPE=hidden NAME=action VALUE="defaultActionCode">
<A HREF="Javascript:FormLaunch('CgiCall', 'anAction')">
   <IMG SRC="some_image.gif" BORDER=0>

The challenge is that the most part of the technical implementation could be hidden whithout reducing flexibility in how the form elements are placed and shaped. The variable definition feature, along with the "header element recollection" capability, will allow such an improvement.

The following shows how to reduce the form submission code :

<A HREF="Javascript:FormLaunch('CgiCall', 'anAction')">
<IMG SRC="some_image.gif" BORDER=0></A>

to the single expression :

<% %anAction()% %>

while the designer still will be able to choose which image is used to represent the activator :

<IMG SRC="some_image.gif" BORDER=0> Defining variables as templates, the INLINE attribute

First soluce will construct a developper side template as :

<TEMPLATE ID="anAction()">
<A HREF="Javascript:FormLaunch('CgiCall', 'anAction')">
<IMG SRC="<% %IMAGES_ROOT_UTL% %><% %anAction_image% %>" BORDER=0></A>

then allowing a designer side template to define the source of the image :

<TEMPLATE ID="anAction_image" INLINE>

The INLINE attribute specifies here that the leading and trailing newline are not part of the template content (and so the association <% %IMAGES_ROOT_UTL% %><% %anAction_image% %> will not roll off at the end of the image root path string. The INLINE template above starts with an 'a' as first char, and ends with an 'f'. The SET statement

The SET statement allow the designer to pass explicitely some variables to the script author's side. The author should use these variables to produce some hidden constructs. The syntax for a variable definition statement is :

<%set %VARIABLE%="quoted_string" %>

Double quote may be omited if the quoted_string contains no white spaces.

Variables are defined from the point the SET statement is parsed. The value is available from this point using a single call syntax :

<% %VARIABLE% %>

The variable definition feature may be used to "reset" some iterative table pointers (ie. reseting the first cursor of the table_name[] table known as table_name when using the Perl ESSI Processor).

The above example should be written :

<FORM <% %CGI_CALL% %> >
... form items ...
<%set %CGI_CALL->IMAGE% = "" >

The script author will define :

a template internally (in the script source, or as an external template in a separate file) :
function FormLaunch(formname, actioncode)
document.form[formname].action.value = actioncode;
<INPUT TYPE=hidden NAME=action VALUE="defaultActionCode">
<A HREF="Javascript:FormLaunch('CgiCall')">

The name (ie CGI_CALL and CGI_CALL->ANACTION()) of the DIML calls involved in the action. Note here that we choosed an "object oriented" notation that will depend on capability of the DIML Processor. This is a "a posteriori" rationale to the encapsulation of variable names between two '%' characters, as it allows larger variable name conventions to be used.

The name (ie CGI_CALL->IMAGE) of optional variables the author will need to construct the hidden template.

Note : please note that the SET statement could be written at any place in the DIML source document

4.3 Structural markups

4.3.1 Templates

Template is a way to optimize Web document encoding, extending the entity concept to sub-entities. The underlying idea is that any Web page (or any page in a document) layout has sub-components that can be semantically isolated. For example, a typical catalog index should have some general header indicating who is the owner of the catalog, then will follow a high level menu for global navigation in the whole Web site. Then will follow a toolbar which makes the catalog manipulation easy. Then comes the actual list of selected or sorted items.

HTML has a major limitation till now. As application of an SGML document, a document contains generally a single HEAD section, and a BODY section. The unique alternative to this would be a FRAMESET definitions that parts the layout into independent frames, each one loading a new document file.

It has been largely proved that frame structures are a bit tricky to manipulate, especially in dynamic systems. The main interest in FRAMESET is the relative gain in network bandwidth as frames still consistent will not be loaded again when something on the screen must change (see the TARGET attribute of the A element in HTML 3.0).

A template gives a new approach for the improvement of document's structures and reusability of HTML code. Template definition

An ESSI template is defined as a fragment of HTML document in which some ESSI variables can be injected. Any HTML construct can be written in a template. Eventually, a template could include a whole HTML page. This is the way it is implicitly understood in DIML documents.

An ESSI template is defined as an SGML element that adds its definition to the HTML standard element list.

An ESSI template declaration starts with a


start tag and ends with a


end tag (as commonly used in HTML definitions)

A template definition should normally occur only outside a standard BODY element. But, as ESSI statements are processed before sending the document, it won't cause any trouble to insert a template definition in a BODY, or HEAD section. The ESSI processor should not leave any template definitions in the processed document.

Don't be astound that our constructs are close to standard SGML declarations. We must assume that one day, ESSI statements could be used at user agents side (who knows ...!). Attributes

A template has a basic ID attribute which assigns a name to the template. This name is mandatory if the template has to be recalled by a substitution statement. The ID may be any quoted string as defined in the SGML definition, or a single token unquoted if no separator is used in.

The INLINE attribute : see defining variables as templates Template element contents

A template may contain a fragment of an HTML document, but can also contain a HEAD element. This HEAD element should be concatenated to the actual HEAD element of the main HTML fragment, when the substitution statement is executed. The content of the HEAD section should be inserted only once in the main HEAD section, even if the template is used twice or more times. For example, the DIML code :

<HEAD> some main header code...</HEAD>
<% template file="#one" %>
<% template file="#one" %>
<SCRIPT TYPE=Javascript>
function TemplateSpecificFunction()
some HTML body code...

should produce, once processed :

<HEAD> some main header code...
<SCRIPT TYPE=Javascript>
function TemplateSpecificFunction()
some HTML body code...
the same HTML body code...

There is today no provision for cumulating some indexed HEAD items.

The content of a template can include itself other variable substitution calls, or other template calls, which should be processed before inserting the content into the calling fragment.


4.3.2 Template calls Single call

An ESSI template can be recalled whenever in a DIML fragment, even prior its effective definition. This implies templates MUST be cropped before the substitution operations start.

A simple call is proceeded by a calling statement in the DIML source file :

... HEAD statements
<P><%template src=a_valid_fragment_URI %>

The file attribute pointing on the desired template may be used as a standard fragment URL, pointing on an HTML fragment. The template's id is to be considered as a fragment anchor. Thus, a template might be fetched in another DIML source file. Here come some examples of some classic situations :

The following statement :

<%template file="#template_id" %>

calls a template defined somewhere in the same source file. The statement :

<%template file="some_relative_path/some_document.diml#template_id" %>

will search for a template named "template_id" into a file designated relatively to the current path.

In order to cope with SSI inclusion restrictions the file attribute should not accept any ".." in it.

To point into a file located somewhere else in the file system, you should use the virtual attribute, so :

<%template virtual "../a_file.diml#a_template" %>

is valid.

The file or virtual attribute should always be local pathes. Trying to include files outside the local host space, say, trying to use an http: prefix, is not allowed yet (that is, no protocol nor machine name should be mentioned). Array call

Templates are also made to provide a painless mean to define HTML layout models that should be applied as an iterator in an HTML document dynamic construction process.

A Web page resulting from automatic database extraction, or any other programmatic construction shows often repetitive elements. This repetition is the consequence of the iterative way the page has been constructed.

Thus, the ESSI syntax proposes a way to use a template as iteration model.

For example, lets consider an answer of a search engine to a query for some topic. Usually, the search results are obtained from a database, and a Web page is constructed with such results, giving something like :

<H1>Results from your query :</H1>
   <TR WIDTH=400>
      <TD ALIGN=top WIDTH=40>1 -</TD>
	 <TD ALIGN=top WIDTH=400>
	 <A HREF SRC=""></A><BR><P>
	 <FONT COLOR="#FFFF80" SIZE=-1>Some information associated 
	   with this link</FONT>

Suppose now that your query is answered by 10 matching url. The <TR>...</TR> line should appear 10 times, with a sequence number in the left cell, and each link written close to its description in the right cell.

This could be the result of an array call of an ESSI template using array variables :

<TEMPLATE ID="aSingleRow">
<TR WIDTH=400>
   <TD ALIGN=top WIDTH=40><%%SEQUENCE[]%%> -</TD>
   <TD ALIGN=top WIDTH=400>
   <A HREF SRC="<%%MATCHING_URL[]%%>"><%%MATCHING_URL[]%%></A>

An array call is just like a single call, excepted that its syntax denotes an array usage of the array variables that are used in :

<%template file="#a_template_anchor" iterate=10 %>

means that a maximum of 10 rows can be printed in the resulting HTML code, even if more than 10 records were extracted from the database. The way the script should manage paged layout depends on the script itself, and of use of special variables as counters. To force consistency of the model, a single call should be thought as a single iteration array call of a template, so :

<%template file=#a_template %>


<%template file=#a_template iterate=1 %>

are equivalent.

This call causes the ESSI processor to iterate the input hash structure, incrementing related indexes depending on the inclusion nesting level and the table dimension. Overriding repetition count limitation

In some applications, the result page must flow continuously down, rendering the whole resutl list of a single request. The following syntax allows overriding the previously defined limitation and proposes a "while there are data" form of the iterated template call.

<%template file="#a_template_anchor" iterate="*" %> Rules for reusing templates or variables

As it has been foreseen, array indexes are iterated as soon as the surrounding template has been evaluated. This has two major consequence :

  • No iteration can take place in the global fragment of an DIML file.
  • When a template is later recalled, iteration continues where it stopped after the first iteration loop.
  • As all indexes always restarts to 1 when a document is parsed, a designer should not rely on sequence continuity between two Web pages. Nested iterations

As nested template calls are allowed, it may be useful to describe how should behave a fully featured processor when nesting array calls to some templates. Here comes an example of such a situation :

<TEMPLATE ID="inner_loop">
<TEMPLATE ID="outer_loop">
<%template file="#inner_loop" iterate=3 %>
Some part of main body...
<%template file="#outer_loop" iterate=5 %>

The expected result of such a construct is a square array of 5 x 3 cells, in which each value should correspond to the input array segment [SOME_ARRAY񖶄, SOME_ARRAY񘄶].

The global scheme of array management is discussed in a complementary document Simplified access to local templates

Resulting from a clever comment of one of my students, who found somewhat ugly the calling syntax, especially when the DIML file was monolithic, a simplified alternate access syntax has been added to the initial <%template ... %> call.

Experimenting the processor, we noted that adding the template content as a new entry of the input hash array could be convenient. A local template can thus be directly called as a local ESSI variable, where the variable name is the unique ID in the template declaration.

The direct call syntax will be extended to a local array call, adding brackets to the ID key.

As an example, if a local template is defined as follows :

<TEMPLATE ID="a_template">
Some DIML text ...

then a template substitution in a body section could be notified by the simple call :

<% %a_template% %>

If the template contains array access variables, then it would be convenient to call directly the array form :

<% %a_template[10]% %>


<% %a_template[*]% %>

Implementation note : Note that variable creation resulting from local template definitions will occur at compile-time (is not implicit in the calling code). The users will take care to avoid naming collisions between in-code variables and template parsing resulting variables.

4.4 Expressions

ESSI statements may use simple control structures. These control structure may willingly remain elementary because the ESSI extension does not pretend to replace scripting languages. It just does provide a way to help structuring complex HTML layouts, and separating the logic and the rendering aspect of a client server mechanism.

4.4.1 Conditional statements The IF...ELSE...ENDIF statement

ESSI statements can be written as a standard conditional structure "if ... else". Complexity of such a structure is not a main goal. They are only defined to improve design of template files and optimizes storing space when different layouts are very similar.

To improve clarification of the DIML source, conditional structures may appear using two distinguishable forms. When the whole statement is written within the same DIML statement, it is called "one shot" statement. When it directly switches between in-line HTML alternatives, it is called "multiline". The "one shot" syntax

The syntax for a conditional statement is :

<%if (condition) expression else expression %> 

in which expression may be a single variable or a template call, and condition is an expression that has a final boolean value.

The condition may use any syntax features the native language of the processor will allow, and in most cases, will accept the usual C-condition conventions.

The expression can be a template call, that will produce the insertion of a substituted template where the statement stands :

<%if (%TEST%) %template file="#the_template"% %endif %>

An expression may also be a literal HTML fragment. This form is provided for convenience where the conditional statement is used to switch between two short HTML statements :

<%if (%TEST% == 0) "<HR WIDTH=30>" %else %ALTERNATIVE% %endif %> 

The example above shows also that these forms can be combined in any way.

Be carefull to escape correctly the litterals. A litteral quote in an HTML sequence should be marked as the character entity &quot;. The characters :

  • ["] double quote
  • [<] when followed by a [%]
  • [>] when preceded by a [%]

should be escaped to avoid processor confusion.

Notice that the ESSI processor does execute a single pass character entity substitution, based on the character list given in the HTML 4.0 DTD (see the The "multiline" syntax

For convenience when large HTML alternatives must be switched, a form similar to SSI conditional syntax is accepted for DIML conditional statements :

<%if (condition) %>
some HTML code ...
<%elsif (condition) %>
a second HTML alternative...
<%else %>
some other code...
<%endif %> Operators in conditions

The ESSI extension recognizes the major comparison operators used in C and PERL :

==	equality
!= 	difference
<		lower to (strictly)
>		higher to (strictly)
<=	lower or equal
>=	higher or equal
eq	equality (lexicographically)
lt	lower to (lexicographically)
gt 	higher to (lexicographically)
ne 	non equal (lexicographically)

The ESSI extension adds the PERL operators for regexp comparison :

=~	contains scheme
!~ 	does not contain scheme

Moreover, the ESSI syntax allow use of logical operators to combine multiple expression tests :

!		unary not
&&	logical AND
||	logical OR
^		logical XOR The SWITCH...CASE statement

To extend power of conditional constructs, the ESSI definition accepts a structure to deal with "selector" variables.

The basic form of this statement is :

<%switch (%SELECTOR%) case text_value_expression %>
DIML statements...
<%case alternative_value_1 %>
DIML statements...
<%case alternative_value_2 %>
DIML statements...
<%case alternative_value_3 %>
DIML statements...
<%case alternative_value_4 %>
DIML statements...
<%case alternative_value_5 %>
DIML statements...
<%default %>
DIML default code...
<%endcase %>

Such a structure works like in ANSI-C, except that no explicit "break;" signal should be written. The "endcase" branch point is automatically reached as the specific "case" has been parsed.

There should have only a few further extensions in statements as ESSI syntax is NOT intended to grow as a programming language. We only thought that developers could spare efforts and time using some minimal conditional features, and thus reducing the number of template files to be written.

5. ESSI document structure

This chapter discusses about possible structure used by DIML documents. Will be detailed the differences between what is induced by the syntactic rules, and the consequences of some extra usage, attempting to specify what should be the reaction of an ESSI processor to such an extrapolated use.

Additionally, this chapter will define some basic rules to indicate how an DIML should be parsed.

5.1 Global section

As an extension of an HTML document, it may assumed that an DIML document could be written using only HTML valid constructs. So any HTML document is an DIML document.

As a consequence, any DIML document may contain a HEAD section, a BODY section, which in turn could contain some inline TEMPLATE defs, and finally some isolated TEMPLATE defs past the </BODY> closing tag.

Will be considered as part of the GLOBAL section any HTML constructs that are defined outside any template definitions. The global section defines the HTML text frame that will effectively be used as the document basis. Conversely, templates must be interpreted as information bricks that are given next to the main body, and that will be used to finalize this body.

A global section may contain any injection scheme or template calls it will need. It globally must be treated as an HTML document would be, once the ESSI replacements are done.

Array calls will be processed as defined in this specification, iterating the index each time the template is fully substituted.

5.2 Template sections

Any code inserted between two section marks is considered outside the global section and may be even never written in the finalized document.

This code can contain injection scheme or other template calls. A special attention must be paid in case of call loops as there is no obligation for a processor to signal this faulty situations.

Template sections MUST NOT be nested - as it would be meaningless - though it is possible to call a template within a template definition.

5.2.1 Use of array calls in a template definition

As template calls are allowed in a template definitions (except recursive calls), it is syntactically possible to call a template using its array form.

In this case, the programmer should beware that ESSI processing of the array will be executed "just-in-time", and the input data arrays will be iterated linearly each time the template is processed.

6. Appendices

Appendix 1 : The ESSI Multidimensional Array Model

Appendix 2 : References

Appendix 3 : Hall of honors

Great thanks to everybody who came to support the project, who listened my elucubrations during all this amount of time, and who gave me the most "psychespace profe award" of the 1999th (wasn't too hard being the unique candidate !).

Special thanks to

  • Jean-Louis Campion
    Eisti Applied Research LaboratorY (EARLY)
    for his constant asistance.
  • William Godin
    EISTI - promo 2002
    For his help in testing prototype and concepts
  • The NTIC students
    EISTI - promo 2000
    For their criticisms and opinion
  • Nesim Fintz
    Our venerated dean
  • Francis Gibert & Sean Gough
    FGP / GS Sensors
    Patiently waiting for our results
  • Edouard Deslandes
    For his sympathetic support and encouragements

    All material is copyleft V.G. FREMAUX (EISTI France) 1999 to 2003 except explicitly mentioned