Literature Markup Language - <LML />

specification

Version: 1.0 from 2009-10-06

Created: 2008-10-08/2008-12-18 2009-01-09/11 2009-01-19 2009-02-23/24 2009-10-5/6

Alternative archived static version: lml1.0.tar.gz

New (2013-04, 2013-06, 2013-11): Suggestions and Ideas for Literature Markup Language Version 1.1 - more comments and additions are welcome.

Author: Dr. O. Hoffmann (German web-page)

Index

(short index, the long index is available in the navigation, context or document information menu of the browser or in the element and attribute index).

Introduction

The big open question in (X)HTML was always and still is up to now, how to markup text and literature with meaningful elements. Because currently (X)HTML does not provide specific elements with a semantical meaning for several applications, the XHTML role attribute and a new profile XHTML+RDFa are introduced to provide authors the possibility to specify the semantical meaning of an element with a reference to another language or specification using a CURIE. Additionally the usage for rel and rev can be extended to use CURIEs to specify the relation to or the functionality of a hyperlink target precisely. WAI-ARIA defines some predefined values for role for some applications. SVG tiny 1.2 adopts the role attribute and the RDFa attributes from XHTML.

RDFa provides attributes to map RDF syntax to attribute values, which can be used to enhance the semantical meaning of XHTML documents dramatically.

Unfortunately neither (X)HTML nor WAI-ARIA nor RDFa define a complete collection for literature. This is a little bit surprising, because already the name hypertext markup language indicates, that it should be the main domain of (X)HTML to care about this. There are other resources like DAISY, DocBook, FictionBook or XLDL with a larger collection of elements with a semantical meaning and there are maybe even more resources for more or less specific applications.

It cannot really be expected, that authors have to search each time in many different resources for a proper element respectively role value, therefore it is collected, supplemented and compared here for anyones convenience and maybe as a bases for a proposal to extend the vocabulary of (X)HTML, WAI-ARIA or RDFa to get a semantically somehow more useful language. Additionally using the similar approach with RDFa and role for SVG ensures semantical meaning for text in SVG too. Because SVG is a graphics format, it cannot be expected, that this is done in a more convenient way than with such a role attribute or with RDFa.

LML elements are applicable as CURIEs for the usage as roles and with XHTML+RDFa (what is already a recommendation). Typically the attribute property can be used to define the semantical meaning of an element in more detail, that is not available in (X)HTML itself. This attribute property exists too in SVG tiny 1.2.

Alternatively to the role or property approach, because LML is an XML, it can be used directly or can be mixed with other formats to reuse the functionalities of other formats together with the semantical elements of LML.
Therefore mainly the author has the choice, how to use it, to get the best markup one can get for the intended purpose. The main advantage to use LML as its own language is, that the document depends only on one or two formats. If roles from many different formats are used, the risk is increased, that one of the referenced collections gets lost, what is not under the control of the author. And it is much more work to check many dependencies than just one or two. The advantage of a compound of many formats is, that it is typically simple to extend the functionality or semantical meaning of a document with already existing formats. LML tries to combine this, having most literature related things within LML and having additionally those extensions available for other purposes, not directly related to literature, if required.

Several samples are available to show the usage of LML. If no other host language is used or required for other reasons, a default (visual) presentation for LML is provided too, simulated with CSS as far as possible including alternative variants switching on and off the display of meta information, what is restricted somehow due to limitations of CSS. This means, with a proper interactive user interface, it is expected, that the presentation of meta information is much more effective as with this simple CSS approach. In the default style the interface is a small square icon, which is expanded if hovered. It shrinks again, if the meta area is left in the direction of the border.

This is the first version of this format - improvements and corrections are probable in the future. Suggestions, contributions and corrections are welcome - simply contact the author.

Concept

LML is an XML, therefore documents have to be at least well-formed. User-agents may render not well-formed documents up to the point of an error, to help authors to fix those errors, but this is not required. An error message including the line number of the first error should be the minimum information about an erratic document as a help for authors. Typically a meaningful fix of errors depends strongly on the content and is only possible for the author, therefore this has to be left to the author. A meaningful error message will help authors to fix errors before publication.

Because literature has in general not a really precise structure, it would be counterproductive to have a very specific definition of a structure model, therefore this remains intentionally vague to ensure, that this collection is really usable in the real world and not just esoteric. Another point for daily usage of role with CURIE is, that the values of role and therefore the element names of often used elements are short. A third important point is, that the definitions are human readable and understandable, else there is a low chance, that authors will use such a collection.
The namespace related to LML is http://purl.oclc.org/net/hoffmann/lml/ (Note, that this is a PURL; a redirect), the current address may change.
Therefore the namespace declaration may be something like: xmlns:l="http://purl.oclc.org/net/hoffmann/lml/", then for example the role containing the CURIE for the element literature is: role="l:#literature". If used within a CURIE, it is important to note, that this is a PURL for the current version. If other versions follow, there will be additionally PURLs for every version. And the current version will have references to previous versions, if there are relevant changes.

Because there is no precise structure model, there is no document type declaration or another scheme. However a scheme may be added, if a scheme language is found (or developed), which is flexible enough to cover the needs of a more complex language. Limitations of current scheme languages can be already seen with XHTML and SVG, the used scheme languages can by far not describe all restrictions, variants and possibilities of these languages, therefore already for SVG tiny 1.2 the prose specification is much more relevant and complete than any scheme.
But it might be useful to have some entities defined, for example to reuse content or to simplify the recognition of cryptic glyph numbers. For this a doctype can be provided, containing mainly the defined entities. For example predefined german Umlaute and the ligature 'ß' as in XHTML and some abbreviations look like this:


    
    
    
    
    
    
    Literature Markup LanguageLML">
    eXtensible HyperText Markup LanguageXHTML">
    Scalable Vector GraphicsSVG">
  ]>]]>

But of course, if the encoding is specified correctly within the XML processing instruction, respectively within the header, if send by a server, there is no need to mask these and other glyphs, if available directly on the keyboard. But the abbreviations of course are still helpful, if these constructions appear more often within the document and can be abbreviated with simply &l;, &h; and &s;.

Because currently there is no defined method to specify an attribute or property with a CURIE, only a few specific and a number of common attributes are mentioned here at the moment. Often literature related issues can be solved without attributes anyway. And of course attributes from other namespaces can be simply noted using the correct namespace. If the attribute values are predefined, it is obviously possible to provide them as CURIE too. Currently it is assumed, that at least some common attributes are available, an identifier like xml:id, respectively the id from (X)HTML or SVG, then xml:lang, the xmlns to indicate namespaces and the abbreviations for CURIEs, class (see SVG or (X)HTML), role. Often attributes provide meta information about the element or specific functionalities, therefore for several applications there is a related element defined for this purpose to be within the element meta. If the host language provides only these attributes for the intended functionality, then obviously those attributes should be noted too.

Current or old versions of formats often have no role attribute like versions 1.0 and 1.1 from XHTML or SVG or versions 4 or 5 from HTML. In general, because except of 'HTML5' those versions depend on a DTD, in general the author can define an extension for those formats containing the attribute, however this does not imply, that the attribute has a meaning at all. In the XMLs it is in general possible to use attributes from other namespaces with a related namespace declaration, however, current validators rely typically on DTDs and are not able to check this different dependency. If this is assumed to be important, this approach cannot be used too. LML defines therefore additionally 'non invasive' methods related to the element roles, specified only for this purpose to indicate semantic structures in old (outdated, bad designed) versions of popular formats.

The general concept is derived from (X)HTML, respectively CSS to have content either in block elements or inline elements. Additionally there are metadata elements containing meta information about the content of other elements. Some meta information is intended to be well separated from the other so called flow content, but completely accessible, other meta information is maybe part of the normal flow without a need for a specific separation.

Typically block elements are well separated from each other in presentation. Inline elements indicate phrases within text fragments inside block elements within the same line, typically without a spatial or temporal indication. Meta elements contain (meta) information about text and are presented on another logical level, however for LML this information is considered to be possibly interesting for any audience and should be accessible for anyone, not just for robots or specific helping tools, not available in any user agent.

Styling is in general not discussed here, this can be applied with an XML stylesheet processing instruction to the complete document or additionally using a specific meta information. Both reference external stylesheet documents.

Concerning animation, declarative animation with SMIL (including timesheets) or SVG is possible. For this it is required to know, which elements, attributes and properties are animatable. In LML everything can be animated except the fragment identifier (xml:id). The target element can be identified with the XLink:href, if it is not the direct parent. Attribute values in LML itself are typically no numeric values, therefore not interpolable and not additive. For them obviously only discrete, no additive and no accumulative animation is available. However for numeric attribute values or for (styling) properties with numeric values all this is possible.
animateMotion and animateTransform and maybe an animation of styling positioning properties may require the definition of an origin. In general the coordinate system of the styling language is used. Without styling (the default) the top left corner is assumed to be the origin. The x-coordinate goes from left to right, the y-coordinate from top to bottom.
For animateMotion and animateTransform the SMIL attribute origin can be used. The value is 'default' as described or the absolute coordinates in parenthesis, for example (10em, 12em) or (-5ex, 12ex) or (100px, 20%) etc. Alternatively relative coordinates can be specified using as a value first the fragment identifier of an element within the document, followed by whitespace followed by coordinates in parenthesis as for absolute coordinates for a possible offset. If the fragment identifier indicates the animation target element itself or the fragment cannot be identified within the document, the provided fragment identifier is ignored. It is possible to skip the additional coordinates in parenthesis and then the whitespace too.
Missing coordinates simply indicate (0,0). For other coordinates there are units required. Coordinates without units or unknown units are ignored. Known units are those from CSS. Percentages for absolute coordinates are related to the size of the complete document, those for relative coordinates are related to the size of the element indicated as the origin. 'size' means here the corresponding length in x- respectively y-direction independently. If the size is determined automatically, this is done without the influence of animateMotion and animateTransform.
Authors always have to take care, that the document interpreted without animation contains still the same (text) information as with animation. If the authors intend is, that the document does not contain any (text) information, it might be a good idea to indicate this with some informational text in the element desc. Obviously for documents without any (text) information it is trivial to take care, that the document interpreted without animation contains still the same (text) information as with animation. However the desc should not contain a lie concerning this issue.

Techniques

It is assumed, that there are three quite different techniques to provide text, respectively three types of text, this is prose and poetry and code (for example source code of computer programs or from markup languages). Historically, before writing was invented, there was mainly the daily conversation without a requirement for conservation and the information intended to be conserved for several generations. Still today a lot of conversation is not intended to be conserved and many people dislike techniques to do this without their knowledge.
For other information it turned out to be essential to be conserved. The archive mechanism for such information was to memorise it somehow, this was simplified by rhythm, rhyme, repetitions, music. This was called lyric or poetry. Later, after writing was invented, this survived and written poetry was structured too, to conserve better the structure of this poetry.
With the written word it was possible too, to conserve other information too and some structure was moved from poetry to this typically more unstructured information, called prose with different functionality and meaning. For any written word the method to structure is developed within the centuries from whitespace separation between words, constructions of sentences and punctuation up to the markup languages of today.
Later machines, computers were invented. It was necessary to provide those machines commands in formalised, machine readable structure or languages. Such texts are again quite different from poetry and have some special requirements. If such texts appear within literature markup language documents, such text is typically not intended to be directly interpreted by the programs, these are often only samples, to show how to structure such texts to the reader for example for educational purposes. Typically such code appears in some prose content around it, explaining the intended purpose or functionality, if the code is interpreted by a related program.

And it happens that there is poetry in a prose environment and vice versa. Because poetry content has some specific requirements for presentation and prose has not, there has to be an indication to meet those requirements. For code the structure of the code needs to be conserved too in the presentation, but for slightly other reasons than for poetry.
Many elements however can be used for both prose and poetry and their behaviour is derived from its environment, typically from the parent element. Sometimes there may be some text for which it is not important, if it is interpreted as prose or as poetry. Due to current practice it is assumed, that without an indication there is not need for a specific poetic presentation, however there is no requirement either to suppress the appearance of accidental rhythm or rhyme in such fragments, which may confuse an audience otherwise for explicitly prose content.

If an element is indicated here explicitly to be poetic or prose or code, this applies of course. If there are two or more roles explicitly given for one real element or the element itself is contrary to the given role, the situation is ambiguous. Authors may avoid this in most cases. If it happens anyway or is intended to be meaningful, the last role in the role list applies. If a parent element is explicitly indicated either as poetic or prose or code and for the element itself this is neither explicitly indicated nor identifiable by the element itself, the behaviour of the parent is used.

The indicated technique is relevant by this approach, not the text content itself or its possible interpretation. It indicates the intention of the author in a conceptual manner, nothing else. Therefore there is no need for discussion, whether the considerations of the author are wrong or right, it is mandatory for the markup - the discussion about the considerations of the author has to be performed with the author directly on another level than the markup. Therefore the document might have some quirky indications but is not wrong just because it is quirky, it is arts.

Poetry

