| Tal4Rdf | Silex team |
|
T4R is not the first proposal to enable presentation of RDF data. The most prominent existing approach is Fresnel.
Compared to Fresnel, T4R has a much lower level of abstraction. The distinction in Fresnel between lenses and formats provides more modularity and reusability, and Fresnel selectors automates the selection of the appropriate lense and format for a given resource. While this makes Fresnel more practical for complex applications handling uncontrolled data, this comes at the cost of complexity.
T4R’s simplicity, on the other hand, makes it easier to learn and deploy, suited to prototyping and rapid development.
Furthermore, while Fresnel only specifies an abstract presentation model, T4R, as a template language, aims at the actual rendering into a concrete syntax. Indeed, an implementation of Fresnel could rely on T4R for the actual rendering.
The choice of TAL as a template language comes from a long experience of using it in different projects, especially the Advene application.
TAL provides the advantage, over other template languages, to integrate into the XML-based output language without breaking it (see how). As a consequence, the templates can be viewed (for testing) and even edited with standard tools (like WYSISYG editors) that need not be aware of TAL itself. With a little effort, these same tools can be enhanced to allow the edition of TAL processing instructions, bringing template authoring to the reach on non-expert users.
This accessibility to non-experts is also ensured by the relative simplicity of TAL’s expression syntax. TAL uses slash-separated paths, which are quite similar to filenames and URLs with which most users are already familiar.
By default, using tal:content, tal:replace and tal:attributes, an empty node-list will render to an empty string, while a non-empty list will render as only one of its elements. This silent loss[1] of information is the price for simplicity and robustness. Indeed, combining several values in a meaningful way depends on the context (and sometimes is not even possible, consider for example tal:attributes="href foaf:homepage), hence it should not be done automatically. Since, on the other hand, in the open Web there is no guarantee that any property will have exactly one value, this would require virtually any path to be “protected” against multiple values, for example: tal:attributes="href foaf:homepage/any|nothing". This would seriously hinder the readability of templates.
Note that in some situations (e.g. debugging a template), it would be preferable to know exactly when a path yielded zero, one or several values. In these situations, the display mode can be set to strict. This makes the rendering more accurate, though less prone to breaking the result (as with the href example above): a node list of zero or more than one node will be rendered as {n nodes} where n is replaced by the number of nodes in the node list.
Footnotes
| [1] | Of courss, it only occurs at rendering: storing a node-list in a variable does not reduce it to a single node. |