Updated: January 5, 2010 by Stéphane Sire (Media research group)
The XTiger XML language is derived from the XTiger language (web link).
XTiger XML (XTX) defines several XML elements and their attributes which can be mixed on a host document using a special namespace. Currently it uses the same namespace as XTiger (http://ns.inria.org/xtiger) although this must be changed in the future since it is not stricto-senso compatible. For convenience this namespace is often associated with the xt prefix (e.g. xmlns:xt="http://ns.inria.org/xtiger") that will be used in the rest of this document.
Currently XTiger XML supports only an XHTML host document. The combination of XTiger XML with an XHTML host document constitutes a document template. For convenience the file is named with a ".xtd" suffix. You can also name the template document with an .html or a .xhtml suffix to be able to open it directly in a browser, but if you open it without transforming it with an XTX processor you may only see parts of the document template.
The purpose of a document template is to describe a visual presentation for a document that will be used to edit XML data. This is similar to a formular. When the document template is processed with a XTX processor it becomes interactive and the user can enter data. The XTX processor is also able to load XML data into the template and to save back XML data from the template. Hence XTX is a kind of control language that stands between the view (the XHTML document) and the data (the XML data).
The XTiger XML Language is embedded inside an XHTML host language and describe a mapping from this document to an XML Content Model.
(DATA) XML Content Model <-------- XTiger XML Language (CONTROL) -----> XHTML Host Language (VIEW)
In summary, when writing an XTiger XML template document, you should have on one hand an idea of the XML Content Model you want to edit, and on the other hand an idea of a presentation document based on XHTML that you would like your formated data looks like. The XTX processor will transform the XTX elements embedded inside the XHTML template into dynamical data entry fields that will allow to edit the document and to save the edited data to XML when finished. This is what we call pseudo-WYSIWIG editing.
XTiger: to be done
XSTL + XML: to be done
XFoms: to be done
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xt="http://ns.inria.org/xtiger">
<head>
<title>My first template</title>
<xt:head>
<xt:component name="friend">
<li><xt:use types="text">name</xt:use><xt:menu-marker/></li>
</xt:component>
</xt:head>
</head>
<body>
<p>List of persons to great:</p>
<ul>
<xt:repeat minOccurs="0" maxOccurs="*" label="persons">
<xt:use types="friend" label="name"/>
</xt:repeat>
</ul>
</body>
</html>As you can see, it contains two parts:
The example above declares a single component type named friend. This component type is included in the body section where it can be repeated between zero and a non limited number of times. Consequently, when used to enter data, the previous template can produce the following XML data documents:
<instance>
<persons/>
</instance>or this one:
<instance>
<persons>
<name>Charlie</name>
<name>Oscar<name>
</persons>
</instance>The top element instance in the XML data document is currently not defined by the template (note: this will be done soon). It can currently be set arbitrarily by the programmer when invoking the XTX processor for saving the edited data using the Javascript API.
The mapping between the document template and the target XML data model is controlled with two attributes (in green in the document example above):
XTX comes with a set of built-in component types which are ultimately mapped to editable user interface text input fields. These built-in component types allow the user to enter or to modify data into the document. Consequently a document template that does not reference any built-in component type will not allow users to input new data, at most it will allow users to repeat static parts of the document, to change their order or to choose between different parts, which is not quite useful.
The built-in component types are included in the template document with an xt:use element with a types attribute set to the unique type name of the built-in component. For instance the following declaration <xt:use types="text">name</xt:use> includes a text editor that can be used to input a name, as suggested by its default value which is put in the element content.
The XTX library can be extended with new buil-in components. This is usually done by creating a Javascript plugin which has to register it's type name to the library. This way it is possible to create many different editing interaction styles by using different plugin editors. For instance a common use of plugin editors is to create editors that constrain the input data, such as entering a date, or a number, uploading an image, etc.
The XTX library comes with 3 built-in component types which are explained below: string, text and select.
Contains xt:component
Contained in head (XHTML)
The xt:head element contains the component types declaration section of the template document. It must be present even if it is empty.
| Name | Mandatory | Value | Definition |
|---|---|---|---|
| label | no | any string, defaults to 'instance' if not defined | mapping with
the tag name for the root element
of the XML content model of the template Note: not yet implemented |
Currently XTX does not interpret the other attributes for this element which are defined in the original XTiger specification.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xt="http://ns.inria.org/xtiger">
<head><xt:head label="test"/>
</head>
<body>
<p>Empty</p>
</body>
</html>
The template above generates only one XML content model:
<test/>
Contains any XHTML content, xt:use, xt:repeat, xt:attribute, xt:menu-marker
Contained in xt:head
The xt:component element declares a new component type which can be included later on with an xt:use element. The content of the component may be any regular XHTML, or it can includes other XTX elements or both. The creation of nested components can be achieved by including other components within a component through one or more xt:use elements. This will also create nested XML data structures as the xt:use elements can be mapped to a tag name in the XML content model of the template (see below).
An xt:component may contain a unique optional xt:menu-marker element. This element is significant only if the xt:component is included in the scope of an xt:repeat element. In that case the xt:menu-marker element will be replaced by the repetition menu.
| Name | Mandatory | Value | Definition |
|---|---|---|---|
| name | yes | string | name of the type of this document, it must be unique within all the components of a template and it is used to include the component in an xt:use element |
| i18n | no | string | label that is displayed for the option that represents the inclusion of this component in the menu generated in case of a xt:use element that references multiple types; this is used for internationalization purposes of a template |
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xt="http://ns.inria.org/xtiger"><xt:head>
<xt:component name="intro">
<p>I was born the <xt:use types="string" label="date">day of month, year <xt:use>
in <xt:use types="string" label="place">city</xt:use></p>
</xt:component>
</xt:head>
</head>
<body>
<h2>Presentation of <xt:use types="text" label="name"param="shape=parent">name</xt:use></h2>
<xt:use types="intro" label="birth"/>
</body>
</html>
The template above will generate the following type of XML data:
<instance>
<name/>
<birth>
<date/>
<place/>
</birth>
</instance>Contains empty, or text node
Contained in xt:component, xt:repeat or any XHTML element that can have child elements
The xt:use element includes a component inside the document at it's position. It may include a specific component type, a builtin component type, or a list of component types. In that latter case the xt:use element will generate a selection menu allowing the user to choose at runtime the component type to include. It can only carry on a text content, which is meaningful only in the case the xt:use includes a primitive component types (it is ignored otherwise). In that case it is up to the primitive editor to interpret this content, which is usually displayed as the default content when the user has not input data yet, or no data has been loaded.
It is a good practice to set a self-explanatory default content that hints the user about the expected content. You may notice that the content of the xt:use element differs from the original XTiger specification, that used to save the document data with the document.
The xt:use element supports an experimental flow attribute which can be used to slice the XML content model into different parts which may be discontinued in regards to the template document order. This is useful for instance to split the XML content model in two parts in case of internationalization: one part may be dependant of the language, while the other part may be independant. In that case, the language dependant parts of the template can be defined in the template as usual, while the independant parts can be defined inside a separate flow. The API to serialize the XML content of a document template, which is described in the developer's guide, allows to serialize all the XML content model into a single document, or to serialize the main XML content model and the different flows into different documents. This is useful to split the XML content and to store it in different databases or tables.
| Name | Mandatory | Value | Definition |
|---|---|---|---|
| types | yes | white space separated list of type names | lists the components which can be included at the position of the xt:use, if there are several names the XTX processor will generate a selection menu |
| label | no, only mandatory in conjunction with a flow attribute | string | mapping with a tag name in the XML content model |
| option | no | "set" or "unset" | if this attribute is
present, the xt:use content is
optional,
when its value is "set" the content is set by default whereas it is not
set if its value is "unset" NOTE: actually option is interpreted if and only if types integrates a single primitive component type |
| param | no | semi-colon separated list of key=value attribute value pairs declarations | declares some options which can be set for the primitive editor that will manage the component included with this xt:use; this attribute is only taken into account 1) if the xt:use contains only one type name in the types attribute and ii) if this is the type name of a registered primitive editor |
| flow | no | string | places the XML content model that starts at the xt:use element inside a separate flow named with this attribute; it is possible to create a discontinued flow that embraces several xt:use elements by using several times the same name in the flow attribute; however in that case the flow attributes with the same name can not be nested |
See above the xt:component example<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xt="http://ns.inria.org/xtiger">
<head>
<xt:head label="minutes">
<xt:component name="listOfParticipants">
<ul><xt:repeat minOccurs="0" maxOccurs="*" pseudoLabel="name" >
<li><xt:use types="text" label="name">participant name</xt:use><xt:menu-marker/></li>
</xt:repeat>
</ul>
</xt:component>
</xt:head>
</head>
<body>
<h1><xt:use types="text" label="title">Meeting title</xt:use></h1>
<blockote>
<xt:use types="text" label="goal">Goal</xt:use>
</blockote>
<h2>Present</h2><xt:use types="listOfParticipants" label="present" flow="participants"/><h2>Decisions</h2>
<ul><xt:repeat minOccurs="0" maxOccurs="*" label="decisions">
<li><xt:use types="text" label="decision">decision</xt:use><xt:menu-marker/></li>
</xt:repeat>
</ul><h2>Excused</h2><xt:use types="listOfParticipants" label="excused" flow="participants"/></body>
</html>
If serialized as a single document, the template would generated the following type of XML content that is called a tide; the first children of the xt:tide root element is the XML content of the main document (i.e. the main flow), while each of the other first level children represents a different flow:
<xt:tide xmlns:xt="http://ns.inria.org/xtiger">
<minutes>
<title>Library decoration</title>
<goal>Define which plants we should bring to improve our library room. </goal>
<decisions>
<decision>bring a ficus</decision>
</decisions>
</minutes>
<participants>
<present>
<name>Alice</name>
<name>Bob</name>
</present>
<excused>
<name>Charles</name>
</excused>
</participants>
</xt:tide>
You may have notice that the previous example is not completely internationalized, as some text inside the template itself, which is not part of the XML content model, such as the <h2> sub-title Present, should also be internationalized. However this could be done using different templating mechanisms that depend of the server-side framework used to serve the templates themselves.
The same content that would be generated from the same template without the separate participants flow attributes would generate the following XML content:
<minutes>
<title>Library decoration</title>
<goal>Define which plants we should bring to improve our library room. </goal>
<present>
<name>Alice</name>
<name>Bob</name>
</present>
<decisions>
<decision>bring a ficus</decision>
</decisions>
<excused>
<name>Charles</name>
</excused>
</minutes>
Contains empty, or text node
Contained in descendant of an xt:component or an xt:repeat element
The xt:attribute element includes a built-in component type that will be mapped to an XML attribute in the XML content model of the document. This XML attribute will be attached to the current XML element in scope when generating the XML data. The component type name is given in the types attribute, which although in a plural form must contain only one component type name.
| Name | Mandatory | Value | Definition |
|---|---|---|---|
| types | yes | a primitive component type | sets the built-in editor that will be used to edit the attribute; this can be only a primitive component type editor (i.e. currently "string", "text" and "select") |
| type | deprecated name for types | ||
| name | yes | string | mapping withn an attribute name in the XML content model |
| option | no | "set" or "unset" | if this attribute is
present, the xt:attribute is
optional,
when its value is "set" it is set by default whereas it is not
set if its value is "unset" |
| values | no | optional white space separated list of the values allowed for the attribute | defines allowed values
for the attribute, this only
works if
the primitive component type manages a list of choices (i.e.
at that
moment this is the case only with the select
primitive component type) |
| default | yes | string | defines the value by default of the xt:attribute, if the attribute values is defined the default value must be part of the list |
| i18n | no | optional white space separated list of the labels to display for each value in the values attribute | displays a different label for each option in the menu that presents the allowed values to the user; this is useful only in conjunction with a primitive component type that manages a list of choices (see the remark above about values); if present, the order of the labels in this list must be the same as the order of the corresponding values |
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xt="http://ns.inria.org/xtiger"><xt:head>
<xt:component name="author">
<p>My name is <xt:use types="string" label="name">your name<xt:use>,
but you can call me <xt:attributetypes="string"name="nickname" default="your nickname"></p>
</xt:component>
</xt:head>
</head>
<body>
<xt:use types="author" label="author"/>
</body>
</html>
The extract above will generate the following type of XML data:
<instance>
<author nickname="your nickname">
<name>your name</name>
</author>
</instance>Contains empty
Contained in descendant of an xt:component, or of an xt:repeat
The xt:menu-marker element must be placed inside the scope of an xt:repeat element (either as a direct descendant or as a descendant after one or more type inclusions through xt:use elements). It allows to control the insertion point of the Add / Remove buttons generated by the XTX processor when transforming the repetition element.
Contains any XHTML content, xt:use, xt:repeat, xt:attribute, xt:menu-marker
Contained in any XHTML element that can have child elements, xt:component, or another xt:repeat
The xt:repeat element defines a document fragment that can be repeated zero or more times. A zero time repetition means that the fragment is optional and is not set. The xt:repeat element will generate some interaction element (a pari of Add / Remove buttons) that will be inserted at the place of the first xt:menu-marker element inside the fragment, or inserted at the end of the fragment if it doesn't contain any xt:menu-marker element.
The xt:repeat element can be mapped to a tag name in the XML content model through a label attribute, in a way similar to the xt:use element. If it is not associated with a tag name, it MUST declare in a pseudoLabel attribute the name of the first tag name that is generated in the XML content model of its fragment. This is mandatory to allow the XTX processor to correctly load XML data into the template.| Name | Mandatory | Value | Definition |
|---|---|---|---|
| minOccurs | no | number (default to 0) | minimum number of
inclusions of the content fragment in
the document, 0 means it is optional Note: currently the only supported values are 0 or 1 |
| maxOccurs | no | number or * (default to *) | maximum number of
inclusions of the content fragment in
the document, * means there is no limit Note: currently the only supported value are 1 or * |
| label | no | string | mapping with a tag name in the XML content model |
| pseudoLabel | no | string | in case the label is not defined for the entire repeated component, the pseudoLabel must give the name of the first XML tag name which is repeated in the XML content model |
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xt="http://ns.inria.org/xtiger">
<head>
<xt:head label="menucard">
<xt:component name="dish">
<p><xt:menu-marker/><xt:use types="text">dish</xt:use>
costs <xt:attributetypes="text"name="price" default="00"/> euros</p>
</xt:component>
</xt:head>
</head>
<body>
<h2>Restaurant Menu Card</h2>
<xt:repeat minOccurs="0" maxOccurs="*" pseudoLabel="dish">
<xt:use types="dish" label="dish"/>
</xt:repeat>
</body>
</html>
The extract above will generate the following type of XML data:
<menucard>
<dish price="20">Chicken and fries</dish><dish price="30">Noodles and salmon</dish><dish price="15">Rice and pork</dish></menucard>
Synopsis
<xt:use types="string" label="nickname" param="lookahead=4">your nickname</xt:use>OR
<xt:attribute types="string" name="birthdate"default="year" param="lookahead=0">
</xt:attribute>
The string primitive component type is associated with a string editor that generates a span and an input field in the document. The span displays the current content of the editor. Each time the user clicks on it, it is hidden and the input field is shown instead to edit the content. When the user validates the entry with Return, the input field is hidden and the span is shown again with the new content. The user can cancel a current entry by pressing the Escape key.
The string editor does not provide any advanced option such as automatic resizing as user's input data. The only supported option is the lookahead option that sets a number of extra characters (spaces) that will be added at the end of the content before displaying the input field for a new entry.
The string editor supports the option attribute of the xt:use or xt:attribute element that includes it. If this attribute is present it generates a checkbox from which the user can include its content into the document or not.
The content of this editor is initialized to the text content of the xt:use element, or to the value of the default attribute of the xt:attribute element.
This primitive component type exists for historical reasons and for debugging. It is recommended to use the text primitive component type instead, since it provides advanced options to control its appearance and behavior and uses less memory (it does not generate an input field for each editable content).
| Parameter | Values | Default | Description |
|---|---|---|---|
| lookahead | number | 2 | defines how many empty characters to add at the end of the edit field when it is opened, for instance if a field contains 'hello', displaying it with a lookahead of 5 will display 'hello ' (5 spaces after) |
Synopsis
<xt:use types="text" label="parag"param="type=textarea;layout=float">
Write a new paragraph here.</xt:use>
OR
<xt:attribute types="text" name="birthdate" default="year"
param="type=input;layout=placed;expansion=none" option="set"/>
The text primitive component type is associated with a text editor that generates a span in the document and either an input field or a textarea field (for multilines entry) in the document. The difference with the string editor is that the input or the textarea fields are shared between all the text primitive editors which are created inside the document.
The text editor supports two types of input or textarea fields with different layout. The float layout dynamically positions the input or the textarea on top of the content to edit when the user clicks on it (using CSS absolute positioning). The placed layout dynamically replaces the content to edit, which is stored in a span, by the input or the textarea field when the user clicks on the content. Once the editing is finished, a float field is hidden revealing the content span which is updated with the last entry; similarly, a placed field is replaced back with the content span.
The text editor supports the option attribute of the xt:use or xt:attribute element that includes it. If this attribute is present it generates a checkbox from which the user can include its content into the document or not.
The content of this editor is initialized to the text content of the xt:use element, or to the value of the default attribute of the xt:attribute element.
The text
editor is controlled by passing a list of option
declarations into the param
attribute on the XTX element that
includes it into the document. For instance the example in the synopsis
creates
a text editor with a shared textarea and a float layout.
| Parameter | Values | Default | Description |
|---|---|---|---|
| type | 'input' | 'input' | the edit field is an <input> (shared at the document level between all the instances) |
| 'textarea' | the edit field is an <textarea> (shared at the document level between all the instances) | ||
| layout | 'placed' | 'placed' | the edit field is inserted dynamically into the DOM instead of the <span> handle |
| 'float' | the edit field is placed dynamically on top of the <span> handle using CSS absolute positioning, currently the algorithm works only if the target handle is statically placed | ||
| shape | 'self' | 'self' | the shape/length of the edit field equals the current shape of the handle |
| 'parent' | the shape of the edit field equals the current shape of the parent of the handle | ||
| class | string | '' | the value of the class attribute will be set as the class attribute of the span element that displays the editor content; it will also be dynamically added to the class attribute of the input field or textarea field when editing; this allows to style the editor on a per-instance basis with CSS |
| expansion | 'none' | 'grow' | the edit field has a fixed shape/length |
| 'grow' | the edit field expands as the user types text; the direction of the expansion may depend on the implementation of the primitive editor and on the 'shape' parameter too, for instance an edit field implemented as an <input> can only grow horizontally, while an edit field implemented as a <textarea> (e.g. 'textarea' editor) will grow horizontally if its shape is set to 'self' and vertically if its shape is set to 'parent' | ||
| clickthrough | boolean | true | when switching to edit
mode the cursor will be placed
at the
character under the mouse, currently this attribute has no effects on
IE browser (note: let
me know if you know how to convert mouse position into character
selection position on IE) note: implementation still in progress |
| copyFonts | boolean | true | when true the edit field
will inherit the font metrics
'font-size', 'font-family', 'font-weight', 'color' either from the
parent of the handle if shape='parent' or from the handle itself note: not implemented (the library acts as if it were set to true) |
Synopsis
<xt:attribute types="select" label="country" default="Switzerland"
values="FranceItalySwitzerland">country</xt:use>
OR<xt:attribute types="select" label="currency" default="EUR"
values="EUR USDCHF" i18n="Euro Dollars Franc-Suisse">currency</xt:use>
The select primitive component type is associated with a popup menu editor that generates a span in the document that contains a current selection. The popup menu is displayed each time the user clicks on the span and it updates its value to the selected value.
The select primitive component type MUST be associated with an xt:attribute element because it uses its values attribute to build the options of the popup menu, and by default it selects the option defined in the default attribute.
The select editor supports the option attribute of the xt:attribute element. If this attribute is present it generates a checkbox from which the user can include its content into the document or not.
The select editor supports the i18n attribute of the xt:attribute element. If this attribute is present, the labels displayed in the popup menu are taken from the i18n list instead of the values list, so both lists must have a one to one matching. This attribute does not change the generated XML content model which is still conditioned by the values attribute.
This editor does not currently manage any parameter.
Synopsis
<xt:use types="content" label="parag">your paragraph</xt:use>OR
<xt:attribute types="content" name="favorite dish" default="chicken tikka masala"/>
This primitive component type will be associated with an editor that directly controls the document content through HTML contentEditable attribute. Hence it will be the most economical in terms of memory occupation as it will not generate any input or textarea field. It will allow gives a better WYSIWYG experience and allow to create mixed content with Rich Text Editing types of decorations.
The AXEL (Adaptable XML Editing Library) XTX processor is implemented as a Javascript client-side library which can be run inside a browser. You have the choice to import this Javascript library directly into the template file, using script tags, to make it an auto-editable template. As an alternative you can use an editing application. Such applications can be built with the library. They should allow to load templates and to edit documents with them. They should allow to load XML data into the documents and to save back the document to XML data.
The Javascript XTX processor takes as input an XTX template document. It loads the template document into the browser memory and then it transforms it, removing the XTX elements and generating adequate XHTML content to turn the document into an interactive editable document. During this transformation the processor creates some Javascript objects to control user's input and the dynamic display of user interaction elements (e.g. buttons, popup menus, etc.).
TO BE COMPLETED
The Javascript XTX processor generates some CSS attribute class attributes while transforming a template document. It then uses CSS rules to style these elements. Most of the time as a document template author you will use the standard xtiger.css which is given with the XTiger demonstration editor application (path: editor/extras/xtiger.css). But you may also redefine them or override them using an !important CSS rule.These CSS attributes are described in the table below.
As of its current development XTiger XML styling is still highly unstable and may change, hence the table below is not necesarilly up to date.
The most interesting class name is xtt-editable which is set on the handle of primitive editors. It can be used for instance to improve feedback about the editable fields by using :hover pseudo selectors.
| Category | Class (or selector) | Description |
|---|---|---|
| Internal | xtt-boundary | |
| xtt-gen-error | ||
| xtt-shadow-buffer | ||
| xt:repeat editor | xtt-repeat-left | |
| xtt-repeat-right | ||
| "text" and "string" primitive editors | xtt-editable | |
| xtt-on | ||
| xtt-off | ||
| option editor (when using a primitive component type with option="set" or option="unset") | xtiger-option-checkbox | |
| xtt-option-edit-set | ||
| xtt-option-edit-unset | ||
| "select" primitive editor popup menu (implemented with a list block <ul>) | ul.xtiger-popup | |
| ul.xtiger-popup li | ||
| ul.xtiger-popup li.invisible | ||
| ul.xtiger-popup li.selected |
| XTiger element | XTiger Attributes (mandatory) | Values for types attribute | option attribute | param attribute |
| xt:use | types label param flow (only if label is defined) |
"string" | yes | yes |
| "text" | yes | yes |
||
| list of component types | no | N/A | ||
| xt:attribute | types
(type
is deprecated) name default values i18n (only with types="select") |
"string" | yes | yes |
| "text" | yes | yes | ||
| "select" | yes | N/A |
| Primitive component type (types=...) | Allowed In | Parameters (param=...) | Values (default) |
| "string" | xt:use xt:attribute |
lookahead | integer (2) |
| "text" | xt:use xt:attribute |
type | input,
textarea |
| shape | parent, self | ||
| layout | float, placed | ||
| class | class name | ||
| expansion | none, grow | ||
| "select" | xt:attribute | N/A | N/A |