Poetry is in general text with specific requirements for the presentation of rhythmic or rhymed content. Elements intended to contain a complete poetic text or a larger or more complex poetic fragment like poetry, poem, lyrics, dialogue may contain metadata and descriptive content like the date of creation and the name of the author as well, additionally it may contain prose elements embedding prose content related to the poetic content.

poetry

Description

Type: Block

A generic element to contain poetic content.

Relations

poem

Description

Type: Block

An element to contain a poem (not more than one poem).

Relations
  • FictionBook: poem
  • DAISY: poem

lyrics

Description

Type: Block

An element to contain lyrics (not more than the lyrics of one song) and may contain a related notation of the music as well.

Relations

wikipedia: Lyrics

st

Description

Type: Block

An element representing a strophe or a stanza or a group of verse lines of a poetic text. In general it is expected, that st contains only verse lines as content, represented by the element sl. Especially an st does not contain another st, poem, lyrics, poetry etc. Within a dialogue, an st may contain the elements sp or directive too additionally to sl elements.

Relations

sl

Description

Type: Block

An element representing a strophe line or verse line of a poetic text. In general it is expected, that sl appears as content of a poem, lyrics, st or dialogue element. Especially an sl does not contain another sl, st, poem, lyrics, poetry etc.

It is expected, that text within one verse line is identifiable to belong to this line. Especially for visual presentation within a limited space this requires some indication of an undesired line break, which appears in some formats.

Relations
  • FictionBook: v
  • XLDL: line
  • DAISY: line, if it appears within a poem
  • XHTML2: l (only poetry)

Poetry Samples

dialogue

Description

Type: Block

An element containing a dialogue fragment in a poetic form as in a drama or a song for more than one person. Typically the content consists of the elements directive, sp, st, sl.

Relations

directive

Description

Type: Block (inline)

An element containing (stage) directives in a dialogue fragment. This is a specific case of prose or metadata content within poetry content and provides more information within a drama about the appearance of a scene. This can be combined with prose elements inside or simply be used to contain descriptive prose text.

If the directive is within sl, l or p the directive is inline, else block.

Relations

XLDL: description

sp

Description

Type: Block (inline)

An element containing information about the currently speaking person in a dialogue fragment. This is a specific case of prose or metadata content within poetry content. Typically it contains the name of the speaker as prose text and this element is directly followed by st or sl elements containing the poetic text message of this speaker. If an sp element follows directly on an sp element, this indicates the previous speaker to be speechless. If there is no previous speaker for sl or st elements, this means that the speaker is anonymous from the off, but this should be avoided by the author.

If the sp is within sl, l or p the sp is inline, else block.

Relations

XLDL: speaker

Dialogue Samples

  • dialogue (using XLink to provide some link functionality for citation inside a meta element)
  • dialogue (using XHTML to provide some link functionality for citation inside a meta element and for the document title)

Prose

Prose is in general text with no specific requirements for the presentation of rhythmic or rhymed content. On the contrary the presentation should not pronounce accidental rhythmic or rhymed fragments.

prosa

Description

Type: Block

A generic container for prose with no specific requirements for the presentation of rhythmic or rhymed content.

Relations

wikipedia: Prose

address

Description

Type: Block

A container for an address, this may include a postal address, fax, email, phone number ...
Depending on the origin or different traditions, there can be specific requirements, how these data are ordered, what is not in the focus of this definition.

Relations

Note, that in (X)HTML there is an element with the same name and a more specific meaning as a container for contact information to the author or editor, this is not the case here.

beq

Description

Type: Block

A container for mathematics or in general equations or similar structures from natural science, logics or related areas. Often equations or such abstractions require some advanced presentation or markup from foreign namespaces to provide the functionality. Similar to fig beq can contain the content itself or links to external resources.

Relations
  • DocBook: equation
  • WAI-ARIA: math (only not accessible representations like raster images)

Sample for beq

Examples how to embed equations.

bibliography

Description

Type: Block

Indicates that the content of the element is a bibliography, typically external references with a relation to the content of the current document. Typically a bibliography is a specific type of prose, for the exotic case that this is not true, the author may add an additional role like poetry at the end of the role list to indicate this.

Relations

DocBook: bibliography

caption

Description

Type: Block

A caption of a table or fig or beq.

Relations

conversation

Description

Type: Block

An element containing a conversation fragment for example in an interview or a stage play or a 'frequently asked questions' section. Typically the content consists of the elements directive, sp, line, p.

Relations

directive

Type: Block

This is the same as directive from dialogue, but appears within the element conversation. It is related to non poetic content, for example in a stage play.

Relations

XLDL: description

sp

Type: Block

Description

This is the same as sp from dialogue, but appears within the element conversation. It is related to non poetic content, for example in a stage play or an interview and might be used too to indicate abstractions like 'question' and 'answer' in a 'frequently asked questions' section, even if this does not have real speakers.

The element contains information about the currently speaking person in a conversation fragment. Typically it contains the name of the speaker as text and this element is directly followed by line or p elements containing the text message of this speaker. If an sp element follows directly on an sp element, this indicates the previous speaker to be speechless. If there is no previous speaker for other content except directive in a conversation, this means that the speaker is anonymous from the off, but this should be avoided by the author.

Relations

XLDL: speaker

conversation sample

conversation Beispiel (de)

fig

Description

Type: Block

A container for a figure. The content may be a caption, more descriptive text, metadata about the figure, images, graphics or some other multimedia content (visual, audible, tactile, smellable, tactile etc) and a text alternative for all this non textual content, see switch for the method to provide alternatives.
link can be used to reference external content or the host language has to provide elements with the functionality of such content or with the functionality to embed this multimedia content, for example the SMIL media object elements or the corresponding elements in SVG or img or object in HTML4 or img in DAISY or imagedata or mediaobject in DocBook.

Relations

Samples for fig

Examples how to embed graphics.

form

Description

Type: Block

A container for a form. The functionality of the form is either provided by the host language or a specific language like XForms can be used.

Relations

HTML4: form

Sample for form

Examples how to use XHTML forms.

l

Description

Type: Block

A container for one line of prose text.

It is expected, that text within one line is identifiable to belong to this line. Especially for visual presentation within a limited space this requires some indication of an undesired line break, which appears in some formats.

Relations
  • DAISY: line, if it appears outside a poem
  • SVG: text, can be used for any text, not only prose
  • XHTML2: l (only prose)

list

Description

Type: Block

A container for a list.

It is expected, that the content is only list related elements like list items, groups or topics, meta elements. The list element can have a list type indicator attribute.

Relations

ltype

Description

Type: attribute

The element list indicates more a technical functionality, not much about the semantical purpose of a list. ltype is a specific attribute of the list or lg element. It indicates the list type of a list. If used with the role approach, a predefined value can be used with the related CURIE.

For example HTML has specific elements for this purpose, ul, ol, dl. Often these elements are more related to styling than semantics and do not cover all types of possible lists. Instead of completing this list of elements, an author can simply specify the list type with this attribute.

Obviously, if the host language does not provide the intended functionality, the author has to simulate it by styling, if possible. If not simulatable, the functionality cannot be used respectively it cannot be expected, that the functionality is available with a user-agent, that does not interprete LML itself. A typical approach might be styling.

Predefined values are:

uo
unordered, typically the list items indicated all with the same symbol, the list is not really technically unordered.
oi
increasing order, typically the list items have different indicators like numbers or letters to indicate the order. The indicators have themselves some order from begin to end with increasing order like numbers from small to large.
od
decreasing order, typically the list items have different indicators like numbers or letters to indicate the order. The indicators have themselves some order from begin to end with decreasing order like numbers from large to small.
df
definition, here the lt content is defined by the following li content. This can be used too, if only one object is defined, similar to the element dfn from HTML, what is pretty plurivalent about the question what is defined and what is the explanation. This list type corresponds to the HTML definition list.
law
for law text paragraphs, the lt contains the paragraph identifier, the li the law text of the paragraph. Typically law paragraphs have to be referenced, therefore the paragraph identifiers need to be hard-coded and not generated implicitly with the types oi or od, additionally an author may add an identifier attribute like xml:id to provide a possibility to reference each paragraph separately.
bill
for bills or invoices, the lt contains the amount of money, the li the product.
recipe
for recipes, the lt contains the amount or mass or volume,the li the ingredients.
shop
for shopping lists, lt are inside the li, one for the amount, one maybe for the price, the other content of the li is the product to buy.
none
no indication or numbering of list items (default).
project
if a project is splitted into several documents, this lists all elements belonging to one project like a book or magazine to ensure, that all documents can be gathered together automatically.
contact
for address books, telephone books etc, listing contact information about persons or organisations. The element lt may indicate an identifier, name, number etc, the li the contact information.
label
for lists structuring for example a simple form, typically then a lt contains a label for some form input elements inside li.
al
this is used for a list of link elements in a meta element for alternative language variants, the language is indicated with the attribute rlang of the element link.
ac
this is used for a list of link elements in a meta element for alternatives in another format (MIME-type), the type is indicated with the attribute type of the element link.
as(*)
this is used for a list of link elements in a meta element for (alternative) stylesheets (or timesheets) applied to the meta element target, (*) is optional with * as a wildcard for an optional string. The default style has no string, alternatives belonging together have the same string. The cascade or the priorities follow the nesting of elements. If there is no style with no string, no style is used as default. The stylesheets are only applied, if the meta element target is inside the current document. If the meta element target is another document, this list has no influence on the appearance of the other document.

Because this list is not exhaustive, it may be extended in the future. If an author wants to extend it with a currently not existing type, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the type.

Relations

none

li

Description

Type: Block

A container for a list item. li appears only in list (or in lg inside list).

Relations

lt

Description

Type: Block or inline depending on the appearance

A container for a list topic. lt appears only in list, lg or in a li. If it appears as direct children of a list or lg, it is a block element, if it appears as direct children of a li, it is an inline element. Authors should not mix these two models. If used inside the li, it should be either before or after any other content of the li. Obviously in such a case the li itself may only contain inline content, alternatively it can contain only block elements but not a mixture.

A list topic or list title or list term or list tag gives something like the heading for the following li elements, respectively the following li elements define or describe the topic. In some types of lists the list topic may be inside the li and it may be only a tag or symbol or number or marginal note like the numbering in law text paragraphs. It may contain the amount of or for the list items in a recipe or bill. Authors may avoid that there is no following list item. If there is no list item is following, it is assumed that the list item is empty.

Relations

lg

Description

Type: Block

A container for a group of listed containers. This can be used to group li elements within a list including lt, but can be used independently from list without li elements inside. The second use case works similarly to the list element, but the children are not explicitly mentioned li or lt elements. li is replaced with another element, for example for a list of authors of the document a creator element can be used with the element lg inside with the corresponding number of elements providing the names of the authors. This is a more weak list indication as the list element. The children can be inline elements too.

Relations

none, but several formats provide specific grouping elements for specific children.

Samples for lists

list type samples.

p

Description

Type: Block

A block container for text indicating a paragraph. A p typically consists of a few sentences representing a completed train of thought. A paragraph has no specific substructure and may not contain other block elements like p itself, but it can contain inline elements. Authors are discouraged to use it as a container for poetry content and may not indicate it as poetry as well.

Relations

table

Description

Type: Block

A container for tabular content. Note, that for advanced purposes, some specific attributes or styling might be required for tabular content, not defined here. In doubt it can be more useful, to use explicitly another language like XHTML to markup tables.

There are different models for the content of a table, common to all are a caption, colgroup and col.
The simplest model is to have only additional tr elements.
The next model ist to have thead, tfoot, tbody as children of table additionally and the tr inside of them.

Relations
ttype
Description

Type: attribute

The element table indicates more a technical functionality, not much about the semantical purpose of a table. ttype is a specific attribute of the table element. It indicates the type of a table. If used with the role approach, a predefined value can be used with the related CURIE.

Predefined values are:

bill
for bills or invoices with a more complex structure than the related list type bill.
calendar
for calendars, week, month, complete year, indicating for example a relation between the date of the week and the date, the week number and the date etc
comparison
for comparisons, for example for different products, objects or subjects and their properties and behaviour, appearance etc.
contact
for address books, telephone books etc, listing contact information about persons or organisations in a structured way.
group
for a group or Cayley table defining a binary operation. Sometimes it might be more effective to use MathML for this.
label
for tables structuring for example a more complex form, typically then a th contains a label for some form input elements inside td.
lookup
for tables containing data to look up something, for example numerical data from astronomy for mathematical functions, lists of physical constants, historical events.
matrix
for matrices or vectors and related mathematical structures. Sometimes it might be more effective to use MathML for this.
none
no further indication of the semantical meaning (default).
recipe
for recipes with a more complex structure that the related list type recipe.
scheduler
for tables containing dates and events to organise something, like a personal planner or scheduler or to correlate events, times and the location where and when the event will happen or happened already.
shop
for shopping lists with a more complex structure that the related list type shop.
statistics
for statistical data
timetable
for timetables of buses, trams, subways, air-planes etc

Because this list is not exhaustive, it may be extended in the future. If an author wants to extend it with a currently not existing type, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the type.

Relations

none

tr

Description

Type: Block

A table row. Inside of tr there are td or th.

