TAL—Template Authoring Language

Figure 1 shows two authentic examples of hypermedia applications for digital TV. In them, we can recognize the “Button-Text-Image” template used in our examples throughout Sect. 3. In both applications there is a menu (made up by a set of buttons). When a button is selected, by using remote control key navigation, a new text frame and a new image is presented, replacing the display of the previous text frame and image. Text frames and images are always exhibited in the same screen position. This interaction pattern is very common in digital TV applications (as can be seen by browsing the NCL Club public repository [8] of applications developed for the Brazilian Terrestrial Digital TV System) from where the two examples were downloaded.

It is very simple, but laborious, to specify these applications as complete hypermedia compositions; in these specific cases, using NCL. Figure 2 presents a structural view of the composition representing the navigational menu for the first application, which has only three buttons. As aforementioned, it is not possible, using NCL, to specify a variable number of child objects of a composition. That is why we had to repeatedly define three buttons, three images and three text objects, and all the relationships among them, although they have the same behavior. Moreover, that is why we cannot reuse the same structure for the second application that has four selection possibilities instead of three. In Fig. 2, three similar NCL <link> elements give the navigational temporal semantics. As for example, the one shown in the figure has the selection of the button 1 as condition. If this condition is satisfied, the presentation of all text frames and images are stopped (ending the presentation of any text frame and image previously selected) and then the presentation of the first image and the first text frame is started. The other <link> elements are only partially shown to no pollute the sketch. Also in the figure, three interfaces associated with the composition indicate that it starts presenting the three buttons. Note how tediously repetitive this specification task could be, especially for a menu with a large number of selection options.

In TAL, a template is an open-composition (an incomplete composition), or even, a pattern for a composition, whose content is given by:

Child objects of templates can be media objects (any object whose content is to be processed for exhibition) or other nested compositions. An interface can define part of the content of a media object, or can define a child object property, like its positioning on the screen, etc. Child composite objects and the template itself may also have interfaces that externalize interfaces of their internal child objects. Note that in defining the vocabulary we are also defining the hierarchy imputed to the child objects, given by the composition nesting.

It should be stressed that the number of child objects of a template may be left undefined, improving the template expressiveness. The vocabulary allows for defining types. A type for child objects can entail several instantiations.

Constraints are used to verify the correctness of the component instantiation process of a template. They specify rules on the component types and interface types of templates. They can also define algebraic expressions that correlate the cardinality of different types of components and interfaces.

Resources are the unchangeable part of a template. An example of its use is found when an author wants to include a required company logo to all application derived from the template.

Relationships give semantics to a composition. They relate child object interfaces. Since child objects of a composition (and their interfaces) can be left undefined by a template, relationships can also be established among child-object types, and among child objects types and resources. Therefore, relationships referring to child-object types need also to specify how to iterate on the interfaces of the instances of these child objects. As an example, it is possible to create relationships from each instantiated child object of a given type to all other instances of another type.

Interfaces of child objects of a composition may be mapped to interfaces of the composition in order to externalize these internal interfaces to be used in relationships defined outside the composition. Similarly to relationships, since interfaces of a composition can be left undefined by a template, mappings can be established between interface types of child objects and interface types of the composition. Therefore, mappings must also to specify how to iterate on interface instances.

Turning back to the “Button-Text-Image” template, it could be now represented as shown in Fig. 3. In the figure, three component types are defined: “button”, “text” and “image”. A cardinality constraint could require at least one instance of each type, and that the number of instances of each type is the same. Another constraint could require that the number of interface instances for the template is the same of the number of “button” component type instances. Mapping between each of the template interface instances and each “button” component type instances must be established, in order that applications that follow the template start presenting the menu (the set of buttons). In TAL, when any composition is started without specifying an interface, all its internal interfaces mapped to interfaces of the composition start.

Still in Fig. 3, there is a relationship among the “button”, “text” and “image” types. It specifies for each “button” type instance that its selection must result in stopping all instances of the “text” and “image” types, and afterwards in starting the presentation of the “text” and “image” instances correlated with the “button” instance.

Once the template is defined, an application author, for example an NCL author, may create a padding document quickly and easily; for example, the document of Listing 1 targeting the application of Fig. 2. Note that it is not necessary to define any NCL interface mappings (mappings to NCL <port> elements) or relationships (NCL <link> elements), since they are already defined in the template, and, as such, they will appear in the resultant (final) NCL document after the template processing. Note that the template is referred in the padding document by using the template attribute of the <context> element that inherits the template specification, as it is discussed in the next section.

