TAL—Template Authoring Language
© The Brazilian Computer Society 2012
Received: 30 November 2011
Accepted: 23 March 2012
Published: 12 May 2012
This paper presents TAL (Template Authoring Language), an authoring language for hypermedia document templates. Templates describe document families with structural or semantic similarities among them. TAL supports the description of templates independently of the target hypermedia authoring language. The paper also presents a TAL processor that generates complete hypermedia documents taking as input a template specification in TAL and a data file with the information that makes that document particular in its family.
KeywordsTAL Nested context language Template oriented programming Hypermedia authoring Hypermedia design patterns iDTV
Hypermedia documents define presentations of media objects (text, audio, video, images, etc.) spatially and temporally related. The creation of such documents is usually achieved by using declarative languages, among which structure-based XML languages, such as NCL , SMIL , SVG , etc.
Some structure-based languages include the concept of hypermedia composition as one of the most important abstractions authors can use. Hypermedia compositions include media objects and other hypermedia compositions, recursively, in addition to relationships among these elements. Hypermedia compositions may implicitly define relationships among their child elements, as is the case of “par” and “seq” SMIL containers with their embedded temporal semantics. But they can also have relationships explicitly defined, as is the case with NCL links. In either case, hypermedia compositions encapsulate semantic relationships among objects. We should note that even with languages that do not support composition abstraction, the whole body of the document denotes a composition. In other words, the concept of composition still prevails, although not allowing composition nesting.
Precisely because compositions encapsulate semantic relationships, hypermedia languages that support them allow for the creation of extensively reusable documents . However, to the best of our knowledge, all structure-based hypermedia languages fail to let authors create compositions with unspecified internal content or unspecified relationships, that is, with incomplete content. As a simple example, such languages allow us to create a slideshow with a fixed number of images being presented together with a background audio. However, they do not allow us to define a slideshow “pattern” of presentation (note that we are not talking about layout but about document content), so that it can be reused and customized in specific instances. We must define which images we are going to use, and which background music we want to be played. This is because this sort of authoring languages aims at specifying particular hypermedia documents and not a family of documents.
A family of documents is defined as a set of documents that share the same specification for their compositional structure, which we call a template .
In this paper we present TAL: Template Authoring Language. TAL is a modular declarative language that supports the specification of templates: incomplete hypermedia compositions. TAL defines a family (a set) of compositions, and it is independent of any authoring language used to specify hypermedia applications that benefit from TAL compositions to define a particular member of the template family. In the paper, we also present a TAL processor, developed to instantiate final hypermedia documents (application specifications) from TAL templates.
TAL is an evolution of the XTemplate  language. It is also a kind of XML schema having as its main purpose to let expert authors specify templates to be used by other authors (possibly non-experts) in a simple, quick and error-free document creation process.
There are many good reasons for template-based development. First, templates promote coherent application branding, enabling content producers to define and follow the same hypermedia-application pattern. Second, as a consequence of having hypermedia presentations following the same interface patterns, thanks to a common source template, they can be more usable for those who view and interact with different documents of the same family. Third, template-based authoring promotes reuse, allowing authors to concentrate on filling out only the blanks that make a particular document unique within the family to which it belongs. Finally, templates can also encode domain concepts across related applications, creating a specific vocabulary and defining a set of constraints on this vocabulary, to be followed by all documents of a given family.
In this work, a template is formally described by means of a vocabulary of allowed child-object types, a set of relations allowed between those types, rules that constraint the instantiation of these child-object types and relations, and a set of fixed composition’s components (media or composite objects and relationships). In this sense, a template is an incomplete hypermedia composition that has certain blanks that must be filled out in accordance with rules that constrain the content and relationships that authors can insert.
After this brief introduction, the next sections are structured as follows. Section 2 briefly discusses related work. Section 3 presents TAL; the language concepts are defined, the language elements and attributes are presented, and an example is discussed in detail. Section 4 shows how templates can be extended given rise to other templates, and how template definitions can be nested. Finally, Sect. 5 presents our conclusions and final remarks.
2 Related work
Several hypermedia applications embed common design patterns. Design patterns have been intensively studied and proposed in the literature , including those targeting hypermedia applications [4, 10].
In line with design patterns principles, SMIL Timesheets  allow for adding temporal behavior to hypermedia applications independent of the language used by the application. Indeed, SMIL Timesheets, is a temporal counterpart of CSS , also developed in W3C recommendation groups. More precisely, SMIL Timesheets aims to allow any language to incorporate the XML elements and attributes of the SMIL temporal control modules. SMIL Timesheets specify which elements are active at a given time moment and their temporal scope within a document.
Unlike SMIL Timesheets, which allow for embedding temporal aspects in documents written in some timeless specification languages, the TAL language allows for specifying temporal semantics to be applied to compositions outside of them, and as first-class entities. The aim is to incorporate the defined semantics in hypermedia application specifications that are defined using languages that allow temporal behavior specifications.
TAL allows for defining not only common design patterns but also a series of constraints on their uses, as is discussed extensively in the next sections. TAL can be considered as a specification language to a set of high level hypermedia design patterns expressed as a template.
A key basis for TAL development was the composition templates proposed in previous versions of XTemplate language . The XTemplate model is based on the style and configuration concepts introduced in Architecture Description Languages (ADLs) . In ADLs, a style describes the conceptual architecture of a system, and a configuration an instance of the style. There is a clear similarity between the composition template and the architectural style concept, and also between the hypermedia composition and architectural configuration concepts. However, the open hypermedia composition concept of XTemplate is at the same time a style and a configuration. Open hypermedia compositions define not only a vocabulary of types and restrictions on the instantiations of these types (similar to styles in ADLs) but also enable the definition of resources, which are elements present in all documents based on these compositions (similar to the purposes of configurations in ADLs).
The new version of XTemplate (3.0)  targets families of documents written in NCL 3.0. Unlike TAL, XTemplate 3.0 was developed to a specific target hypermedia language. On the other hand, TAL can be processed together with a padding document to generate applications in different target languages, depending only on the specific processor used. TAL specifications can thus be used to generate hypermedia applications in declarative languages such as SMIL , SVG , HTML/ECMAScript , NCL , etc.
XTemplate focus on easing the authoring performed by experts. However, all XTemplate users need to have some technical pre-requisites such as XPath and XSLT  knowledge, even if they only need to instantiate composition templates. On the contrary, TAL has as one of its goals to reduce the need for expert authors. TAL avoids the use of external notations different from those of the target-language conceptual model, and notations that are beyond the abstraction level of the target language (like XSLT processing instructions of XTemplate 3.0 do).
In a previous work, we have established the characteristics and methods that may govern the template oriented authoring process . In that paper two main roles involved in the process are described: (i) the role played by the template author, which is an expert responsible for the identification and design of templates, and (ii) the role played by the document author, which can usually be a non-expert since he/she only needs to understand how to fill the gaps described in templates (in what we call, in this paper, the padding document).
One challenge raised in the mentioned work  is how to smoothly communicate the template semantics, typically related to the abstraction level of the template authors, to final document authors to allow them to perform their main task: to instantiate the template in some target language. In the current work, TAL templates are designed to allow the final document author to understand templates, without needing further pre-programming requirements. Ideally, we tried to reduce the cognitive distance between the two roles. Although we know that in some cases a meta language for template semantic description will be necessary, for simple scenarios, this proves to be possible.
3 Template authoring language
TAL is a XML-based language that follows the modular approach. In Sect. 3.1 we present a simple use case, defined by the “Button-Text-Image” template, which will be worked out in the remaining subsections. Section 3.2 introduces TAL language concepts, while Sect. 3.3 describes the language elements and attributes. Section 3.4 presents the syntax for defining the language selectors, and Sect. 3.5 the syntax for defining constraints. Section 3.6 deals with how relationships among child objects of a composition must be specified.
3.1 Use case: Button-Text-Image template
3.2 TAL concepts—overview
Vocabulary: defining the allowed types of child object (the components) of the template, the allowed types of interfaces for these child objects and for the template itself, and the allowed relations to be used in relationships among child objects.
Constraints: defining rules on the types defined in the vocabulary.
Resources: instantiated child objects that shall be inherited by all compositions that use (follow) the template.
Relationships: relating child-object types and resources.
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.
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.
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.
3.3 TAL specification
TAL language is composed of eight modules. Two are used in the definition of padding documents1 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.
XML elements and attributes of TAL Language
(template | importBase)+
(component | interface | relation | assert | report | warning | link)*
id, selects, (property-name)*
(component | interface)*
id, selects, componente, interface
Cdata = mapping specification (forEach)?
Cdata = relation specification
Cdata = message
Cdata = message
Cdata = message
Cdata = link specification (forEach)*
Cdata = link specification (forEach)*
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.
The Vocabulary module defines entity types of a template, through the <component>, <interface> and <relation> elements.
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 . 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.
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  identifier; the second to the pButton  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  identifier; the second to the button  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.
3.4 Selectors of TAL
TAL Language selectors
Selects any element
Selects any element whose name is E
Selects any F element descendant of an E element
E > F
Selects any F element child of an E element
Selects an E element when it is the ith child
E + F
Selects any F element that is immediately preceded by an E element
Selects any E element that has the “foo” attribute
E[foo = val]
Selects any E element whose “foo” attribute has “val” as a value
E[foo ∼= val]
Selects any E element whose “foo” attribute is a list of values, and one of them is equal to “val”
The same as E[class ∼= val]
Selects any E element whose identifier is equal to “myId”
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.
3.5 Constraint language
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 , 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 , using XPath  and XSLT  technologies. However, that proves to be of hard use, especially for non-expert programmers, which led us to this new proposition.
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.
3.6 Specifying relationships in TAL
presentation event, which is defined by the presentation of a subset of the information units of a media object. Presentation events can also be defined on compositions, representing the presentation of the information units of any object inside it;
selection event, which is defined by the selection of a subset of the information units of a media object being presented;
attribution event, which is defined by the attribution of a value to a property of an object.
Reserved condition values associated to event state machines
Reserved action role values associated to event state machines
Some examples can help understanding how relationships are defined. If one would like to define a relationship between two media objects “A” and “B”, in which the end of “A” starts the exhibition of “B”, we would have “onEnd A then start B end”. In another example, if an author would like to mute the audio of an audiovisual object “V” when it is resized (property bounds), we would have “onEndAttribution V.bounds then set V.soundLevel = ‘0’ end”.
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).
4 Extending and nesting templates
This section describes two further features of TAL. In Sect. 4.1 we illustrate the extension mechanism for templates, using a slide show as example. In Sect. 4.2 we show how templates can define component types that follow other template definitions. This template nesting feature is exemplified by replacing the “image” component type of the Button-Text-Image template of Sect. 3, by a component type that follows the “slideshow” template of Sect. 4.1.
4.1 Slide show
In the “slideshow” template, a new audio component type is defined (line 6) with only one instance (constraint in line 14 to 16). A <media> element of the padding document shall refer to this component through its class attribute having “audio” as value. Another NCL <port> resource is also added (line 5) to start the audio component instance when the template starts its presentation. The relationship of lines 7 to 13 establishes that the end of the presentation of the audio instance must stop the presentation of all photo component instances.
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.
4.2 Button-Text-Slideshow Template
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.
Finishing this section, we should stress that template nesting enhances TAL expressiveness and makes easier the modeling of several scenarios.
Templates specified using TAL can be instantiated generating new final documents. As aforementioned, these documents are actually the output of a TAL processor. In order to do so, a TAL processor takes a template specification along with a padding document as its input data. This kind of approach enables “expert” authors to create TAL templates to be used by less skilled multimedia document creators (see Listing 2). All the latter have to do is to define how features that are specific to the particular document they are about to produce must be filled in. In other words, less skilled authors simply produce a padding document for a particular TAL template (see Listing 1 for a padding document targeting the NCL language). We should emphasize that this strategy promotes reuse of all the semantic structure associated to a template.
The paradigm used to create applications promoted by TAL seems to appropriately answer to the requirements imposed by emerging interactive digital TV applications. It allows for authors to establish and follow a particular format (or pattern) of presentation, which may be associated to branding, among other things.
A side effect of using TAL, which may come as a handy feature, is that it allows authors to specify explicitly the semantics of a given composition type. That is, as we define a template as an open hypermedia composition, new compositions are created as specializations of high-level specification. Seen from this perspective, a template can be taken as the description of semantic constrains that apply to all relationships pertaining to a given composition type, regardless of the actual compositions that are eventually instantiated by end authors.
The TAL processor for NCL was developed in Lua language and it is freely distributed in http://www.telemidia.puc-rio.br/tal.
We are currently working on providing use of templates in authoring tools such as NCL Composer [5, 7]. Since this particular tool provides support for plug-ins that may define different authoring views for a document specification (textual, layout, structural, outline, and temporal views, among others), we are working on adding views to help authors creating new documents using TAL templates. This should promote the use of Composer, helping novice authors to create new documents based on pre-existing templates.
As future work we are planning to do empirical tests with (potential) TAL users, in an attempt to understand what is the actual contribution of TAL to the overall usability of NCL-based authoring resources, especially in comparison with other existing template-specification languages (in the same domain). One of the factors that are of particular interest and relevance for this research is to assess the scalability of TAL in actual contexts of use.
As another future work we are planning to use ontologies in describing TAL templates. This would bring about better reasoners to check the consistency of templates, sub-templates and instances. Moreover, users could use conventional ontology readers and editors in using TAL.
A template must be processed together with a padding document given rise to a new document in some specification language, called target language. Usually a specific processor is required for each target language.
This research has been partially supported by CNPq and FAPERJ.
- ABNT NBR 15606-2:2007. (September, 2007) Televisão digital terrestre—Codificação de dados e especificações de transmissão para radiodifusão digital—Parte 2: Ginga-NCL para receptores fixos e móveis—Linguagem de aplicação XML para codificação de aplicações (Portuguese)Google Scholar
- Clements PC (1996) A survey of architecture description languages. In: International workshop on software specifications and design. Proceedings of the 8th international workshop on software specification and design. ISBN:0-8186-7361-3Google Scholar
- Gamma E et al. (1994) Design patterns: elements of reusable object-oriented Software. ISBN 978-0201633610. Addison-Wesley, ReadingGoogle Scholar
- Germán DM, Cowan DD (2000) Towards a unified catalog of hypermedia design patterns. In: 33rd Hawaii international conference on system sciencesGoogle Scholar
- Guimarães RL, Costa RMR, Soares LFG (2007) Composer: Ambiente de Autoria de Aplicações Declarativas para TV Digital Interativa. In: XII Simpósio Brasileiro de Sistemas Multimídia e Web—WebMedia (Portuguese)Google Scholar
- ISO/IEC Standard. ISO/IEC 19757-3:2006 Information technology—Document Schema Definition Language (DSDL)—Part 3: Rule-based validation—SchematronGoogle Scholar
- Lima BS, Soares LFG, Moreno MF (2011) Considering non-functional aspects in the design of hypermedia authoring tools. In: ACM symposium on applied computing, SACGoogle Scholar
- NCL Club. http://www.clube.ncl.org.br
- Muchaluat-Saade DC, Rodrigues RF, Soares LFG (2002) XConnector: extending XLink to provide multimedia synchronization. In: II ACM symposium on document engineeringGoogle Scholar
- Rossi G, Schwabe D, Garrido A (1997) Design reuse in hypermedia applications development. In: Proceedings of the eighth ACM conference on hypertext, hypertext design, pp 57–66View ArticleGoogle Scholar
- Santos JAF, Muchaluat-Saade DC (2011) XTemplate 3.0: spatio-temporal semantics and structure. In: Multimedia tools and applications. doi:https://doi.org/10.1007/s11042-011-0732-2Google Scholar
- Scowen RS (1993) Extended BNF—a generic base standard. In: Software engineering standards symposiumGoogle Scholar
- Soares Neto CS, Soares LFG (2008) Autoria Orientada a Arquétipos. In: XXXIV Conferencia Latinoamericana de Informática, CLEI 2008, Santa Fe, Argentina (Portuguese)Google Scholar
- Soares Neto CS, Soares LFG, Souza CS (2010) The Nested Context Language reuse features. J Braz Comput Soc 16, 229–245View ArticleGoogle Scholar
- W3C (2008) Synchronized multimedia integration language (SMIL 3.0) W3C recommendation. Available in http://www.w3.org/TR/2008/REC-SMIL3-200812
- W3C (2009) Cascading style sheets level 2 revision 1 (CSS 2.1) specification. Available in http://www.w3.org/TR/CSS2/
- W3C (2009) Scalabe vector graphics. W3C recommendation. Available in http://www.w3.org/TR/SVG11/
- W3C SMIL timesheets 1.0. W3C working draft. Available in http://www.w3.org/TR/timesheets/
- Wallace M (1996) Practical applications of constraint programming. In: Constraints, vol 1, pp 139–168Google Scholar
- W3C. XHTML 1.0 The extensible hyperText markup language. A reformulation of HTML 4 in XML 1.0. Available in http://www.w3.org/TR/html/