Relations
  • DAISY: tr
  • DocBook: tr
  • HTML4: tr

td

Description

Type: Block

A table data cell. Due to the complexity of tables, authors may avoid unnecessary complex content inside a td.

Relations
  • DAISY: td
  • DocBook: td
  • HTML4: td

th

Description

Type: Block

A table data cell containing header information. Due to the complexity of tables, authors may avoid unnecessary complex content inside a th.

Relations
  • DAISY: th
  • DocBook: th
  • HTML4: th

thead

Description

Type: Block

A grouping element for table rows tr containing header information.

Relations

tfoot

Description

Type: Block

A grouping element for table rows tr containing footer information.

Relations

tbody

Description

Type: Block

A grouping element for table rows tr containing table data.

Relations

colgroup

Description

Type: Block

A structure element to group table columns, see the HTML4 description for details.

Relations

col

Description

Type: Block

A structure element for tables columns, see the HTML4 description for details.

Relations

Code

Code elements indicate texts in specific structures or languages intended for programs or machines to be interpreted. However if this appears in LML, this is not directly interpreted by machines as machine code, it is typically used to provide samples for example for educational purposes.

code

Description

Type: Inline

Provides fragments from programs, scripts, markup language and similar text types. If quoted from other authors, this needs additionally quoting and a citation.

Relations

bc

Description

Type: Block

A block container for code or markup. This corresponds to the code element for inline content. Provides fragments from programs, scripts, markup language and similar text types. If quoted from other authors, this needs additionally quoting and a citation.

Relations

ap

Description

Type: Inline

Indicates an attribute or property, typically for an element in a markup language. If a more detailed identification of the language is required, the attribute property can be used.

Relations

none

el

Description

Type: Inline

Indicates an element, typically in a markup language. If a more detailed identification of the language is required, the attribute property can be used.

Relations

none

ob

Description

Type: Inline

Indicates an object, function, procedure, module of a programming or scripting language. If a more detailed identification of the language is required, the attribute property can be used.

Relations

none

val

Description

Type: Inline

A value of a variable, parameter, attribute or property. Typically only required as indication outside a code context. If a more detailed identification of the language is required, the attributes datatype, respectively typeof can be used.

Relations

var

Description

Type: Inline

A variable in a programming or scripting language. Typically only required as indication outside a code context. If a more detailed identification of the language is required, the attributes datatype, respectively typeof can be used.

Relations

m

Description

Type: Inline

Indicates a matrix. The content is not the matrix itself, this is for example a letter representing a matrix.

Relations

wikipedia: Matrix

n

Description

Type: Inline

Indicates an entity or variable representing a number or scalar. Many quantities consist of a number and a unit u. The content is not the number itself, this is for example a letter representing a number. This is only intended for simple scalar objects like integers, real or complex numbers.

Relations

wikipedia: Scalar

t

Description

Type: Inline

Indicates a tensor. The content is not the tensor itself, this is for example a letter representing a tensor.

Relations

wikipedia: Tensor

u

Description

Type: Inline

Indicates a unit, many quantities consist of a number and a unit. There are international standards for units, typically those units should be preferred compared to legacy units. For example the basis standard unit for a length is m (meter), for time is s (second) for masses kg (kilogram, this is an exception were the base unit already contains a prefix). Prefixes belong to the unit as for kg, km, ms etc.

Note, that for the abbreviations the choice of lower or upper case letters is important. Caution has to be taken, that the meaning is not corrupted for example by styling. There is no whitespace between a prefix and the base unit and there should be no line break between the number and the unit, even if a small space is recommended between the number and the unit for written text (what can be realised with styling, because within the markup the unit is already separated from the number by the begin tag for the u element).

Relations

wikipedia: International System of Units

v

Description

Type: Inline

Indicates a vector. The content is not the vector itself, this is for example a letter representing a vector.

Relations

wikipedia: Vector

Samples for code elements

How to use code elements.

Elements for general use

Many elements can be used for both prose and poetry content. If they are children of a prosa or poetry element, the behaviour is derived from the parent element. If there is no parent element, no specific requirements are assumed.

Content block elements

literature

Description

Type: Block

This element corresponds to the root element of an LML document. Every content is literature, therefore is everything included in the literature element. There is often no need to use this element within a role attribute, because the host language has its own root element. But in a format not related to literature it might be useful to indicate clearly a change from something else to literature.

A second functionality is to separate embedded content from other authors. For this within the document there is another literature element noted, containing the independent content respectively document fragment.

version
Description

Type: Attribute

The element literature has a specific attribute version, indicating the LML version of the current document (fragment). The value is a string, containing a version information, for the current version one may write: version = "1.0". Within another host language using literature as a role value, one may use the attribute on the same element with an LML prefix as usual for attributes from foreign namespaces. Without a version indication, the current/latest version is assumed (whatever this means, depends on the user-agent; human readers might be able to guess this better from the date, a document was published too).

If LML fragments are used in compound documents and there is more than one version of LML in the future, it might be useful too, to indicate which version is meant. Authors are recommended to use a literature element with a version attribute in such a case for larger fragments; if no literature element is used as container, authors may reference the version with a CURIE in a role or property attribute.

Relations

Literature samples

A small anthology of flash fictions.
Obviously most other samples are samples for literature too, this mainly shows nested literature elements.

abstract

Description

Type: Block

An abstract is a summary, typically at the top of an article or report. This is especially usual at the top of scientific articles.

Relations

ackno

Description

Type: Block

Acknowledgements related to the documents, an expression of thanks to somebody for ideas, discussion, typically at the end of the document or article.

Relations

act

Description

Type: Block

An act of an stage play or drama etc.

Relations

XLDL: act

acting

Description

Type: Block

A container for a list of characters typically at the beginning of an act or scene of an stage play or drama etc.

Relations

XLDL: acting

appendix

Description

Type: Block

Container for an appendix. Typically if present this is appended to the end of a book, article, report or general a larger piece of literature. The issues of an appendix are somehow related to the main part of the rest, but not directly in the focus of the theme. Often it helps to understand the main part.

Relations

DocBook: appendix

bq

Description

Type: Block

A container for a quoted text. The cite element provides the information about the source, respectively the author. Typically content from other authors is quoted, and only if mentioned in relation to the current theme and within the current document. This is not necessary, if the other related element is already indicated as independent article (or report) in a collection from different authors, if for each of them is unambiguously specified, which are the authors of each article within the article.

Relations

Samples for bq

chapter

Description

Type: Block

A chapter is a larger part of a book or another larger document.

Relations

co

Description

Type: Block

Often in a magazine, newspaper or an online portal not really related text fragments are jammed together in one document, therefore there is not really only one theme per document. co (component) indicates such a fragment. In contrast to this for example a group of chapters and sections share close relations and the same issue; independent content from different authors are typically indicated either as quotings or with additional literature elements. For components such a separation by author is not required or does not exist. Typical components of magazines or newspapers of online portals are for example a weather forecast, a column or gloss, a news section or advertisement, jokes, cartoons, dictum of the day. While the content of such components changes regularly, the type of the content remains the same for a longer time.

Relations

comment

Description

Type: Block

A comment about another text fragment, typically from another person than the author. This appears often at the bottom of online articles or in blogs, guest books, forums. Of course the author of the comment should be identified too. This is different from a quotation, because normally the author does not quote a comment, the commentator adds the comment himself. Because it is closely related to the issue of the document, this is better than using the element literature to indicate something completely separated or the element co indicating some completely different content.

Relations

none

conclusion

Description

Type: Block

A fragment containing a conclusion or summary typically at the end of a scientific article.

Relations

none

dedication

Description

Type: Block

A dedication or inscription, typically somewhere at the beginning of the document.

Relations

epigraph

Description

Type: Block

A specific type of quotation or inscription at the beginning of a document or document section.

Relations

epilog

Description

Type: Block

An epilog(ue) or afterword of a book or larger article.

Relations

g

Description

Type: Block

A generic block container to indicate a group of elements or text fragments. This is typically used as a container, if there is no other element with a semantical meaning fitting to the intention of the author. Typically a host language will have such a container anyway, there is not need to use this as a role value, but this maybe is useful, if LML is used as the host language itself.

If an author uses this element, because no other element fits to the intended semantical meaning of the text, this may indicate, that there is a semantical gap in the current version of LML. Before this generic element is used, authors may check again, that there is no other element fitting to the intended meaning. Alternatively it is possible, that the intended meaning should be checked again, if this is meaningful.

But there are some applications for a generic container, for example related to the limited capabilities of the used styling language. This cannot be changed with LML, but the usage of a generic container avoids at least the corruption of the semantical meaning with a wrong usage of a meaningful container for the wrong purpose.

Relations

glossary

Description

Type: Block

Container for a glossary. A glossary is a separated part of a project containing a list of words, idioms, expressions, phrases often used in the project and required to understand the content of a project. This helps the reader especially, if the idioms are more precisely defined as in the general use or not used at all in another context.

Relations

DocBook: glossary

h

Description

Type: Block

A heading or title of a chapter or section or otherwise separated part of content. Because the heading belongs to this section or part and is therefore expected to be inside the section or part and not before.

Relations

hs

Description

Type: Block

A subheading or subtitle of a chapter or section or otherwise separated part of content. This is intended to follow after the related (main) heading related to the same fragment and does not indicate another subsection or part of the content as for example the h1 - h6 cascade indicates for (X)HTML. In some rare cases something like a subheading may precede a heading too, this is not excluded for the usage of this element.

Relations

help

Description

Type: Block

Container for a helping text. Internet projects and interactive applications may need some additional helping suggestions for users, this can be gathered in a help container. With such a structure it is easier to find such a help. Additional information in the meta element of the help may indicate to what the help is related, if this is not obvious.

Relations

This is for example available in (X)HTML as a value for the attributes rel and rev, not as a specific element or attribute. Of course, if rel and rev can reference a help, this should be identifiable too.

Description

Type: Block

There are some stereotype constructions within multiple document projects, especially on web pages at the top of the document or some larger document fragment to contain a heading (including sometimes an image or logo) for a larger project like a book or magazine to indicate such a conception of a larger construction and to identify the project as somehow unique. Sometimes this is called 'corporate design'. This is the element to contain such information. One advantage is, that for non visual presentation the user can simply skip this document fragment, if identified to be already known.

Relations

'HTML5': header

Description

Type: Block

There are some stereotype constructions within multiple document projects, especially on web pages at the bottom of the document or some larger document fragment to contain some stereotypes like contact data, copyright notes, repeated content for a larger project like a book or magazine to indicate such a conception of a larger construction and to identify the project as somehow unique. Sometimes this is called 'corporate design'. This is the element to contain such information. One advantage is, that for non visual presentation the user can simply skip this document fragment, if identified to be already known.

Relations
Description

Type: Block

A logo is a construction to identify a project, company or person typically represented with some graphic-text combination, maybe contained in a figure. If the logo is only available for a specific representation, for example a graphical or acoustical (jingle) sign, it is expected, that logo contains at least a generic text alternative for example as a descriptive meta information.

Relations

preface

Description

Type: Block

A preface, prologue, foreword or introductory words of a document.

Relations

s

Description

Type: Block

A section is a larger part of a book or another larger document. Or it is a section of a chapter. If both is used, a chapter may contain sections, but a section may not contain chapters. s may contain s themselves, such subsections have no specific elements, the section level has to be determined according to their nesting.

Relations

scene

Description

Type: Block

A scene of an stage play or drama etc.

Relations

XLDL: scene

Block samples

Samples for several block and inline elements.

Content inline elements

a

Description

Type: Inline

Indicates an anchor to identify a document fragment. Note, that the host language has to provide the functionality, especially it is required, that such an element has an attribute containing fragment identifiers as xml:id. This covers only the functionality of an anchor, not that of a (hyper)link. An a element might be empty or might contain some content. It defines the (possibly stylable) position of the start of the element representation, even for an empty anchor this is defined. This indicates already, that the typical use case might be different than in older HTML versions, typically it will be an empty element, because else it is more convenient for authors to use the related element directly. The a element is not intended to group other content, it defines only a target for a reference and has no other semantical meaning or functionality.

User agents may indicate an anchor or any other element with an identifier on demand including the fragment identifier to simplify for example citation of document fragments.

Relations

HTML4: a (only as anchor)

Today many written and spoken texts are full of abbreviations - and many people do not know the meaning or do not even know, if the abbreviation is spoken as a word or as single letters. A few elements try to simplify the situation a little bit. And authors should provide the meaning of an abbreviation at least once per document as metadata within the used abbreviation elements or alternatively within a glossary including references from an abbreviation to the glossary. Intentionally the element names for abbreviations are not really short. This might help authors a little bit to avoid the usage of superfluous abbreviations in favour of the complete phrase for better understandability.

abbr

Description

Type: Inline

An abbreviation or shortcut of a word, term or phrase. Examples are abbr., etc, Dr., Prof., JPEG, ok, ff.
acronym, init and syla can be used for specific types of abbreviations. An even more specific case is a u (a unit respectively the shortcut for it in this case). If some abbreviation does not belong to these types, the generic abbr is used. In doubt about pronunciation, the meta element phon can indicate the pronunciation.