As aforementioned, TAL must be processed together with a padding document to generate applications in different target languages, depending only on the specific TAL Processor used. A specific TAL Processor could use the template of Fig. 3 and the padding document of Listing 1 to generate the final NCL application; another specific TAL Processor could use the same template and padding document to generate the final application in SMIL. Moreover, a padding document could be easily defined for the template of Fig. 3 in SMIL, for example, or in HTML. Other particular TAL Processors could then generate final documents in NCL, SMIL, HTML, etc. based on this SMIL, or HTML, padding document and the template defined in TAL.

TAL language is composed of eight modules. Two are used in the definition of padding documents¹ and the others for template definitions.

The Classification module and the TemplateBase module are used by the padding document to extend its specification language to support templates. The Classification module defines the template attribute and the class attribute (the last one discussed in Sect. 3.4). The template attribute extends a composition specification in the padding document. It refers to the template to be used together with the open composition specification to generate the target-language final document. The TemplateBase module defines the <templateBase> element used by the padding language to define a template base. Templates used in the padding document can be imported to the <templateBase> using <importTal> child elements.

Table 1 summarizes the hierarchical structure of the elements and attributes defined in the other TAL modules. These elements and attributes are used in template definitions. Attributes that are required are underlined. Also in the table, the following symbols are used: (?) optional (zero or one occurrence); (|) or; (*) zero or more occurrences; (+) one or more occurrences. In some elements the textual content (Cdata) is a relation, or a relationship, or a mapping specification, or even an error message, as explained in what follows.

The Structure module defines the root element, called <tal>. This element has the id attribute. As any id attribute of TAL, it may receive any string value that begins with a letter or an underscore and that only contains letters, digits, “.” and “_”. The id attribute univocally identifies an element in a TAL document.

The Importing module allows for importing templates defined in other TAL documents. The <importBase> element is used for this purpose. Its documentURI attribute must have the URI of the imported TAL document as value. The alias attribute specifies a name to be used when referring to the imported template. Imported templates can be used in compositions of the importing template or else to be extended generating new templates, as discussed in Sect. 4.

The Template module defines the <template> element and its attributes. More than one template may be specified in a TAL document. A <template> must have the id attribute. The extends attribute can be used if the template extends another template, referenced by this attribute value. In this case, the template inherits the vocabulary, constraints, resources, and relationships defined in the extended template.

Types for child objects of a template are defined by the <component> element. Interface types, both for the template itself and for its child objects, are defined by the <interface> element. A relation type is defined by the <relation> element. These elements have the required id attribute, and the selects attribute, which establishes to which target padding language elements the corresponding types must be applied. The syntax of allowed values for the selects attribute is described in Sect. 3.4.

The <component> element can also have property-names as attributes. Each property-name and respective value should be converted by the TAL processor to a property/value of the instance of the <component> type. In other words, each <component> instance inherits the properties defined in the property-name attributes of the <component> type, whose interpretations are responsibility of the TAL processor. If the padding document declares a property that has already been defined by the template, the value declared by the padding document has precedence.

When an <interface> element defines an interface type for a composition, in particular for the template, it can also define a mapping to an interface of a child object of the composition, externalizing this mapped interface. As mappings can be established among types, <forEach> child elements can be used to iterate on these type instances.

The content of the <relation> element specifies a sentence that defines causal or constraint relation. Relations are used to specify relationships (discussed in Sect. 3.6).

The Constraint module establishes constraint rules by using <assert>, <report> and <warning> elements. Rules are specified similarly to Schematron [6]. In all three elements the test attribute specifies the logical test to be evaluated, following the syntax described in Sect. 3.5. The error or warning message is defined in the content of these elements. The <assert> element requires the test evaluation returns “true”, otherwise its error message should be presented. The <report> element is similar but requires that the test be evaluated as false to not exhibit its error message. The <warning> element requires that the test be evaluated as false to exhibit its warning message. When an error message occurs, the template evaluation is aborted and no final document is generated by the template processor. On the other hand, a warning message does not stop the template processing to generate the final document in some target language.

The Relationship module allows for specifying relationships. Relationships are defined by using <link> elements. As relationships can be established among types, <forEach> child elements can be used to iterate on these type instances. More details about relationships are presented in Sect. 3.6.

Resources (any target-language element) can be directly inserted in the template using the target-language namespace when defining them. The template processor interprets each element outside the template namespace as an element to be included in the final (target language) document. Listing 2 exemplifies the use of resources including a logo to be exhibited during the template presentation. Listing 2 gives the complete specification of the template of Fig. 3 (the “Button-Text-Image” template), including the logo previously mentioned. In this section, only the general template structure is explained, leaving the description of some specific attribute values to the next sections.

In Listing 2, line 1 is the standard XML header. Lines 2 to 45 define the template base that, in this case, has only one template: the “Button-Text-Image” template (lines 3 to 44). This template can be applied to padding document compositions whose template attribute has “ButtonTextImage” as value.

Lines 4 and 10 define two resources to be included in the target-language document after the template processing.

Lines 5 to 9 define an interface type for the template. This type selects every <port> element in the padding document whose class attribute has “pButton” as value. Concerning indexation, the first element found in the padding document that agrees with the “port[class = pButton]” selector is related to the pButton [1] identifier; the second to the pButton [2] and so on. This procedure is particularly useful to understand the mapping specifications, defined in lines 6 to 8, between each “pButton” interface to each corresponding “button” component. Note in line 6 how iteration is defined on each pButton[i] interface instance. In line 7 the interface of a child object is specified, by using component attribute and omitting the interface attribute. When the interface parameter is omitted, it is assumed that the child object interface corresponds to the one representing the whole content of the object.

Lines 11 to 13 define component types for child objects of the template. The component type “button” selects every <media> element in the padding document whose class attribute has “button” as value. They represent the set of menu buttons to be exhibited. Once more, the first element found in the padding document that agrees with the “media[class=button]” selector is related to the button [1] identifier; the second to the button [2] and so on. This procedure is particularly useful to understand relationship and mapping specifications. Likewise, the component types “text” (for the corresponding text frames) and “image” (for the corresponding images) select every <media> element in the padding document whose class attribute has “text” and “image” as value, respectively.

Lines 14 to 22 define relationships established among child objects of the template, when any of the buttons is selected. Section 3.6 presents relationship specifications in more details. Note, however, that the order to apply the actions defined by a relationship is the order of their definition in the <link> specification; in this case first “stop” and then “start”.

Cardinality constraints are defined in lines 23 to 43. The first constraint requires at most one “logo” instantiation. The second one requires that the number of “button” components is equal to the number of “pButton” interfaces. The third to fifth constraints require at least one “button”, one “text”, and one “image” component, respectively. The sixth and seventh constraints require that the numbers of “button”, “text”, and “image” instances are the same.

Templates and types defined in TAL may use selectors similar to CSS selectors [16]. Selectors are used to identify which elements of the padding document must be processed in agreement with the type or template they are associated with. Table 2 summarizes the different selectors that may be used.

Turning back to our example in Listing 1, the “myMenu” composition refers the template having its template attribute equal to “templates.xml#ButtonTextImage”. The “button1”, “button2” and “button3” <media> elements, all of them with the class attribute equal to “button”, are associated to the “button” component type (see Listing 2) by means of the selector “media[class=Button]”. The same happens with the other component types and interface types of the template.

As previously exemplified, template authors can establish constraints on the use of entity types they define in padding documents.

Constraint rules are defined based on constraint programming paradigm [19], in which authors specify properties (the constraints) to be obeyed by a solution, instead of a sequence of algorithmic steps that gives the solution.

The same purpose was pursued in previous TAL version, called XTemplate [9], using XPath [11] and XSLT [11] technologies. However, that proves to be of hard use, especially for non-expert programmers, which led us to this new proposition.

Figure 4 gives the EBNF [12] syntax of the new constraint language embedded in TAL. The terms in brackets and bold are the terminals of the grammar. The braces ({ }) denote an optional section. The | symbol defines an optional list for a grammatical rule.

In Fig. 4, note that TAL selectors can be used in defining constraints, which makes the language more versatile. Usually, constraints are defined as logical sentences that result from comparing two expressions (possibly nested between parentheses), which can contain integer constants, cardinality of component and interface types, or the result of a selector clause.

Figure 5 presents the EBNF syntax for defining relationships in TAL. As usual, the terms in brackets and bold are the terminals of the grammar. The braces ({ }) denote an optional section. The | symbol defines an optional list for a grammatical rule.

Relationships in TAL are defined by <link> elements that follow the same semantics of causal links of NCL [1], in which conditions must be satisfied to cause the execution of a set of actions. As in NCL, relationships are based on events. The current version of TAL supports the following event types:

Each event defines a state machine (see Fig. 6). Moreover, every event has an associated attribute, named occurrences, which counts how many times the event transits from occurring to sleeping state during a document presentation. Events of presentation and attribution types also have an attribute named repetitions, which counts how many times the event shall be automatically restarted (transited from sleeping to occurring states). This attribute may contain the “indefinite” value, leading to an endless loop of the event occurrences until some external interruption.

Link conditions can be simple or compound. Simple conditions are associated to event state transitions defined in Table 3. Compound conditions are logical expression (using “and” or “or” operators) between simple and compound conditions.

Link actions can also be simple or compound. Simple actions are shown in Table 4. Compound actions are made up by simple and compound actions associated by parallel (“||”) or sequential (“;”) operators.

Taking back to the “Button-Text-Image” template of Listing 2, lines 14 to 22 specify a relationship among types of components. Since the relationship starts with the <forEach> element, it is translated into several NCL links, when processed targeting the NCL language. These link conditions are given in line 16, in which the selection of any component of “button” type triggers the actions stopping all images and text presentations (line 17 to 19) and starting, in sequence, the presentation of the text and the image corresponding to the selected button (line 20).

Figure 7 shows an open-composition describing a slide show, a classical example of document family. During the slide show, a background audio is played. The open-composition can be defined by a template with two component types. One is the audio type, which is constrained to have only one instance. The other is the photo type, which is constrained to have at least one instance, but without limit of instances. Two resources establish the audio component and the first instance of the photo component as starting points of the composition. Two relationships are defined in the template. The first one establishes that the end of the audio instance must stop the presentation of all photo instances, thus ending the slide show. The second one determines that when the presentation of any photo ends the next photo presentation must start.

Next we use this simple example to illustrate how templates can be extended to generate new templates. So, let us first define a basic TAL template for slide shows specified using NCL language. This template is similar to the one of Fig. 7, but without the background audio. In this basic TAL template whose identifier is “slideSequence”, as shown in line 3 of Listing 3, the presentation begins starting the first photo component instance, as defined by the NCL <port> resource of line 4. Line 5 defines the photo component type that selects each padding (document) <media> element with class attribute equal to “photo”. Every instance of the photo component inherits the defined explicityDur attribute that must be translated by the TAL processor to an attribute of the targeting language that determines 6 seconds for each photo instance exhibition. Lines 12 to 14 establish that there must be at least one photo instance. The basic template has only one relationship (“changingPhotos”) defined in lines 7 to 11. The relationship determines that the end of each photo instance presentation must start the following, with the end of the last instance starting the first one. This circular behavior is created by the line 9 (“i%#photo+1”). The % symbol denotes the binary operator that calculates the remainder of the division of first operand (i) by the second operand (#photo). This is necessary in order to index the first instance after the last one.

The template of Listing 3 can now be extended by the template “slideshow” (line 4 in Listing 4) to define the desired template of Fig. 7. Line 3 of Listing 4 shows how this new template imports the previous one to be extended. The importing template will inherit the vocabulary, relationships, resources and constraints of the imported one.

Let us now extend the “slideshow” template giving rise to the “controlledSlideshow” template of Listing 5. NCL documents following this template allows for moving forward and backward in the slide sequence using the navigational “RIGHT” and “LEFT” keys, respectively, without waiting for the 6 seconds duration of each slide.

In Listing 5, the “slideshow” template is imported with the “doc” alias (line 3). The new template is defined in line 4 as an extension to the previous template. Three new relationships are added. The first defines the navigation to the next photo exhibition by using the “RIGHT” key (lines 6 to 11). The last two define the circular navigation to the previous photo exhibition by using the “LEFT” key (lines 13 to 22). Note that the “abort” command is used instead of “stop”, since “abort” does not generate notification (onEnd) to trigger the link “changingPhotos” inherited from the template of Listing 3.

The template we present in this section is similar to the Button-Text-Image template of Sect. 3. However, instead of presenting an image when a button is selected, a slideshow is exhibited. This new template example also targets the NCL language. It illustrates how TAL allows authors to define a template that contains a composition (a component type) that is defined in agreement with another referenced template.

Listing 6 presents this new template in TAL. The single difference with regards to the template of Sect. 3 is related with the previous “slideshow” template, which is imported in line 4. In this new template, instead of having the definition of the “image” component type, we define the “slideshow” component (line 13). This component represents an imported template referred in the template attribute. From line 14 on of Listing 6, the template definition is identical to lines 14 to 45 of Listing 2, except from replacing “image” by “slideshow” in all occurrences.

Finishing this section, we should stress that template nesting enhances TAL expressiveness and makes easier the modeling of several scenarios.