Relations

acronym

Description

Type: Inline

A specific abbreviation, typically a word made from key letters of a group of words, spoken as a word, not as a group of letters. Examples are DAISY, LASER, RADAR, NATO. Note that some acronyms like laser or radar developed to quite common simple words, for those words it is not necessary anymore to indicate them as acronyms, if intended to describe the related object or activity, not the original abbreviated process or principle.

Note that there is more than one explanation of the word 'acronym' in some languages, however this is only an element name and this definition here applies for the element. For other meanings some other elements for abbreviations are available.

Relations

init

Description

Type: Inline

A specific abbreviation or shortcut of a word, term or phrase, sometimes called initialism, typically made from key letters of a group of words, each letter spoken separately, not as a word. Often for the first letter of each shortened word a capital letter is used. Examples are SVG, HTML, MathML, LML.

Relations

wikipedia: Initialism

syla

Description

Type: Inline

A specific syllabic abbreviation or shortcut of a word, term or phrase, typically made from key syllables of a group of words, spoken as one word. Examples are Interpol, Gestapo, Stasi.

Relations

wikipedia: Syllabic Abbreviation

allegory

Description

Type: Inline

Indicates an allegory, parable, simile, if the author wants to pronounce it, here just the short ones, because it is inline content. The very short form is typically more a methaphor.

Relations

wikipedia: Allegory

me

Description

Type: Inline

Indicates a metaphor, if the author wants to pronounce it. An allegory is typically a longer variant, a metaphor consists typically only of one or a few words.

Relations

wikipedia: Metaphor

br

Description

Type: Inline (and empty)

Indicates a line break within some text. The br is intended to be an empty element, this means it may not contain any content. Content within the element is not impossible, but has no semantical meaning.

Indicated line breaks may have different purposes - typically it is a very weak structure this indicates, maybe within a p only a small break or separation of two (or more) units creating only together the idea provided by the paragraph. Or within a verse line of a poem it may indicate a specific exotic use case in a non classical poetic form. Because this element was abused in (X)HTML as an element to structure or to style content, authors are explicitly discouraged here to use it for such purposes.

In SVG tiny 1.2 the related tbreak is introduced, because SVG tiny 1.2 has no specific elements to structure text depending on its semantical meaning.

Relations

contradiction

Description

Type: Inline

Indicates a contradiction. Contradictions are a common issue in languages and are repeatedly discussed. To avoid confusion, such intentional construction can be indicated with this element.

Relations

wikipedia: Contradiction

d

Description

Type: Inline

An inline separator (stylable dot) to dissociate text content, for example in a list group of links. There is no specific styling or presentation. This is mainly recommended to be used as a separator for links directly followed on each other to simplify the recognition of the separation for screen-readers and similar non visual presentation programs. This is better than to use arbitrary glyphs as separators, what can be irritating for the audience of a screen-reader. Within a list group this is typically used as an empty element within the element representing the list item either at the beginning or at the end. Alternatively the separator element can be the list group item itself, containing in this case the listed content.

Relations

none

del

Description

Type: Inline or block

Indicates a deleted fragment. For historical reasons or for comparison such a passage might be still interesting, therefore it is not completely removed, often a new or modified fragment replaces it using the element ins. This element introduces no further separation from other content as block elements typically do, but it requires an unambiguous indication, that the content is not valid anymore.

Relations

HTML4: del

ins

Description

Type: Inline or block

Indicates an inserted fragment. For historical reasons or for comparison it might be interesting to indicate, that a passage is inserted into some content, typically later after a revision. This element introduces no further separation from other content as block elements typically do, but it requires an indication, that the content is inserted (later).

Relations

HTML4: ins

deco

Description

Type: Inline or block

Indicates a document fragment to be decorative only. This is some content only available for some specific type of presentation, for example visual or some construction providing some background noise, which therefore does not contain any information relevant for the intention of the document. Especially a user-agent without the capabilities to present this content may leave it out of his presentation without further notice to the user and without changing the meaning or intention of the author.

Relations

WAI-ARIA: presentation

em

Description

Type: Inline

Emphasised content. To be used, if some phrases are more important than phrases around it. Emphasised content can be emphasised even more by using just another em - consider alternatively or additionally the usage of strong.

Relations

strong

Description

Type: Inline

A strong emphasised passage of content. Compare element em.

Relations

eq

Description

Type: Inline

A container for a inline mathematics or in general equations or similar structures from natural science, logics and related areas. Often equations or such abstractions require some advanced presentation or markup from foreign namespaces to provide the functionality. Similar to the related block element beq eq can contain the content itself or references a resource with a link.

Relations

DocBook: mathphrase

Sample for eq

Examples how to embed equations.

fp

Description

Type: Inline

A foreign phrase, a word or short phrase from another language, not assimilated. If such a foreign word is not common in the primary language of the document, it can be expected, that such a phrase is explained respectively translated for example in a related meta element.

Some social circumstances can result in a mixture of quite different languages, for example so called 'denglisch' results from anglicisms and pseudo-anglicisms in the german language. This is often not understandable for a certain amount of german speaking or english speaking people, therefore there is a requirement to explain such anglicisms and even more pseudo-anglicisms to the general public, if used at all.

Relations

DocBook: foreignphrase

hypothesis

Description

Type: Inline

Indicates a hypothesis, presumption or assertion to be examined in a text.

Relations

wikipedia: Hypothesis

lie

Description

Type: Inline

Indicates a lie, fraud, trickery or cheat. Of course, if something is intended as a lie to the reader, an author will not markup such lies, but in some kinds of texts or fictions such a markup might help to inform the reader about a lie, the protagonists do not expose yet.

Relations

wikipedia: Lie

Description

Type: Inline

Indicates a (hyper)link to another resource, document or a document fragment. Note, that the host language has to provide the functionality or a language like XLink has to be used to provide the technical functionality of a link.

Note, that XLink provides the possibility too, to embed other documents, for example raster images.
A user agent should indicate referenced external content in both cases to ensure, that the user is able to identify the referenced content. This might be necessary too for legal reasons and to respect authors rights of the referenced content to separate such unproblematic referencing from quotation or republishing of foreign content.
For a visual presentation the size of the embedded content might be important. Often this can be derived completely 1) from styling or 2) from the embedded content. 3) If this is not possible, for example if an SVG document provides the size only in percentage, the link is treated as an (inline-)block element, this means, the width expands automatically to the size of the parent element, correspondingly to CSS width: auto for block elements. If the height is known and the aspect ratio is preserved, this is used instead to determine a proper width. If the width is determined automatically as described and the aspect ratio is preserved, the height is calculated from the aspect ratio. If the aspect ratio is not preserved and there is no other information for the height indicated, the height is assumed to be the same as the width. Authors are strongly recommended to avoid situations with completely missing information, they should a least provide some information about the aspect ratio to ensure a useful display.
For embedded timed content like video or audio it is expected, that the user-agent provides an interface on demand to begin, end and pause the timed element. Additionally the user-agent may provide the functionalities to search forward and backward. Timed content referenced with XLink:actuate="onLoad" starts with the onLoad event for the referenced document automatically. Timed content referenced with XLink:actuate="onRequest" begins with a begin within the user-agents interface. In this case the user-agent has to indicate, that the resource needs to be activated. 'other' and 'none' is not expected to be embedded, if specified anyway, they behave as 'onRequest'. LML itself has no further functionality for the author to have influence on the timing of embedded content. If this is required, a specific format like SMIL or SVG can be used as a component or embedded resource to provide such a functionality in a declarative way.

XLink attributes
Description

Type: Attribute

If XLink is used, the following attributes are intended to have specific values for this type of link:

href
"URI"
the URI or IRI of the link target.
type
"simple" (Other types are available in XLink, but are not further discussed here, the general definition can be found in XLink.)
title
"string"
a title for the arc of the hyperlink.
show
"new | replace | embed | other | none"
'new' opens the target in a new window or tab - the exact behaviour depends on the user preferences, how to present new content.
'replace' replaces the current document. If the document is embedded itself in another document, it does not replace the embedding document(s) too, for this the host language has to provide advanced syntax.
With 'embed' the other document is embedded inside the current document, like for example an image in SVG or an object in (X)HTML.
'other' is related to references to external stylesheets or timesheets or scripts or the reference to other parts of the project. LML provides the markup to indicate this relation.
'none' means simply no presentation - the user may list such links additionally as optional referenced content separated from the current document, similar to meta information. LML may provide markup to indicate what to do with it.
actuate
"onRequest | onLoad | other | none"
'onRequest' means typically a user interactivity like an activation or click on the link content. If the link is empty, the user-agent should provide an indication to activate the referenced content.
'onLoad' means an activation with the onLoad event, typically for external stylesheets, timesheets or scripts, static raster images
'other' is related to the reference to other parts of the project. LML provides the markup to indicate this relation.
'none' means a deactivation of the link functionality. The user-agent may provide a separated indication of the referenced content.
role
"URI"
referencing a document (fragment) indicating the role of the link target.
arcrole
"URI"
referencing a document (fragment) indicating the role of the arc of the link.
type
Description

Type: Attribute

The link element has an attribute type to indicate the content type (internet media type, formerly called MIME type) of the referenced document. In case of embedded content this can be useful as a hint. Implementations may choose to not fetch and embed formats that they do not support. Note that if an internet media type is returned by the server, the server metadata is authoritative over the type attribute. The user agent may use this attribute or the server information to decide, whether it is useful to fetch the referenced content or not. To choose an alternative within a switch element the related typec has to be used.

For a list of internet media types, see the IANA media type registry.
For a list of types for audio and video codecs, see the IANA codec registry and RFC2361.

For some formats like audio or video it might be useful to provide information about the used codecs. Other formats like SMIL might require often more than one internet media type for some useful presentation.

Therefore the value is a whitespace or comma separated list of internet media types (or codecs) or media type or codec groups.
An or-group is indicated with parenthesis, '(' at the beginning, ')' at the end.
An and-group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups.
A single type evaluates to true, if it is interpreted.
An or-group evaluates to true, if at least one of the specified types, respectively groups directly inside is interpreted.
An and-group evaluates to true, if all specified types, respectively groups directly inside are interpreted.
This attribute evaluates to true, if all specified types, respectively groups directly inside are interpreted.

Some more advanced formats may provide alternatives themselves, as LML, SVG or SMIL. In such a case, that alternatives can be indicated with an or-group.
For example type = "({image/svg+xml image/png} {application/xhtml+xml image/png} {text/html image/gif})" indicates, that either SVG and PNG are required for a proper presentation or XHTML and PNG or alternatively HTML and GIF. Because support for PNG and JPEG/JFIF is required anyway in SVG, there is no need to indicate them additionally, therefore in the first item this can be skipped.

LML has currently no registered media type, for the usage within type one may use "application/x-lml+xml". For the header send by a server one may use this too or simply "application/xml".

rlang
Description

Type: Attribute

The link element has an attribute rlang (reference language) to indicate the language of the referenced document. This corresponds to the attribute hreflang in (X)HTML. The value is a language identifier as for xml:lang.

hint
Description

Type: Attribute

The link element has an attribute hint to indicate, that external content is referenced (what can be relevant for example in relation to author rights especially for embedded content).

Possible values are the default 'none', 'same' and 'other'.
'none' means, that no specific hint is intended by the author. Concerning authors rights this implicates no statement at all.
'same' means, that the referenced content belongs to the same area or project than the referencing document. No specific hint is required.
For 'other' this indicates, that the referenced content belongs to another area or project (with other author rights), a noticeable hint should be provided by the user-agent to indicate the change of areas or claims.

Relations

name

Description

Type: Inline

Represents the name of a person, location, organisation or product, especially useful to avoid confusion with the same words not used as a name to identify a subject or object. Typically a name is intended to identify an individual subject or object, not a general representation of subjects or object classes. Under some circumstances the reader may have problems to identify a name as a name, this can be avoided with this element. The element itself provides no more information about the class of subjects or objects, the named entity belongs to. For this additional attributes like typeof or property can be quite useful, if required.

Relations

neo

Description

Type: Inline

Indicates a neologism, a new word creation. If the meaning is not obvious, the author may want to explain it with some meta information.

Relations

wikipedia: Neologism

ph

Description

Type: Inline

A generic inline container to indicate a phrase or a group of elements or text fragments of inline content. This is typically used as a container, if there is no other element with a semantical meaning fitting to the intention of the author. Typically a host language will have such a container anyway, there is not need to use this as a role value, but this maybe is useful, if LML is used as the host language itself. One helpful application can be to use it to add some additional meta information and explanations with an element meta to the phrase, if it needs further explanation and does not belong to the meaning of another inline element. This element may be used to add additional styling too.

Relations

q

Description

Type: Inline

An inline quotation. The cite element provides the information about the source, respectively the author. See cite and the related block element bq for more details.

Relations

Samples for q

Examples how to quote.

ruby

Description

Type: Inline

Minimal Content Model: (rb, (rt | (rp, rt, rp)))

A container for ruby notation.

Relations

XHTML (ruby): ruby

rbc

Description

Type: Inline

Minimal Content Model: (rb+)

The ruby base container, contains rb elements. Only one rbc element may appear inside a ruby element.

Relations

XHTML (ruby): rbc

rtc

Description

Type: Inline

Minimal Content Model: (rt+)

The ruby text container, contains rt elements. One or two rtc elements may appear inside a ruby element to associate ruby texts with a single base text, represented by an rbc element. More than two rtc elements must not appear inside a ruby element.

Relations

XHTML (ruby): rtc

rb

Description

Type: Inline

Minimal Content Model: (PCDATA | Inline - ruby)*

The ruby base element. For simple ruby markup, only one rb element may appear. For complex ruby markup, multiple rb elements may appear inside an rbc element. Each rb element is associated with a corresponding rt element, for fine-grained control of ruby presentation.
The rb element may contain inline elements or character data as its content, but the ruby element is not allowed as its descendant element.

Relations

XHTML (ruby): rb

rt

Description

Type: Inline

Minimal Content Model: (PCDATA | Inline - ruby)*

The ruby text element. For simple ruby markup, only one rt element may appear. For complex ruby markup, multiple rt elements may appear inside an rtc element. Each rt element is associated with a corresponding rb element, for fine-grained control of ruby presentation.
The rt element may contain inline elements or character data as its content, but the ruby element is not allowed as its descendant element.

rbspan
Description

Type: Attribute

The rt element has a specific attribute rbspan. In complex ruby markup, the rbspan attribute allows an rt element to span multiple rb elements. The value shall be an integer value greater than zero ("0"). The default value of this attribute is one ("1"). The rbspan attribute should not be used in simple ruby markup, and user agents should ignore the rbspan attribute when it appears in simple ruby markup.

Relations

XHTML (ruby): rt

rp

Description

Type: Inline

Minimal Content Model: PCDATA*

The rp element can be used in the case of simple ruby markup to specify characters that can denote the beginning and end of ruby text when user agents do not have other ways to present ruby text distinctively from the base text. Parentheses (or similar characters) can provide an acceptable fallback. In this situation, ruby text will only degrade to be rendered inline and enclosed in the fallback parentheses. This is the least inappropriate rendering under the condition that only inline rendering is available. The rp element cannot be used with complex ruby markup.

Relations

XHTML (ruby): rp

samp

Description

Type: Inline

A sample, for example for some markup, program, script or any other sample an author needs to provide to explain something.

Relations

sen

Description

Type: Inline

A sentence.

Typically it is not required nor even desired to markup any sentence. If this element is used, it pronounces the content as something like a theorem or proposition or an edge hypotheses or theme of a complete discussion.

Relations

DAISY: sent

sub

Description

Type: Inline

A subscript, typically used in simple representations of an index in a formula, for example in the chemical formula for water the indicator '2' for two hydrogen atoms: H2O.

Relations

sup

Description

Type: Inline

A superscript, typically used in simple representations of an index (top) in a formula or an exponent, for example the top x in ex = exp(x) or as an indicator for the spin degeneracy of atomic or molecular states like 2P1/2.

Relations

time

Description

Type: Inline

Indicates a date, time interval or period. A subset of the international standard ISO 8601:2004 for date and time is used to provide an understandable content. For a date this looks like ±YYYY-MM-DDThh:mm:ss.fZ. Not required time information can be shortened, especially the complete date fraction or the complete time fraction including the separator 'T'. Therefore for a date this looks like ±YYYY-MM-DD, for a time hh:mm:ss.fZ, where .f can be skipped too as :ss.f can and :mm:ss.f. Or for a low accuracy time information one may note something like ~±YYYY. The time zone indicator can be skipped to indicate locale time, in such a case the author should identify the location next to the time information, but not inside the time element. Of course a better approach is to note the time zone directly instead of the Z: ±YYYY-MM-DDThh:mm:ss.f±hh:mm, where the last :mm is optional again.

Durations are possible with the 'P' indicator syntax, for example:
PYYYY-MM-DDThh:mm:ss.f
or in combination with a begin date:
±YYYY-MM-DDThh:mm:ss.fZ/PYYYY-MM-DDThh:mm:ss.f
or with an end date:
PYYYY-MM-DDThh:mm:ss.f/±YYYY-MM-DDThh:mm:ss.fZ

For details about the notation see the definition of the element created.

Note that due to changes and corrections of the calendar system in previous centuries and the current system of leap seconds there is no trivial relation between a precise time interval, period or duration and two dates according to this notation. For this a notation of TAI is necessary. Therefore alternatively the time can be represented as TAI seconds since 1958-01-01T00:00:00.0 in such a way: 'TAI±t.f', where 't.f' is a float representing the number of seconds including possible fractions of seconds. Durations are always noted in TAI seconds, if no begin or end date is provided. Therefore a day has exactly 24 hours or 86400 seconds, a month 30.4375 days or 2629800 seconds, a year 365.25 days or 31557600 seconds - due to these strange numbers for the lengths of months and years, it can be a good idea to avoid larger units than days for durations. Therefore deviating from ISO 8601:2004 one can indicate durations too with an arbitrary number of digits for hours, if leading 'TAI' is used. And one can indicate an arbitrary number of digits for days, if the 'T' after is not skipped.

If an author prefers another ambiguous format or notation, the proper solution could be to provide the sloppy notation in the flow text like 'last saturday' or 'at my 30th birthday' and to add the proper time only as meta information.

Relations

timec

Description

Type: Inline

Indicates the current time. Sometimes documents generated by (server sided) scripting or declarative animations provide clocks with the current time. To distinguish this from arbitrary time information or to provide a simple text equivalent for accessibility reasons one can use this element. The content is the same as for time without the possibility to indicate time ranges or durations, what is meaningless for the current time. After generation of the content the time information is typically not updated, if not animated. Readers have to take into account this for generated static content or if they save such an output to their local file system. Additionally the output from a server is always delayed, authors may try to compensate that for an estimated time for the first view. Readers have to take into account inaccuracies tolerantly.

Relations

none

Inline samples

Samples for several block and inline elements.

Metadata elements

Metadata is considered to be data about a document or document fragment. Corresponding to the higher level of abstraction of these data, some metadata are typically well separated from the fragment, they are about, the so called flow content, but the relation is unambiguously. Therefore separated metadata are typically presented additionally to the document itself, but not embedded inside 'normal' flow content of the document. For example such meta information is available on demand or in a different presentation area like a popup with a content menu or a specific meta information area of the user-agent. This happens for example for link elements in (X)HTML.

(X)HTML as an already older digital format does not provide convenient possibilities to provide much metadata identifiable as such and well separated from other flow content. Therefore metadata elements may appear within the other flow content area too due to the limitation of the used host language or the user-agents. Authors may use styling to simulate this functionality in such a case.

Additional to those separated metadata information - often due to the limitations by the format or the presentation as already mentioned - there is a longer tradition in providing meta information directly within the normal content flow, for example as a project navigation menu or an index, because this metadata is urgently required to get access to the meta information. This is possible too with some metadata elements, but the results may be plurivalent if there is no unambiguous relation between the meta information and the content it is talking about.

The meta element is a container, where the meta information is always clearly separated from other flow content. Content of a meta element is not intended to flow within the content before and after it.

If there is no pointer to specify it differently, the meta information inside meta is about the parent element. Then the parent element is the target of the meta information. For other metadata elements if no pointer specifies it differently, the meta information is about the next parent literature, bq, respectively q or comment element, if there is none of these elements at all, it is about the document itself. With the RDF nomenclature the target is the subject of the meta information.

Direct children of the meta element are always considered as block elements. If other metadata elements than meta occur outside of the meta element, their appearance is indicated as (block) or (inline).

The semantical meanings of the metadata elements inside the meta element indicate the predicate within the RDF nomenclature. This can be done too with the attributes about, rel or rev or the related constructions with the elements rel or rev.

The content of the metadata elements or the content of the content attribute is the object within the RDF nomenclature. External (or embedded) objects can be specified with an attribute to reference content as the XLink:href. Another method is to use the attribute resource. Different from the XLink functionality resource does not provide a direct access to the reference object, but if a URI is provided, the access should be available on demand.

If the element, such a metadata element is inside, only allows inline content, such a metadata element is considered to be inline. On the other hand, if the element allows both inline and block, but the other children of the element are consistently block (inline) elements, the metadata elements may be considered to be block (inline) too, however it is a much better approach, if the author puts already a fitting element around it to get a clean structure. The same rule applies for metadata elements being children of metadata elements not being direct children of the meta element. However authors should avoid such complicated situations of mixes of block and inline children in the same level in general and should structure always consistently. Due to the intentionally vague structure model of LML, authors can technically mix a lot of elements somehow, but they are recommended to provide a clear structure for better understandability.

meta

Description

Type: Meta (block)

A container for metadata or meta information about a document or document fragment. Any element can have meta element(s), even if not mentioned in the element definition. The meta element(s) should be before other children elements, maybe except title of the root element of the document. If title is provided outside the meta, it is recommended to place it before the meta element.

Content inside a meta element is always considered as meta information, presented typically not directly within the 'normal' progress or flow of presentation.

If not defined otherwise within the meta element, the meta element content provides information about its parent element. Part of the additional presentation of this content is the identification of the content the meta information belongs to. It is recommended, that the identification works in both directions, the meta information points to the target of the meta information, the target points back to the related meta information. For both are specific metadata elements provided.

meta is expected to contain structured information, this can be constructed with the same elements used to provide 'normal' flow content or it can be done with a specific language like RDF but typically not both in one meta element.

meta will typically not contain another meta element as a direct child or in general typically a meta will not be the target of a meta. But there can be more than one meta element in one element, especially if the different meta elements provide alternative approaches for meta information about the same content or if the meta information is addressed to different fragments.

If a meta element anyway is the target of a meta element, this might be only done to provide unproblematic meta information about the target meta element itself. Cycling structures or self descriptions are strictly limited to basic information, else this may imply inconsistencies and contradictions due to the G÷del problem. This means, that self-contradictory constructions like 'this statement is wrong' are technically possible and an old fashioned joke, but not expected and meaningless as meta information.

Relations

title

Description

Type: Meta (block or inline)

The title of a complete piece of literature, often included in a literature element. In this case it is a block element with some prominent appearance. Within a citation it can indicate the title of a work, a part is quoted. For headings of chapters, sections and other fragments the related elements h and hs are used instead.

The title represents the complete work, therefore if chosen for an own work, it needs to be quite expressive and usable to identify the document if used for example as reference text in a citation.

If used as document title, the title element should be on top of the content of the literature element of the document respectively in the meta element applicable for the literature element of the document. If it is the title of the root literature element, the meta element should be always on top of the content of the root element to simplify the identification of the document title. If there are plurivalences, the topmost direct child title of the root element respectively the topmost title in the topmost direct child meta of the root element is used as document title, whatever comes first.

The document title is often used in a user-agent as a heading of the viewport, the content is presented in, therefore the place for this purpose is limited, anyway the title should be accessible completely in the presentation of the meta information. If the title is not inside a meta, it is presented with the content and if it is identified as document title, it will be often used as the heading of the viewport too. There is no need for authors to note it twice, but it is not wrong to use a h element too for the general presentation purpose. But user-agents will not consider a h element as heading for a viewport.

If title is used within a citation in a cite, for example together with the element creator, it is simple inline flow content. This means, that typically for visual presentation the size of the title is not changed as for headings, because the title is only referenced, but does not represent a heading in the current document.

Relations

desc

Description

Type: Meta (block)

A container for a description inside the meta element for the target of the meta element. The content of the desc element can be structured with 'normal' flow elements.

Relations

cite

Description

Type: Meta (inline)

If some content from another author is quoted, it is required to provide information about the resource, work, project, book, web-page, whatever applies. This element is expected to contain or to reference this information. Often this will be a link to another resource or to a bibliography list item containing the related information. The cite may contain title and creator too.

Only if the author is the only known or citable source for example for a private communication quotation, the name of the author can be a useful solely content of the cite. It is either directly inside the q or bq element it is related or inside a meta element about a q or bq element or it points somehow to the quotation it is applicable for and the quotation points back to the cite to identify the relation vice versa.

It is possible too, that some other resource is not quoted word-by-word, it is only summarised, what is relevant for the current text. In such a case the cite can be expected outside of q, bq or meta too at the end of such a summary. In this case, if not specified otherwise the citation is related to the content provided by the direct parent of the cite element.

Relations

Samples for cite

created

Description

Type: Meta (inline)

The creation dates or time intervals of the related document or document fragment. If there is more than one date or interval, this element may contain a grouped list of dates or intervals using lg or list. Typically the list will start with the earliest date related to the document. Other orders can be indicated with a list type. If there is more than one applicable element created for one fragment with dates only with different accuracies, that with the highest accuracy can be used, if exactly one has to be chosen. If several different dates are applicable, they are assumed to indicate different versions or later updates.

A subset of the international standard ISO 8601:2004 for date and time is used to provide an understandable content.
For a date this looks like ±YYYY-MM-DDThh:mm:ss.fZ.
'-' and ':' within the string are separators.
± indicates an optional sign of the year, typically only '-' is used, if required, if it is missing, a '+' is implied.
YYYY are four digits for the years (more digits only if required and always in combination with the sign, for smaller year numbers one has to use leading zeros), MM two digits for the month, DD two digits for the day.
'T' is a separator between the date and the following time with hh two digits for the hour, mm two digits for the month, ss.f the seconds with two digits before the optional fractional part of seconds, typically not required for literature, if not generated somehow automatically (leap seconds are possible too).
Z is an indicator for UTC, alternatively the time zone can be indicated with ±hh:mm. Either Z or the time zone should be present, if the T part is present.

If not required, parts after a separator including the separator itself can be skipped, for example 2008-10-12 or 2008-10-12T12:30Z or 2008-10-12T12:30:05.0234Z or 2008-10-12T14:30:05.0234+02:00 or 2008-10-12T14:30+02:00 .

'/' is used to indicate a time interval: 2008-10-02/2008-10-12 means from the second to the twelfth of october 2008, the same as 2008-10-02/12 or 2008-10-02/10-12 .

It is explicitly discouraged to use plurivalent short forms or the basic format (almost without separators), because it is expected, that some literature survives long times, even if not originally intended.

If the (creation) time is not exactly known, this means especially not even the year, a preceding ~ can be used to indicate an estimated date, typically only the year or a range of years. There is no precisely predefined accuracy for this or the other notations. Without the ~ it can be assumed, that the accuracy is implicitly included, if only a date is given (no timezone), the accuracy is about one day. If date and time are given, the shortest time indication, for example minutes, indicate the accuracy implicitly. The event happened within the interval beginning with the indicated minute and ends before the next minute interval begins (includes the begin and excludes the end). The same applies for hours, seconds or fractional seconds. A leading indicator ~ means typically an accuracy a few times lower than this, if combined with an hour as highest resolution level, this means a few hours around the given date and time. If provided for a year, this means a few years around the given specified year. Because there is no lower resolution than years, authors have to provide lower accuracies than about 10 years separately outside of the element with another notation or some additional prose.
Those accuracy discussion already indicates, that for a large amount of literature it is contra-productive or wrong to provide a high accuracy creation information, because it takes typically a longer time to produce some piece of literature, therefore it is wrong to note the creation time with an accuracy of a second or below and no interval. However, this can be possible or meaningful for automatically generated content.

Relations

creator

Description

Type: Meta (inline)

The names of the authors or editors of the related document or document fragment. If there is more than one author or editor, this element may contain a grouped list of names using lg or list. The order of authors is expected to be in such a way, that the main author is the first name in the list. The list type may indicate the order of author names, if required.
The author does not necessarily publish the document, therefore there is another element available, the publisher.

Relations

contributor

Description

Type: Meta (inline)

The names of contributors for the related document or document fragment. Coauthors are to be noted within the element creator. Contributors are no direct authors and contribute in another way to the document. If there is more than one contributor, this element may contain a grouped list of names using lg or list.

Relations

genre

Description

Type: Meta (block)

Indicates the genre, the document or document fragment belongs to. If more than one genre applies, the items are separated with whitespace.
Genres can be grouped together.
A group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups. A '!' before a group indicates a negation. With a negation it is possible to indicate not intended genre areas to avoid plurivalences.

Example:
'{erotic documentary } !{crime porn}' simply means, that it is a documentation about erotics, but there is not both crime and porn in it. '{erotic documentary } !crime !porn' indicates too a documentation about erotics, but here it contains neither crime nor porn.

Another example:
'fashion forMen !heterosexual' is not exactly the same as 'fashion forMen homosexual', because there are bisexual and asexual men too. The second means, the reader can expect fashion for homosexual men.

Predefined values (simplified syntax for some words):

  • advertisement
  • allegory
  • almanac
  • anagram
  • anthology
  • aphorism
  • article
  • audioDrama
  • autobiography
  • biography
  • book
  • cartoon
  • catalogue
  • column
  • comedy
  • comment
  • documentary
  • drama
  • epic
  • fable
  • fairyTale
  • farce
  • fiction
  • flashFiction
  • folkTale
  • forum
  • guestBook
  • haibun
  • humoresque
  • joke
  • journal
  • koan
  • letter
  • lipogram
  • log
  • magazine
  • memorandum
  • news
  • note
  • novel
  • novella
  • parody
  • periodical
  • play
  • protocol
  • report
  • riddle
  • romance
  • saga
  • sample
  • satire
  • science
  • script
  • service
  • shortStory
  • story
  • tale
  • tragedy
  • tragicomedy
  • transcript
  • vignette

Some more predefined values specific for poetry:

  • acrostic
  • ballad
  • blankVerse
  • concretePoetry
  • elfchen
  • foundPoetry
  • freeForm
  • ghazal
  • haiga
  • haiku
  • hokku
  • hymn
  • klapphornvers
  • limerick
  • loveStory
  • mesostic
  • minnesang
  • nonsenseVerse
  • ode
  • ottavaRima
  • renga
  • renku
  • rondeau
  • rubai
  • shi
  • soundPoetry
  • sestina
  • sijo
  • song
  • sonnet
  • stev
  • tanka
  • terzaRima
  • villanelle
  • visualPoetry
  • waka

Literature theme areas:

  • action
  • adventure
  • almanac
  • animals
  • anthropology
  • archaeology
  • architecture
  • art
  • audio
  • baking
  • beauty
  • biology
  • bisexual
  • bizarre
  • business
  • chemistry
  • city
  • classic
  • computer
  • cooking
  • country
  • crime
  • culture
  • databases
  • dating
  • demography
  • design
  • dictionary
  • diet
  • draft
  • drugs
  • ecology
  • economics
  • education
  • engineering
  • entertainment
  • ergonomics
  • erotic
  • ethnology
  • experimental
  • family
  • fantasy
  • fashion
  • fauna
  • fetish
  • fitness
  • flirt
  • flora
  • folklore
  • forBoys
  • forChildren
  • forGirls
  • forMen
  • forSeniors
  • forTeens
  • forWomen
  • friendship
  • gallery
  • games
  • garden
  • gastronomy
  • geography
  • ghostStory
  • graphics
  • guide
  • hardware
  • health
  • heterosexual
  • history
  • home
  • homosexual
  • horror
  • humour
  • languages
  • law
  • layout
  • love
  • management
  • markup
  • mathematics
  • medicine
  • memoir
  • military
  • movie
  • music
  • mystery
  • nature
  • network
  • office
  • operatingSystems
  • organisation
  • outdoor
  • people
  • performance
  • pets
  • photography
  • politics
  • pop
  • porn
  • philosophy
  • physics
  • programming
  • proposal
  • psychology
  • radio
  • relation
  • religion
  • research
  • rockAndRoll
  • school
  • science
  • scienceFiction
  • scripting
  • sex
  • social
  • software
  • specification
  • sports
  • spy
  • statistics
  • study
  • technology
  • television
  • thriller
  • tradition
  • travel
  • tutorial
  • university
  • vegetarian
  • video
  • war
  • wedding
  • wellness
  • western
  • writing
  • www

Because these lists are not exhaustive, they may be extended in the future. If an author wants to extend it with a currently not existing type, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the type or genre.

A classification system can be used too, for example PACS. Notations of such a system are included in such parenthesis: '()'. If available a CURIE for the classification scheme should be added too, locking like this: ('[' CURIE ']' 'classification code'). Such parenthesis within the classification code needs of course to be masked as other critical glyphs from XML too.

The predefined items can be translated for display in the preferred language of a user, the expected presentation is the untranslated item first followed by the translation in parenthesis.

Relations

identifier

Description

Type: Meta (inline)

A permanent identifier for a document (fragment), like a URN, PURL, ISBN, DOI or another type of identifier. The main idea is, that such an identifier is unique for the document (fragment) and does not change sometimes for whatever reason. Once a document has stabilised somehow, it may get such an identifier. Updates and later versions may get another identifier. Alternatively the identifier for a current version may remain the same and if previous versions are provided too, they may get their own identifier. One document can have more than one identifier, but if it once has an identifier, this identifier will not get invalid anymore. If it is required to identify the type of identification, the attribute datatype can be used.

Relations

index

Description

Type: Meta (block)

index contains typically an index or table of contents of the document or complete project maybe including references or hyperlinks to the related fragments of the document or project.

A complete project consisting of several files can be provided as a so called widget, gadget or applet too. These are basically new words for an archive, concerning LML, and have no other meaning than an archive. To create an archive with related LML documents, one can simply choose a common and free archive format like tar or zip. The initial file containing the index providing access to all chapters, sections, parts of a complete project should be named index.xml (respectively as soon as LML is a well known format: index.lml; authors should use only one of them, if both are provided in doubt for an automatic display of the first archive document index.xml takes precedence).
Additionally the archive can be compressed, for example using 'gzip' or 'bzip2'. Typically for web applications there is no need to create an archive, but this can be pretty useful, if complete books or larger works of art or literature are provided for download and are mainly intended for offline reception.

Relations
cu
Description

Type: Attribute

A specific attribute for index and menu cares about a typical problem with reused content (for example with a server script language). The link to the current document is still in the reused index. This superfluous link may confuse users, especially for screen-readers, therefore the link functionality needs to be removed or hidden or the complete link needs to be removed.
The attribute cu (short for: current unified resource identifier) indicates, what the user agent has to do with a link to the current document within the current document (not applicable, if an (additional) fragment identifier is provided). cu has the possible values: " _show | _hide | _unlink | * " with * as the name of a replacement (inline) element. If a replacement element is indicated, the related link is presented like the given element without link functionality. For "_show" the link is still shown, for "_hide" the complete link is hidden, for "_unlink" only the link functionality and indication is disabled and only the content is provided. The default is "_unlink".

impressum

Description

Type: Meta (block)

Provides contact information to the person responsible for the document or fragment. This is typically legal information to identify the author or the person responsible for the document or a complete project. It can be expected, that such an information is available for any document of a project capable to contain such information and relevant information at all. In a larger project these documents may point only to a document with this information.

In some countries such information is required by laws for publications and specific data have to be provided. This element facilitates to find such information automatically.

Relations

keywords

Description

Type: Meta (block)

A container for keywords describing the content of a of the document or document fragment, separated by comma (and additional optional whitespace).

Relations

license

Description

Type: Meta (block)

A container for licence or copyright conditions on the usage of the document or document fragment. This may contain too a so called disclaimer, if required.
Note, that the document is already present for the user, if the license conditions are readable, this cannot be restricted within the same document already for logical reasons. If this is required, other methods have to be used. Note too, that it is pretty useless or even contra-productive to disclaim from consequences due to illegal activities.

Relations

ll

Description

Type: Meta (block)

A container inside the meta element for (a list of) link elements. The links point to the elements the meta information is intended for, if the intended element is not the direct parent of the meta element. This is a list, because the meta information can be related to more than one element, if applicable.

Relations

none

lm

Description

Type: Meta (block)

A container inside the meta element for (a list of) link elements. The links point to (other) meta elements related to the element, the meta information is intended for. This is only necessary, if those meta elements are not direct children of the meta element target, to identify the relation unambiguously. This is a list, because the meta information can be related to more than one element, if applicable.

Relations

none

Description

Type: Meta (block)

A help to navigate within a project or document, contains hyperlinks to other documents of the same project or to fragment identifiers within the same document. cu is a specific attribute for this element.

If menu appears inside meta element, there may be elements rel and rev inside, followed by menu elements or link elements. This means, that the content of the rel or rev indicates a relation between the resources referenced in the following link elements and the meta element target. The relation is applicable for all following siblings until there is another rel or rev indicating another relation.

If menu appears outside a meta element it will typically contain one or more list elements.

Relations

no

Description

Type: Meta (not directly presented)

A container for not directly presented content. Sometimes it might be required to have a container for specific content, intended more for the user-agent than for the user, or such a container may contain otherwise referenced content as the element defs from SVG. SMIL timesheets may require too a container for some additional information about the timesheet.
XHTML has similar elements script and style for other content, not intended for direct presentation, however these elements have a more specific meaning than no.
With styling it can be possible anyway to present the content somehow, but this is not the recommended use of this element. But it is possible to put this element around other content to remove it from presentation for some testing.

Relations

SVG: defs

note

Description

Type: Meta (block)

A side note, annotation, gloss, marginal note, incidental remark related to some content, either of the parent element or the relation is specified with a pointer unambiguously from the note to the content and vice versa.

Relations

pid

Description

Type: Meta (inline)

A project fragment identifier. The content is a CURIE typically within the project (sub)domain. Often a larger project is divided in several documents, but each of these documents have some fragments identical within the project. If an author indicates all these identical fragments with the same pid, programs with a none visual presentation may identify this and may provide a mechanism to skip such content if already known to save some time or to show it, if required. This user-agent behaviour is typically not necessary for a visual presentation, because for such a presentation it is typically simple for the user to skip such content without further help. Typical areas for such a help is for example a menu or index area, a header or footer, a logo.

Relations

none

phon

Description

Type: Meta (block)

Indicates the phonetics or pronunciation especially intended for specific words or phrases, problematic neologisms. The element will typically contain phonetic unicode characters or the phrase written with the international phonetic alphabet. Which type of notation is used can be specified with the attribute datatype or typeof. The element may contain a link to an audio representation too, or a switch between several variants or formats.

Relations

none

published

Description

Type: Meta (inline)

The date of publication of the current version of the related document or document fragment. The value is as described for created. However it is published only on one date, a version history can maybe included into release or in desc.

Relations

publisher

Description

Type: Meta (inline)

The names of the persons, responsible for the current publication of the related document or document fragment. If there is more than one publisher, this element may contain a grouped list of names using lg or list. The order of publishers is expected to be in such a way, that the main publisher is the first name in the list. The list type may indicate the order of publisher names, if required.
Especially this may appear together or within the element impressum to indicate unambiguously how to contact the responsible publisher. If only one of creator and publisher is available, the missing information cannot be directly derived from the available element, however the contact in the impressum should know this information in doubt.

Relations

The following two elements rel and rev (and the related attributes with the same names) indicate relations between documents or document fragments. Such a relation information will typically only indicate the point of view of the current document (fragment) author or editor. Therefore the information might be questionable from another point of view, especially this of the referenced document (fragment) author or editor. To get some reasonable information, in some cases, depending on the claimed relation, one has to explore, if both points of view result in the same conclusion. This is for example critical, if a document claims, that another document is outdated or replaced by the current document. In such a case it should be checked, that the referenced document has a related relation to the current document with a corresponding information. If this is not available, the relation information remains questionable, if there is no other information available about the relation. However, most relations are not really questionable or critical for the referenced document and will not change the meaning or intention of the referenced document from any point of view.

rel

Description

Type: Meta (block)

rel indicates a relation. It appears inside a menu element which appears inside a meta element. menu or link elements are expected to follow the rel element.

The content of the rel indicates a relation between the resources referenced in the following link elements and the meta element target. If more than one relation applies, the relations have to be separated with whitespace.

The content of the rel indicates the purpose or meaning of the referenced resource. For example if this is meta data applicable for a book and rel indicates 'chapter', this means, that the referenced resources are chapters of the book. If there are links to the sections of the chapter too, there may be other menu elements as siblings, then the link to the chapter resource is inside the menu followed by a rel indicating 'section' for the following links to the sections of this chapter of the book.

Or if the relation indicates 'help', then the referenced resources are helps for the meta element target.

Predefined items for rel (and rev) are all LML element names (in general only a subset will be meaningful, but the responsibility for the proper choice is a task for the author or editor). Additionally the following items are predefined:

alternate
Indicates an alternative, typically this is combined with another relation to indicate the type of alternative, if for example used together with translation, this indicates an alternative version in another language.
bookmark
a suggestion for an URI to be used as a bookmark.
dependent
Indicates a dependence between the meta element target and the referenced resource. For the rel it indicates, that the referenced resource depends on the target. The rev indicates, that the target depends on the referenced resource. Such a relation appears for example for translations or a schoolbook or textbook and a collection of exercises or solutions of tasks directly related to the book respectively the exercises.
To indicate such relations can be important to respect author's rights together with other considerations.
profile
Indicates a profile recommendation for extensions. The recommendation has to define, how the extension is applied.
replacement
for a rel the referenced resource replaces the target (and therefore outdated) fragment, for a rev the target replaces the referenced (and therefore outdated) resource.
source
indicates a relation between a copy and the original; rel indicates that the referenced resource is the original and the target a copy, rev the other way around.
translation
Indicates a relation to a translation of the document into another language. The rel indicates, that the target is the original document and the referenced resource a dependent translation, the rev indicates the other direction.
transcription
Indicates a relation to a document containing the same information, but within another format, for example XHTML or SVG instead of LML. The rel indicates, that the target is the original document and the referenced resource a dependent transcription, the rev indicates the other direction.
first
first resource of a collection
last
last resource of a collection
next
next resource of a collection
prev
previous resource of a collection
up
if for example in a book environment there is a systematic global structure of a collection, this refers to the next higher level, for example from a section to the begin of the related chapter, from a chapter to the beginning of a book etc

Because this list is not exhaustive, it may be extended in the future. If an author wants to extend it with a currently not existing relation, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the relation.

Relations
  • HTML4: rel attribute
  • DAISY: rel attribute

rev

Description

Type: Meta (block)

rev indicates a reverse relation. It appears inside a menu element which appears inside a meta element. menu or link elements are expected to follow the rev element.

The content of the rev indicates a reverse relation between the resources referenced in the following link elements and the meta element target. If more than one relation applies, the relations have to be separated with whitespace.

The content of the rev indicates the purpose or meaning of the meta element target for the referenced resource. For example if this is meta data applicable for a section and rev indicates 'chapter', this means, that the referenced resource is the chapter the section belongs to.

Or if the relation indicates 'help', then the meta element target is a help for the referenced resource.

For more details and predefined items for rev see the element rel.

Relations
  • HTML4: rev attribute
  • DAISY: rev attribute

release

Description

Type: Meta (block)

Release or publication data about a document or document fragment. This may contain information like published and publisher too as well as some version history or indication.

Relations

role

Description

Type: Meta (no display)

Indicates the role of the meta element target in another host language. This is only meaningful, if LML appears only as indicator for a semantical meaning of elements in other languages, which do not have a role attribute themselves and where it is undesired to use role with a prefix indicating a foreign namespace. For this situation however, the host language must at least have a container for meta information from other namespaces such as the element metadata in SVG. If the role appears outside a meta, but inside of such a foreign meta construction, the related foreign construction defines, to which element the role applies, for SVG metadata as direct parent this is the direct parent of the metadata. Using RDF syntax, the target is indicated with the attribute about.

The role element contains either an LML element name or a safe CURIE to indicate the role.

Note, that the new (2008-10-14) recommended Format XHTML+RDFa contains already several attributes to provide a closely related functionality. Especially to indicate the semantical meaning of an element, the attribute property can be used in a similar way to a role concerning literature and LML. Therefore if (X)HTML has to be used, this should be the preferred variant to provide some semantical meaning.

Relations

role

roles

Description

Type: Meta (no display)

Indicates an attribute representing a role in another host language. This is only meaningful, if LML appears only as indicator for a semantical meaning of elements in other languages, which do not have a role attribute themselves. With this element it is possible to indicate, which attribute takes the role of a role in the current document. This has to have a sufficient syntax for this application.

In (X)HTML and SVG this is the attribute class. Therefore it can be noted formally for example in SVG within the LML namespace: <roles>class</roles>. class consists of a whitespace separated list of class names. After this notation this is restricted to class names with the same names as LML elements or attributes have. The interpretation is, that the elements containing this attribute have the related semantical meaning as it would have with the role attribute in use not available in the currently used language. Other class names not related to LML have to start with 'c_' to indicate them as class names and not roles. For example class="literature c_something" means for this notation type, that the role of the element is that of a literature element and it belongs additionally to the class 'c_something'.

Because the chosen attribute may have other purposes, alternatively another approach can be used too. For this an additional indicator can be added after the attribute name and a whitespace separator: <roles>class l_</roles>. This means, that all names related to LML have a prefix 'l_' before the element or attribute name. For example class="l_literature something" means, that the role of the element is that of a literature element and it belongs additionally to the class 'something'.
Of course one can choose another prefix, for example 'lml_': <roles>class lml_</roles>.

Up to here this does not solve the problem, that often the element roles cannot be used in another language or the language has no method to define a namespace as HTML. For (X)HTML an author should currently consider to use the variant XHTML+RDFa. The new RDFa attributes should be typically sufficient to provide enough semantical meaning for literature combined with CURIEs from LML.
However, for the older (X)HTML variants one can specify one of the methods above using the attribute profile or a link with a profile relation and the element meta in the following way:

  1. Note as profile resource alternatively (or both the first and the second together)
    • in the start tag of the head element:
      profile="http://purl.oclc.org/net/hoffmann/lml/#"
    • in a link element in the head:
      <link rel="profile" href="http://purl.oclc.org/net/hoffmann/lml/#" title="LML" /> (no '/' in HTML)
    • Alternatively use the Dublin Core approach with both:
      In the start tag of the head element:
      profile="http://dublincore.org/documents/2008/08/04/dc-html/"
      In the link element in the head:
      <link rel="schema.lml" href="http://purl.oclc.org/net/hoffmann/lml/#" title="LML" /> (no '/' in HTML)
  2. Note one of the following alternatives:
    • <meta name="roles" content="class" /> (For the Dublin Core approach: <meta name="lml.roles" content="class" />)
    • <meta name="roles" content="class l_" /> (For the Dublin Core approach: <meta name="lml.roles" content="class l_" />)
    • <meta name="roles" content="class lml_" /> (For the Dublin Core approach: <meta name="lml.roles" content="class l_" />)
    • respectively a variant with the preferred prefix not mentioned explictly here.
    Obviously this applies for XHTML, for HTML remove the '/' specific for XML.
  3. It is possible, that an author wants to use different profiles for different purposes. For this the Dublin Core approach is pretty useful, because it provides a possibility of different schemes with something like prefixes within the names. Otherwise without a schema definition (not recommended) the related meta element(s) must directly follow the link element indicated the profile, the meta belongs to. A later link with rel="profile" indicates, that this profile is applicable for the following meta element(s) and not the previous.
  4. Indicate the roles within the class attribute following the defined syntax and prefix notation.

If for example in SVG it is not intended to use elements from other namespaces within the element metadata, because validation only within the SVG namespace is required for the complete document, another method is defined here, having at least the three above predefined methods available. For this one uses simply the attribute xmlns of the root svg element with one of the following methods:

  • xmlns:roles="http://purl.oclc.org/net/hoffmann/lml/#roles2class"
  • xmlns:roles="http://purl.oclc.org/net/hoffmann/lml/#roles2class-l_"
  • xmlns:roles="http://purl.oclc.org/net/hoffmann/lml/#roles2class-lml_"

This namespace is never really used within the document, it is only an indicator for the used method to provide roles within the element class using the indicated method. Unfortunately SVG tiny 1.1 has not class, therefore there is no other way than to use the metadata element for any element, a role has to be provided. In this case and similar other languages, one has to use the element role within the metadata element in any element, a role is required, respectively LML can be used directly in the desc elements to provide structured descriptions (this is a correct use as already mentioned, but typically only validators do not manage to validate such compound documents).

In case, that the profile remains removed from head in 'HTML5' and no role is defined, this causes a new problem in this language to provide semantical information. Note, that the link approach is still ok, even if the relation 'profile' is not predefined in 'HTML5'.
However it is noted, that one can for example place elements from RDF as any metadata directly into the head, this looks like this:


 
       class
 
]]>

respectively the other variants indicating a prefix.

This corresponds to the SVG approach of RDF within metadata (typically that of the root svg).
For 'HTML5' this approach only applies, if sent as application/xhtml+xml. For the text/html variant there is currently no solution in the 'HTML5' draft. If this is not changed, authors may take this as an indication for bad design of 'HTML5' and may not use the text/html variant for semantically relevant content, because it can be considered to be less advanced than the previous HTML4.

Relations

role

tip

Description

Type: Meta (block)

A container inside the meta element to provide the tool tip related to the target element. In an advanced viewer for an interactive graphical representation a tool tip becomes often visible as an independent viewport, while the pointing device is over the element. A tool tip is no replacement or alternative for the element, it is only an additional hint or help about some functionality of the element. Therefore for any kind of presentation some minimal interactive demand from the user can be expected to make this hint or help accessible. On the other hand the user-agent may have an indication for elements having tool tips.

Relations

Several (X)HTML user-agents use the attribute title for this purpose and this functionality is popular, but not much related to the naming.

WAI-ARIA: tooltip

tune

Description

Type: Meta (inline)

A container inside the meta element to indicate the tune of the target element. If more than one tune applies, the items are separated with whitespace. This might be useful, if the author wants to be sure, that the complete audience is able to understand the intended tune of the text.
Tunes can be grouped together.
A group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups. An '!' before a group indicates a negation. With a negation it is possible to indicate not intended tune areas to avoid plurivalences.

A list of predefined tune items:

  • aggression
  • amusement
  • belief
  • chaos
  • creepy
  • compassion
  • documentation
  • discussion
  • felicity
  • fiction
  • frustration
  • fun
  • grave
  • happy
  • hypothesis
  • ignorance
  • indifference
  • irony
  • joke
  • law
  • logic
  • love
  • neutral
  • nonsense
  • pacification
  • prognosis
  • revenge
  • serious
  • sarcasm
  • science
  • scoff
  • sorrow
  • sympathy

Because this list is not exhaustive, it may be extended in the future. If an author wants to extend it with a currently not existing tune, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the tune.

The predefined items can be translated for display, the expected presentation is the untranslated item first followed by the translation in parenthesis.

Relations

none

version

Description

Type: Meta (inline)

The version of the current fragment. There may be different versions of a document, which can be indicated with this element. The element itself provides no more information about the type of version numbering. To indicate this, additional attributes like typeof or property can be quite useful, if required.

Relations

XLDL: version attribute

conditional processing

Conditional processing is established in SMIL or SVG to provide content dependent on the capabilities of the user-agent and the preferences of the user. A typical example concerning text content is the switch between different languages for the same information. Another typical application is to provide alternatives for multimedia formats not interpreted by the user-agent.

Conditional processing consists basically on conditional processing attributes and the element switch. Conditional processing attributes act as boolean tests and evaluate to either true or false. The attributes can be used in two ways, depending on the context of the element on which the attributes are specified. The default evaluation is true.

Usage without switch:
If the test on conditional processing evaluates to false, the related element and its children are not processed (neither further interpreted nor displayed).

Usage with switch:
Within a switch element not more than one direct child (including its children) is processed at once. Which depends on the conditional processing attributes and on the specific attribute how of the switch element. An exception of this rule is a possible meta element as the first children of a switch. If the test on this meta evaluates to true (for example because it has no conditional processing attributes specified), not only this meta element is processed, the evaluation continues to find possible other elements to be processed. This first meta is presented independently to the conditional processing related to the switch. This ensures, that the author can provide meta information about the switch element and the conditional processing itself.

langc

Description

Type: Attribute, langc= "list of language identifiers"

The value is a whitespace separated list of language tags or language tag groups to indicate the applicable system language. For details about language tags see xml:lang.
An or-group is indicated with parenthesis, '(' at the beginning, ')' at the end.
An and-group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups.
A single tag evaluates to true for the purpose of conditional processing if one of the languages indicated by user preferences equals one of the languages given in the value of this attribute, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this attribute such that the first tag character following the prefix is '-' (minus).
An or-group evaluates to true, if at least one of the specified tags, respectively groups directly inside evaluates to true.
An and-group evaluates to true, if all specified tags, respectively groups directly inside evaluate to true.
This attribute evaluates to true, if all specified tags, respectively groups directly inside evaluate to true.

Relations

SVG: systemLanguage (Note that in SVG the value is processed simpler, excluding and- and or-groups.)

typec

Description

Type: Attribute, typec = "list of types"

The main idea of conditional processing dependent on a media type is to optimise accessibility for (other) formats and documents, if they themselves do not provide (text) alternatives for non textual content. If the referenced document provides this, it is sufficient to indicate the format of the document, not parts referenced inside. If the referenced document or format does not provide (text) alternatives for non textual content, the format itself or questionable formats used within the referenced documents are a matter of indication, if some other formats are required to be interpreted within the referenced format.
For example PNG and JPEG are required in SVG, SVG has the capabilities to provide text alternatives, therefore if text alternatives are available in the SVG document, only the type for SVG needs to be indicated.
If a SMIL document embeds video formats without text alternatives, all formats including that for SMIL need to be indicated.

The value is a whitespace or comma separated list of internet media types (or codecs) or media type or codec groups. For internet media types and codecs details see type.
An or-group is indicated with parenthesis, '(' at the beginning, ')' at the end.
An and-group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups.
A single type evaluates to true, if it is interpreted.
An or-group evaluates to true, if at least one of the specified types, respectively groups directly inside is interpreted.
An and-group evaluates to true, if all specified types, respectively groups directly inside are interpreted.
This attribute evaluates to true, if all specified types, respectively groups directly inside are interpreted.

Relations

SVG tiny 1.2: requiredFormats (Note that in SVG the value is processed simpler, excluding and- and or-groups.)

elc

Description

Type: Attribute, elc = "list of elements"

The value is a whitespace or comma separated list of LML element names or safe CURIEs, respectively groups of them.
An or-group is indicated with parenthesis, '(' at the beginning, ')' at the end.
An and-group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups.
A single element or CURIE evaluates to true, if it is interpreted.
An or-group evaluates to true, if at least one of the specified elements, CURIEs, respectively groups directly inside is interpreted.
An and-group evaluates to true, if all specified elements, CURIEs, respectively groups directly inside are interpreted.
This attribute evaluates to true, if all specified elements, CURIEs, respectively groups directly inside are interpreted.

Relations
  • SVG: requiredFeatures (Note that in SVG the value consists of feature strings and is processed simpler, excluding and- and or-groups.)
  • SVG: requiredExtensions (Note that in SVG the value is processed simpler, excluding and- and or-groups.)

how

Description

Type: Attribute, how = "conditional | interface | auto"

A specific attribute for the element switch, to indicate the method to determine, which direct child is processed. The default is 'auto'.
For the value 'conditional' the switch is done by conditional processing. Only the first direct children of the switch is processed, which conditional processing attributes all evaluate to true. If there is no such element, none of them is processed.
For the value 'interface' an interface is provided to choose between all elements, for which all conditional processing attributes evaluate to true as a first approach. On demand from the user all alternatives have to be indicated, independent from the conditional processing evaluation as a second approach. The information to be provided for the choice are the values of the conditional processing attributes and if available the meta information about each of these elements. A user-agent may provide additionally information about his own choice according to the result from 'auto'. Therefore the initial presentation is only an indication for the interface. After a selection, the selected alternative is processed. On demand the user may choose another alternative.
For the value 'auto' the user-agent chooses between all elements, for which all conditional processing attributes evaluate to true for the best expected presentation result. If this cannot be selected unambiguously, the user-agent chooses the first of the best in source code rendering order. The user-agent may use some rating number construction with reasonable weights for each conditional processing attribute to compute the element rating number by multiplication of all single attribute rating numbers. If a container with simple text and without conditional processing attribute is provided as last alternative within the switch and previous alternatives are other formats, this text is typically only intended as fallback, if nothing else works, therefore the rating number is assumed to be intended very low, even if there is no technical problem with its presentation.

Relations

none

switch

Description

Type: Meta (inline or block)

A container for the alternatives inside. The direct children of switch represent the alternatives.

The user-agent should provide on demand an interface related to how = "interface" for a manual selection between the alternatives and including the possibility to select external programs or to save the related file, if with a link a document in another format is referenced. This is intended to help users to decide on there own on demand, how and which alternative is the best.

Relations

Common Attributes

Some attributes are assumed to be available both in LML and in the host language for any element, if another language is used as host language.

XML attributes

xmlns

Description

xmlns[:prefix] = "resource-name"

Standard XML attribute to identify an XML namespace. This attribute makes the related namespace available for the current element (and its children, if they are not related to another namespace).

Relations

Namespaces in XML

xml:id

Description

xml:id = "unique identifier"

Standard XML attribute for assigning a unique name to an element.

If the host language provides only its own identifier like id, this can be used too, but for LML xml:id is preferred. In doubt both attributes can be noted with the same value.

Relations

xml:id Version 1.0

xml:lang

Description

xml:lang = "language identifier"

Standard XML attribute to specify the language (for example 'en' for english or 'de' for german) used in the contents and attribute values of particular elements.

If the host language provides only its own identifier like lang, this can be used too, but for LML xml:lang is preferred. In doubt both attributes can be noted with the same value.

Relations

XML

xml:space

Description

xml:space = "default" | "preserve"

Standard XML attribute to specify whether white space is preserved in character data.

Relations

XML

xml:base

Description

xml:base = "base URI or IRI"

Standard XML attribute to specify a base URI other than the base URI of the document or external entity.

Relations

XML base

Attributes derived from XHTML or SVG

class

Description

class = "whitespace separated list of class names"

This attribute indicates membership in one or more sets. Multiple set names must be separated by white space characters. A class name may be shared by several element instances.

Relations

role

Description

role = "whitespace separated list of roles"

The attribute indicates one or more roles of an element. The role describes the role of the element, for example the semantical meaning. A role value may be shared by several element instances.

Unlike the class attribute, role attribute values are intended to be selected from a predefined set of values with specific semantic aspects. The values are either predefined by WAI-ARIA or by the default namespace (starting with ':') or by a (safe) CURIE.

Predefined values in LML are the element names, for example ':poetry'.

Relations

XHTML role

datatype

Description

datatype = "CURIE"

Indicates, that the content of the element is in a machine readable format. The data type of this format is defined at the CURIE.

content

Description

content = "string"

If the datatype for an element is specified and the element itself does not contain the data in a machine readable format, the value of this attribute is used instead and has to conform with the data type as specified by the attribute datatype.

about

Description

about = "URI or safe CURIE"

Indicates about what the content of the related element is with a CURIE, this is the so called 'subject'. This works correspondingly to the meta element target, but provides a relation between the content of the element and the URI referenced by about.

property

Description

property = "whitespace separated list of CURIEs"

Indicates the content of the element, respectively the target of about representing a value of the specified properties, this is the so called 'predicate'.

resource

Description

resource = "URI or safe CURIE"

Indicates the resource as (a not clickable) subject of the statement, a so called object. Note, that other possibilities of subject resources, represented in XHTML as the attributes src and href are here in LML provided by the related attribute doing the referencing in the element link, using XLink this is XLink:href.

typeof

Description

typeof = "whitespace separated list of CURIEs"

Indicates an association of the subject with types as specified by the CURIEs.

rel

Description

rel = "whitespace separated list of relations"

The attribute indicates one or more relations of an element. The rel attribute expresses the relationships between two resources. The relation is either a predefined value (with the XHTML vocabulary) or a CURIE.

rev

Description

rev = "whitespace separated list of reverse relations"

The attribute indicates one or more relations of an element. The rev attribute expresses the reverse relationships between two resources. The relation is either a predefined value (with the XHTML vocabulary) or a CURIE.

Relations

RDFa syntax

References

  1. Semantic Markup for Poetry
  2. XHTML role attribute
  3. CURIE Syntax
  4. WAI ARIA
  5. XHTML vocabulary
  6. XHTML (1, 2), HTML4
  7. 'HTML 5'
  8. RDF, Semantic Web
  9. RDFa syntax
  10. Dublin Core Metadata Initiative terms
  11. DAISY; DAISY Specifications for the Digital Talking Book; DAISY Structure Guidelines for the Digital Talking Book; DAISY Digital Talking Book element and attribute index
  12. DocBook; DocBook: The Definitive Guide
  13. FictionBook
  14. XLDL
  15. Atom
  16. RSS 1.0
  17. 'RSS' 2.0
  18. XForms
  19. XLink
  20. SMIL
  21. timesheets
  22. Ausgedichtet - Discussion and tutorial about the problem to markup poetry in (X)HTML and SVG (de)
  23. Text in SVG

Glossary

block element
Block elements are well separated from each other in presentation. For aural presentation for example with breaks or annotations. For visual or tactile (Braille) presentation this may happen with margins, paddings, indentations, borders or outlines. Another approach could be marginal notes, glosses. For interactive visual presentation a precise information might be present only on demand with something like a tooltip.
Some block elements can contain only text or inline elements. Other block elements may only contain block elements. Some elements may contain either block or inline elements (and text), but not a mixture. Typically it is not a good approach to have a mixture of block and inline elements in one element. In general block elements do not appear in inline elements. In some cases LML defines, that a block element may switch into an inline element and vice versa depending on the direct parent element.
flow (of presentation/content)
Information in documents is typically expected to be presented in the order, they are in the source code, this is the flow of presentation. Styling like CSS or timesheets may changes this flow. The meta element is considered to be always extracted from this flow and presented somehow separately or presented within the flow only on demand and then with a clear indication.
inline element
Inline elements indicate typically phrases on the same level as text appears within block elements within the same line, typically without a spatial or temporal indication. For visual presentation they are often indicated with a styling or the appearance different from other inline elements or text. For aural presentation some indication might be only available on demand as annotations or as a change in the styling of the presentation. Some interactive indications are possible too. If the indication is done with additional symbols or glosses, they appear inline too.
metadata
Elements intended to provide meta information.
meta element target
The element, the meta information in the meta element is intended for. With the RDF nomenclature the target is the subject of the meta information.
parents, children, siblings, root
A parent element contains children elements between his begin and end tag. The direct parent is that parent element, which contains an element directly without any other parent elements between. If A is the direct parent of B, this means, that there is no other element C, being a children of A and a parent of B. Correspondingly B is a direct children of A, if there is no other element C, being a children of A and a parent of B. Obviously it is possible, that an element has several direct children, but it cannot have more than one direct parent (what is slightly different from sexual biological systems). Parent elements in general can be called ancestors too and children elements descendants. If elements have the same direct parent, they can be called siblings. A root element has no ancestors and no siblings, but typically descendants, because every XML document has exactly one root element, containing all content, only processing instructions appear outside and comments may appear outside too.
pointer
A method to indicate the target of a meta information. In LML the target is either implied as specified or a specific element is used inside the element representing the meta information, the content of the element ll. Another method is to use the attribute about.
styling
Styling or layout determines, how content is presented. This is different from the markup of the content itself, the markup indicates the intended functionality or structural or semantical meaning. Styling can be for example done with stylesheets or timesheets or scripting and can help to indicate the elements and their semantical meaning or can be used to improve the ergonomics of a document. To be usable, LML documents require some default styling either provided by the author or by the user-agent to enable users to identify the semantical meaning of document fragments.