Internationalization Tag Set (ITS) Version 2.0

Introduction

This section is informative.

ITS 2.0 is a technology to add metadata to Web content, for the benefit of localization, language technologies, and internationalization. The ITS 2.0 specification both identifies concepts (such as Translate) that are important for internationalization and localization, and defines implementations of these concepts (termed “ITS data categories”) as a set of elements and attributes called the Internationalization Tag Set (ITS). The document provides implementations for HTML5, serializations in RDFa and NIF, and the schema languages XML DTD , XML Schema and RELAX NG .

This document aims to realize many of the ideas formulated in the ITS 2.0 Requirements document, in and .

Not all requirements listed there are addressed in this document. Those which are not addressed here are either covered in (potentially in an as yet unwritten best practice document on multilingual Web content), or may be addressed in a future version of this specification.

Relation to ITS 1.0 and New Principles

Relation to ITS 1.0

ITS 2.0 has the following relations to ITS 1.0:

It adopts and maintains the following principles from ITS 1.0:

It adopts the use of data categories to define discrete units of functionality It adopts the separation of data category definition from the mapping of the data category to a given content format It adopts the conformance principle of ITS1.0 that an implementation only needs to implement one data category to claim conformance to ITS 2.0 ITS 2.0 supports all ITS 1.0 data category definitions and adds new definitions. ITS 2.0 adds a number of new data categories not found in ITS 1.0. While ITS 1.0 addressed only XML, ITS 2.0 specifies implementations of data categories in both XML and HTML5. Where ITS 1.0 data categories are implemented in XML, the implementation must be conformant with the ITS 1.0 approach to XML to claim conformance to ITS 2.0.

New Principles

ITS 2.0 also adds the following principles and features not found in ITS 1.0:

ITS 2.0 data categories are intended to be format neutral, with support for XML, HTML5, RDFa, and NIF: a data category implementation only needs to support a single content format mapping in order to support a claim of ITS 2.0 conformance. ITS 2.0 provides algorithms to generate RDFa and NIF out of HTML5 or XML with ITS 2.0 metadata. A global implementation of ITS 2.0 requires at least the XPath version 1.0. Other versions of XPath or other query languages (e.g., CSS selectors) can be expressed via a dedicated queryLanguage attribute.

As of the time of this writing, the new data categories included in ITS 2.0 are:

Domain Disambiguation Locale Filter Provenance Text Analysis Annotation

Motivation for ITS

Content or software that is authored in one language (the source language) is often made available in additional languages or adapted with regard to other cultural aspects. This is done through a process called localization, where the original material is translated and adapted to the target audience.

In addition, document formats expressed by schemas may be used by people in different parts of the world, and these people may need special markup to support the local language or script. For example, people authoring in languages such as Arabic, Hebrew, Persian, or Urdu need special markup to specify directionality in mixed direction text.

From the viewpoints of feasibility, cost, and efficiency, it is important that the original material should be suitable for localization. This is achieved by appropriate design and development, and the corresponding process is referred to as internationalization. For a detailed explanation of the terms “localization” and “internationalization”, see .

Note: This should refer to the best practice document as well, when ready.

The increasing usage of XML as a medium for documentation-related content (e.g. DocBook and DITA as formats for writing structured documentation, well suited to computer hardware and software manuals) and software-related content (e.g. the eXtensible User Interface Language ) creates challenges and opportunities in the domain of XML internationalization and localization.

Typical Problems

The following examples sketch one of the issues that currently hinder efficient XML-related localization: the lack of a standard, declarative mechanism that identifies which parts of an XML document need to be translated. Tools often cannot automatically perform this identification.

Document with partially translatable content

In this document it is difficult to distinguish between those string elements that are translatable and those that are not. Only the addition of an explicit flag could resolve the issue.

Document with partially translatable content

Even when metadata are available to identify non-translatable text, the conditions may be quite complex and not directly indicated with a simple flag. Here, for instance, only the text in the nodes matching the expression //component[@type!='image']/data[@type='text'] is translatable.

Users and Usages of ITS

Potential Users of ITS

The ITS specification aims to provide different types of users with information about what markup should be supported to enable worldwide use and effective internationalization and localization of content. The following paragraphs sketch these different types of users, and their usage of ITS. In order to support all of these users, the information about what markup should be supported to enable worldwide use and effective localization of content is provided in this specification in two ways:

abstractly in the data category descriptions: concretely in the ITS schemas:

Schema developers starting a schema from the ground up

This type of user will find proposals for attribute and element names to be included in their new schema (also called "host vocabulary"). Using the attribute and element names proposed in the ITS specification may be helpful because it leads to easier recognition of the concepts represented by both schema users and processors. It is perfectly possible, however, for a schema developer to develop his own set of attribute and element names. The specification sets out, first and foremost, to ensure that the required markup is available, and that the behavior of that markup meets established needs.

Schema developers working with an existing schema

This type of user will be working with schemas such as DocBook, DITA, or perhaps a proprietary schema. The ITS Working Group has sought input from experts developing widely used formats such as the ones mentioned.

The question "How to use ITS with existing popular markup schemes?" is covered in more details (including examples) in a separate document: .

Developers working on existing schemas should check whether their schemas support the markup proposed in this specification, and, where appropriate, add the markup proposed here to their schema.

In some cases, an existing schema may already contain markup equivalent to that recommended in ITS. In this case it is not necessary to add duplicate markup since ITS provides mechanisms for associating ITS markup with markup in the host vocabulary which serves a similar purpose (see ). The developer should, however, check that the behavior associated with the markup in their own schema is fully compatible with the expectations described in this specification.

Vendors of content-related tools

This type of user includes companies which provide tools for authoring, translation or other flavors of content-related software solutions. It is important to ensure that such tools enable worldwide use and effective localization of content. For example, translation tools should prevent content marked up as not for translation from being changed or translated. It is hoped that the ITS specification will make the job of vendors easier by standardizing the format and processing expectations of certain relevant markup items, and allowing them to more effectively identify how content should be handled.

Content producers

This type of user comprises authors, translators and other types of content author. The markup proposed in this specification may be used by them to mark up specific bits of content. Aside: The burden of inserting markup can be removed from content producers by relating the ITS information to relevant bits of content in a global manner (see global, rule-based approach). This global work, however, may fall to information architects, rather than the content producers themselves.

Ways to Use ITS

The ITS specification proposes several mechanisms for supporting worldwide use and effective internationalization and localization of content. We will sketch them below by looking at them from the perspectives of certain user types. For the purpose of illustration, we will demonstrate how ITS can indicate that certain parts of content should or should not be translated.

A content author uses an attribute on a particular element to say that the text in the element should not be translated.

Use of ITS by content author

The its:translate="no" attributes indicate that the path and the cmd elements should not be translated.

A content author or information architect uses markup at the top of the document to identify a particular type of element or context in which the content should not be translated.

Use of ITS by information architect

The translateRule element is used in the header of the document to indicate that none of the path or cmd elements should be translated.

A processor may insert markup at the top of the document which links to ITS information outside of the document.

Use of ITS by processor

A rules element is inserted in the header of the document. It has a XLink href attribute used to link to an ITS external rule document.

ITS rule file shared by different documents

The rules element contains several ITS rules that are common to different documents. One of them is a translateRule element that indicates that no path or cmd element should be translated.

A schema developer integrates ITS markup declarations in his schema to allow users to indicate that specific parts of the content should not be translated.

An XSD schema with ITS declaration

The declarations for the translate attribute is added to a group of common attributes commonAtts. This allows to use the translate attribute within the documents like in .

The first two approaches above can be likened to the use of CSS in . Using a style attribute, an XHTML content author may assign a color to a particular paragraph. That author could also have used the style element at the top of the page to say that all paragraphs of a particular class or in a particular context would be colored red.

Usage in HTML5

ITS 2.0 adds support for usage in HTML5. In HTML5, ITS local selection is realized via dedicated, data category specific attributes.

For the so-called “global approach” in HTML5, this specification defines a link type for referring to files with global rules. These rules are then processed as described in .

Using ITS global rules in HTML5

The link element points to the rules file EX-translateRule-html5-1.xml The rel attribute identifies the ITS specific link relation its-rules.

ITS rules file linked from HTML5

The rules file linked in .

Support for legacy HTML content

ITS 2.0 does not define how to use ITS in HTML versions prior version 5. Users are encouraged to migrate their content to HTML5 or XHTML. While it is possible to use its-* attributes introduced for HTML5 in older versions of HTML (such as 3.2 or 4.01) and pages using these attributes will work without any problems, its-* attributes will be marked as invalid in validators.

Out of Scope

The definition of what a localization process or localization parameters must address is outside the scope of this standard and it does not address all of the mechanisms or data formats (sometimes called Localization Properties) that may be needed to configure localization workflows or process specific formats. However, it does define standard data categories that may be used in defining localization workflows or processing specific formats.

“XML localization properties” is a generic term to name the mechanisms and data formats that allow localization tools to be configured in order to process a specific XML format. Examples of XML localization properties are the Trados “DTD Settings” file, and the SDLX “Analysis” file.

Important Design Principles

Abstraction via data categories: ITS defines data categories as an abstract notion for information needed for the internationalization and localization of XML schemas and documents and HTML5 documents. This abstraction is helpful in realizing independence from any one particular implementation (e.g., as an element or attribute). (See for a definition of the term data categories, for the definition of the various ITS data categories, and subsections in for the data category implementations.)

Powerful selection mechanism: For ITS markup that appears in an XML instance, which XML nodes the ITS-related information pertains to must be clearly defined. Thus, ITS defines selection mechanisms to specify to what parts of an XML document an ITS data category and its values should be applied. Selection relies on the information which is given in the XML Information Set . ITS applications may implement inclusion mechanisms such as XInclude or DITA's conref.

Content authors, for example, need a simple way to work with the Translate data category in order to express whether the content of an element or attribute should be translated or not. Localization managers, on the other hand, need an efficient way to manage translations of large document sets based on the same schema. These needs could by realized by a specification of defaults for the Translate data category along with exceptions to those defaults (e.g. all p elements should be translated, but not p elements inside of an index element).

To meet these requirements this specification introduces mechanisms that add ITS information to XML documents, see . These mechanisms also provide a means for specifying ITS information for attributes (a task for which no standard means previously existed).

The ITS selection mechanisms allows you to provide information about content locally (specified at the XML or HTML element to which it pertains) or globally (specified in another part of the document). Global selection mechanisms can be in the same document, or in a separate file.

No dedicated extensibility: It may be useful or necessary to extend the set of information available for internationalization or localization purposes beyond what is provided by ITS. This specification does not define a dedicated extension mechanism, since ordinary XML mechanisms (e.g. XML Namespaces ) may be used.

Ease of integration:

ITS follows the example from section 4 of , by providing mostly global attributes for the implementation of ITS data categories. Avoiding elements for ITS purposes as much as possible ensures ease of integration into existing markup schemes, see section 3.14 in . Only for some requirements do additional child elements have to be used, see for example . ITS has no dependency on technologies which are still under development. ITS fits with existing work in the W3C architecture (e.g. use of for the selection mechanism).

Development of this Specification

This specification has been developed using the ODD (One Document Does it all) language of the Text Encoding Initiative (). This is a literate programming language for writing XML schemas, with three characteristics:

The element and attribute set is specified using an XML vocabulary which includes support for macros (like DTD entities, or schema patterns), a hierarchical class system for attributes and elements, and creation of modules. The content models for elements and attributes are written using embedded RELAX NG XML notation. Documentation for elements, attributes, value lists etc. is written inline, along with examples and other supporting material.

XSLT transformations are provided by the TEI to create documentation into HTML, XSL FO or LaTeX forms, and to generate RELAX NG documents and DTD. From the RELAX NG documents, James Clark's trang can be used to create XML Schema documents.

Basic Concepts

This section is informative.

Selection

Information (e.g. "translate this") captured by ITS markup (e.g. its:translate='yes') always pertains to one or more XML or HTML nodes (primarily element and attribute nodes). In a sense, ITS markup “selects” the relevant node(s). Selection may be explicit or implicit. ITS distinguishes two approaches to selection: (1) local, and (2) using global rules.

The mechanisms defined for ITS selection resemble those defined in . The local approach can be compared to the style attribute in HTML/XHTML, and the approach with global rules is similar to the style element in HTML/XHTML. ITS usually uses XPath for identifying nodes although CSS and other query languages can be used if supported by application. Thus,

the local approach puts ITS markup in the relevant element of the host vocabulary (e.g. the author element in DocBook) the rule-based, global approach puts the ITS markup in elements defined by ITS itself (namely the rules element)

ITS markup can be used with XML documents (e.g. a DocBook article), or schemas (e.g. an XML Schema document for a proprietary document format). Since each usage defines some specific requirements, ITS markup may take different shapes.

In the paragraph above, we need an explanation of what “different shapes” means.

The following two examples sketch the distinction between the local and global approaches, using the translate as one example of ITS markup.

Local Approach

The document in shows how a content author may use the ITS translate attribute to indicate that all content inside the author element should be protected from translation. Translation tools that are aware of the meaning of this attribute can then screen the relevant content from the translation process.

ITS markup on elements in an XML document (local approach)

For this example to work, the schema developer will need to add the translate attribute to the schema as a common attribute or on all the relevant element definitions. Note how there is an expectation in this case that inheritance plays a part in identifying which content does have to be translated and which does not. Tools that process this content for translation will need to implement the expected inheritance.

Global Approach

The document in shows a different approach to identifying non-translatable content, similar to that used with a style element in , but using an ITS-defined element called rules. It works as follows: A document can contain a rules element (placed where it does not impact the structure of the document, e.g., in a “head” section). It contains one or more ITS rule elements (for example translateRule). Each of these specific elements contains a selector attribute. As its name suggests, this attribute selects the node or nodes to which a corresponding ITS information pertains. The values of ITS selector attributes are XPath absolute location paths (or CSS selectors if queryLanguage is set to "css"). Information for the handling of namespaces in these path expressions is taken from namespace declarations at the current rule element.

The following needs to be updated to allow for the use of queryLanguage, since we can use CSS selectors now. Perhaps the correction is as simple as changing the first sentence to read “When using XPath values for ITS selector attributes (see queryLanguage for a discussion of alternate values), note that the values are XPath absolute location paths…” Would that do? Also, might we move this to the end of the section?

Caveat Related to XSLT-based Processing of ITS Selector Attributes

The values of ITS selector attributes are XPath absolute location paths. Accordingly, the following is a legitimate value:

myElement/descendant-or-self::*/@*

Unfortunately, values like this cause trouble when they are used in XSLT-based processing of ITS where the values of the ITS selector attributes are used as values of match attributes of XSLT templates. The reason for this is the following: match attributes may only contain a restriction/subset of XPath expressions, so-called patterns.

Basically the following restrictions hold for patterns:

only axes "child" or "attribute" allowed "//" or "/" possible id() or key() function possible predicates possible

Using only XSLT patterns in ITS selector attributes helps to avoid this issue. In many cases, this is possible by using patterns with predicates. The value above may for example be rewritten as follows:

*[self::myElement]/@* | myElement//*/@*

ITS global markup in an XML document (rule-based approach)

For this approach to work, the schema developer needs to add the rules element and associated markup to the schema. In some cases global rules may be sufficient to allow the schema developer to avoid adding other ITS markup (such as an translate attribute) to the elements and attributes in the schema. However, it is likely that authors will want to use attributes on markup from time to time to override the general rule.

For specification of the Translate data category information, the contents of the rules element would normally be designed by an information architect familiar with the document format and familiar with, or working with someone familiar with, the needs of the localization group.

The global, rule-based approach has the following benefits:

Content authors do not have to concern themselves with creating additional markup or verifying that the markup was applied correctly. ITS data categories are associated with sets of nodes (for example all p elements in an XML instance) Changes can be made in a single location, rather than by searching and modifying local markup throughout a document (or documents, if the rules element is stored as an external entity) ITS data categories can designate attribute values as well as elements. It is possible to associate ITS markup with existing markup (for example the term element in DITA)

The commonality in both examples above is the markup translate='no'. This piece of ITS markup can be interpreted as follows:

it pertains to the Translate data category the attribute translate holds a value of no

The ITS selector attribute allows:

ITS data category attributes to appear in global rules (even outside of an XML document or schema) ITS data categories attributes to pertain to sets of XML nodes (for example all p elements in an XML document) ITS markup to pertain to attributes ITS markup to associate with existing markup (for example the term element in DITA)

Overriding and Inheritance

The power of the ITS selection mechanisms comes at a price: rules related to overriding/precedence, and inheritance, have to be established.

The document in shows how inheritance and overriding work for the Translate data category. By default elements are translatable. Here, the translateRule element declared in the header overrides the default for the head element inside text and for all its children. Because the title element is actually translatable, the global rule needs to be overridden by a local its:translate="yes". Note that the global rule is processed first, regardless of its position inside the document. In the main body of the document, the default applies, and here it is its:translate="no" that is used to set “faux pas” as non-translatable.

Overriding and Inheritance

Adding Information or Pointing to Existing Information

For some data categories, special attributes add or point to information about the selected nodes. For example, the Localization Note data category can add information to selected nodes (using a locNote element), or point to existing information elsewhere in the document (using a locNotePointer attribute).

The functionality of adding information to the selected nodes is available for each data category except Language Information. Pointing to existing information is not possible for data categories that express a closed set of values; that is: Translate, Directionality, Locale Filter and Elements Within Text.

The functionalities of adding information and pointing to existing information are mutually exclusive. That is to say, attributes for pointing and adding must not appear at the same rule element.

Notation and Terminology

This section is normative.

Notation

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .

The namespace URI that MUST be used by implementations of this specification is:

http://www.w3.org/2005/11/its

The namespace prefix used in this specification for this URI is “its”. It is recommended that implementations of this specification use this prefix.

In addition, the following namespaces are used in this document:

http://www.w3.org/2001/XMLSchema for the XML Schema namespace, here used with the prefix “xs” http://relaxng.org/ns/structure/1.0 for the RELAX NG namespace, here used with the prefix “rng” http://www.w3.org/1999/xlink for the XLink namespace, here used with the prefix “xlink”

Schema Language

Schema language refers in this specification to an XML-related modeling or validation language such as XML DTD, XML Schema, or RELAX NG.

This specification provides schemas in the format of XML DTD, XML Schema, or RELAX NG. However, these schemas are only non-normative; conformance for ITS markup declarations defines only mandatory positions of ITS declarations in schemas. This makes it possible to use ITS with any schema language that allows for using these positions.

Data category

ITS defines data category as an abstract concept for a particular type of information for internationalization and localization of XML schemas and documents. The concept of a data category is independent of its implementation in an XML environment (e.g. using an element or attribute).

For each data category, ITS distinguishes between the following:

the prose description, see schema language independent formalization, see the "markup declarations" subsections in schema language specific implementations, see A data category and its implementation

The Translate data category conveys information as to whether a piece of content should be translated or not.

The simplest formalization of this prose description on a schema language independent level is a translate attribute with two possible values: yes and no. An implementation on a schema language specific level would be the declaration of the translate attribute in, for example, an XML DTD, an XML Schema document or an RELAX NG document. A different implementation would be a translateRule element that allows for specifying global rules about the Translate data category.

Selection

selection encompasses mechanisms to specify to what parts of an XML document an ITS data category and its values should be applied to. Selection is discussed in detail in . Selection can be applied globally, see , and locally, see . As for global selection, ITS information can be added to the selected nodes, or it can point to existing information which is related to selected nodes.

Selection relies on the information that is given in the XML Information Set . ITS applications MAY implement inclusion mechanisms such as XInclude or DITA's conref.

The selection of the ITS data categories applies to textual values contained within element or attribute nodes. In some cases these nodes form pointers to other resources; a well-known example is the src attribute on the img element in HTML. The ITS Translate data category applies to the text of the pointer itself, not the object to which it points. Thus in the following example, the translation information specified via the translateRule element applies to the filename instructions.jpg, and is not an instruction to open the graphic and change the words therein.

Selecting the text of a pointer to an external object

Usage of Internationalized Resource Identifiers in ITS

The attributes href, locNoteRef and termInfoRef which contain resource identifiers MUST allow the usage of Internationalized Resource Identifiers (IRIs, or its successor) to ease the adoption of ITS in international application scenarios.

The ITS schemas in are not normative. Hence this specification defines no validation requirements for IRI values in ITS markup. For processing of these values, relying on IRIs imposes no specific requirements. The reason is that the processing happens on the info set level , where no difference between IRIs and URIs exists.

Conformance

This section is normative.

The usage of the term conformance clause in this section is in compliance with .

This specification defines two types of conformance: conformance of 1) ITS markup declarations , and conformance of 2) processing expectations for ITS Markup. These conformance types complement each other. An implementation of this specification MAY use them separately or together.

Conformance Type 1: ITS Markup Declarations

Description: ITS markup declarations encompass all declarations that are part of the Internationalization Tag Set. They do not concern the usage of the markup in XML documents. Such markup is subject to the conformance clauses in .

Definitions related to this conformance type: ITS markup declarations are defined in various subsections in and (e.g. ) in a schema language independent manner, relying on the ODD language. Their occurrence in other sections of this document is typographically marked via bold face and color.

Who uses this conformance type: Schema designers integrating ITS markup declarations into a schema. All conformance clauses for this conformance type concern the position of ITS markup declarations in that schema, and their status as mandatory or optional.

Conformance clauses:

1-1: At least one of the following MUST be in the schema:

rules element one of the local ITS attributes span element ruby element

1-2: If the rules element is used, it MUST be part of the content model of at least one element declared in the schema. It SHOULD be in a content model for meta information, if this is available in that schema (e.g. the head element in ).

1-3: If the ruby element is used, it SHOULD be declared as an inline element.

1-4: If the span element is used, it SHOULD be declared as an inline element.

Full implementations of this conformance type will implement all markup declarations for ITS. Statements related to this conformance type MUST list all markup declarations they implement.

Examples: Examples of the usage of ITS markup declarations in various existing schemas are given in a separate document .

Since the ITS markup declarations are schema language independent, each schema language can use its own, possibly multiple, mechanisms to implement the conformance clauses for ITS markup declarations. For example, an XML DTD can use parameter entities to encapsulate the ITS local attributes, or declare them directly for each element. The appropriate steps to integrate ITS into a schema depend on the design of this schema (e.g. whether it already has a customization layer that uses parameter entities). The ITS schemas in the format of XML DTD, XML Schema and RELAX NG in are only informative examples.

Conformance Type 2: The Processing Expectations for ITS Markup

Description: Processors need to compute the ITS information that pertains to a node in an XML document. The ITS processing expectations define how the computation has to be carried out. Correct computation involves support for selection mechanism, defaults / inheritance / overriding characteristics, and precedence. The markup MAY be valid against a schema which conforms to the clauses in .

Definitions related to this conformance type: The processing expectations for ITS markup make use of selection mechanisms defined in . The individual data categories defined in have defaults / inheritance / overriding characteristics, and allow for using ITS markup in various positions (global and local).

Who uses this conformance type: Applications that need to process the nodes captured by a data category for internationalization or localization. Examples of this type of application are: ITS markup-aware editors, or translation tools that make use of ITS markup to filter translatable text as an input to the localization process.

Application-specific processing (that is processing that goes beyond the computation of ITS information for a node) such as automated filtering of translatable content based on the Translate data category is not covered by the conformance clauses below.

The ITS Working group provides a test suite to help implementers to write applications that support the ITS specifications. The test suite provides pairs of input and output files.

Conformance clauses:

2-1: A processor MUST implement at least one data category. For each implemented data category, the following MUST be taken into account:

2-1-1: processing of at least one selection mechanism (global or local).

2-1-2: the default selections for the data category.

2-1-3: the precedence definitions for selections defined in , for the type of selections it processes.

2-2: If an application claims to process ITS markup for the global selection mechanism, it MUST process an XLink href attribute found on a rules elements.

Statements related to this conformance type MUST list all data categories they implement, and for each data category which type of selection they support.

Processing of ITS information

This section is normative.

Indicating the Version of ITS

The version of the ITS schema defined in this specification is 2.0. The version is indicated by the ITS version attribute. This attribute is mandatory for the rules element, where it MUST be in no namespace. If there is no rules element in an XML document, a prefixed ITS version attribute (e.g. its:version) MUST be provided at the root element of the document. If there is both a version attribute at the root element and a rules element in a document, they MUST NOT specify different versions.

The following paragraph is little bit strange. What is purpose? Do we want to allow mixing of ITS 1.0 and 2.0 or not?

Each XML document can have a different version. That is: if external rules are linked via an XLink href attribute on the rules element, they can specify a different version than the rules element.

Locations of Data Categories

ITS data categories can appear in two places:

Global rules: the selection is realized within a rules element. It contains rule elements for each data category. Each rule element has a selector attribute and possibly other attributes. The selector attribute contains an absolute selector as defined in . Locally in a document: the selection is realized using ITS local attributes, which are attached to an element node, or the span or ruby element. There is no additional selector attribute. The default selection for each data category defines whether the selection covers attributes and child elements. See .

The two locations are described in detail below.

Global, Rule-based Selection

Global, rule-based selection is implemented using the rules element. It contains zero or more rule elements. Each rule element has a mandatory selector attribute. This attribute and all other possible attributes on rule elements are in the empty namespace and used without a prefix.

If there is more than one rules element in an XML document, the rules from each section are to be processed at the same precedence level. The rules sections are to be read in document order, and the ITS rules with them processed sequentially. The versions of these rules elements MUST NOT be different.

Depending on the data category and its usage, there are additional attributes for adding information to the selected nodes, or for pointing to existing information in the document. For example, the Localization Note data category can be used for adding notes to selected nodes, or for pointing to existing notes in the document. For the former purpose, a locNote element can be used. For the latter purpose, a locNotePointer attribute can be used.

Each data category allows users to add information to the selected nodes except for language information. Pointing to existing information is not possible for data categories that express a closed set of values, that is: Translate, Directionality, Locale Filter, and Elements Within Text.

The functionalities of adding information and pointing to existing information are mutually exclusive. That is: markup for pointing and adding MUST NOT appear in the same rule element.

Global rules can appear in the XML document they will be applied to, or in a separate XML document. The precedence of their processing depends on these variations. See also .

Markup for global, rule-based selection is defined as follows.

Container for global rules. Version of the ITS schema. 2.0 The ITS namespace. http://www.w3.org/2005/11/its A valid XML namespace The ITS namespace. http://www.w3.org/2005/11/its A valid XML namespace Pointer to external rules files. The query language to be used for processing the rules. xpath css xpath Default is XPath 1.0 http://www.w3.org/TR/xpath/ Defines the default values of the variables used in the various selector expressions used in the rules. Selector expression identifying the nodes to be selected. Version of the ITS schema. 2.0

Global selection within HTML5 This should be probably merged with 5.4 "Link to External Rules"

Global rules work in HTML5 as follows.

Global rules will be attached externally using the link element, with the link relation its-rules. In global rules XPath 1.0 will be used for selection. If users prefer easier selection mechanism, they can switch query language to CSS selectors by using the queryLanguage attribute, see .

Using XPath in global rules linked from HTML5 documents does not create an additional burden to implementers. Parsing HTML5 content produces a DOM tree that can be directly queried using XPath, functionality supported by all major browsers.

Local Selection in an XML Document

Local selection in XML documents is realized with local ITS attributes, the ruby element, or the span element. span serves just as a carrier for the local ITS attributes and a container for ruby.

The content model of span permits arbitrary nesting of ruby markup, since the rt element can contain span. An application of ruby, however, MUST not use such arbitrary nesting.

The data category determines what is being selected. The necessary data category specific defaults are described in .

Defaults for various data categories

By default the content of all elements in a document is translatable. The attribute its:translate="no" in the head element means that the content of this element, including child elements, should not be translated. The attribute its:translate="yes" in the title element means that the content of this element, should be translated (overriding the its:translate="no" in head). Attribute values of the selected elements or their children are not affected by local translate attributes. By default they are not translatable.

The default directionality of a document is left-to-right. The its:dir="rtl" in the quote element means that the directionality of the content of this element, including child elements and attributes, is right-to-left. Note that xml:lang indicates only the language, not the directionality.

Markup for local selection is defined as follows. The attribute group att.local.no-ns.attributes contains ITS attributes in no namespace and is used with the ITS elements span, locNote, ruby, rt and rp. The attribute group att.local.with-ns.attributes contains namespace qualified ITS attributes and is used with elements from different namespaces. The attribute group att.local.html5.attributes contains ITS attribute for HTML5.

The dir and translate attributes are not listed in the ITS attributes to be used in HTML5. The reason is that these two attributes are available in HTML5 natively, so there is no need to provide them as its- attributes. The definition of the two attributes in HTML5 is compatibly, that is it provides the same values and interpretation, as the definition for the two data categories Translate and Directionality.

The Translate data category information to be attached to the current node. The nodes need to be translated. The nodes must not be translated. Localization note. The type of localization note. Localization note is an alert. Localization note is a description. URI referring to the location of the localization note. Pointer to a resource containing information about the term. Indicates a term locally. The value 'yes' means that this is a term. The value 'no' means that this is not a term. The text direction for the context. Left-to-right text. Right-to-left text. Left-to-right override. Right-to-left override. States whether current context is regarded as "within text". The element and its content are part of the flow of its parent element. The element splits the text flow of its parent element and its content is an independent text flow. The element is part of the flow of its parent element, its content is an independent flow. Comma-separated list of extended language ranges, or an empty string value. The Translate data category information to be attached to the current node. The nodes need to be translated. The nodes must not be translated. Localization note. The type of localization note. Localization note is an alert. Localization note is a description. URI referring to the location of the localization note. Pointer to a resource containing information about the term. Indicates a term locally. The value 'yes' means that this is a term. The value 'no' means that this is not a term. The text direction for the context. Left-to-right text. Right-to-left text. Left-to-right override. Right-to-left override. States whether current context is regarded as "within text". The element and its content are part of the flow of its parent element. The element splits the text flow of its parent element and its content is an independent text flow. The element is part of the flow of its parent element, its content is an independent flow. Comma-separated list of extended language ranges, or an empty string value. Localization note. The type of localization note. Localization note is an alert. Localization note is a description. URI referring to the location of the localization note. Pointer to a resource containing information about the term. Indicates a term locally. The value 'yes' means that this is a term. The value 'no' means that this is not a term. States whether current context is regarded as "within text". The element and its content are part of the flow of its parent element. The element splits the text flow of its parent element and its content is an independent text flow. The element is part of the flow of its parent element, its content is an independent flow. Comma-separated list of extended language ranges, or an empty string value. Inline element to contain ITS information. The ITS namespace. http://www.w3.org/2005/11/its A valid XML namespace The ITS namespace. http://www.w3.org/2005/11/its A valid XML namespace

Query Language of Selectors

Choosing Query Language

Rule elements have attributes which contain asbolute and relative selectors. Interpretation of these selectors depends on the actual query languge. The query language is set by queryLanguage attribute on rules element. If queryLanguge is not specified XPath 1.0 is used as a default query language.

XPath 1.0

XPath 1.0 is identified by xpath value in queryLanguage attribute.

Absolute selector

The absolute selector MUST be an XPath expression which starts with "/". That is, it must be an AbsoluteLocationPath or union of AbsoluteLocationPaths as described in XPath 1.0. This ensures that the selection is not relative to a specific location. The resulting nodes MUST be either element or attribute nodes.

Context for evaluatiation of the XPath expression is as follows:

Context node is set to Root Node.

Both context position and context size are 1.

All variables defined by param elements are bind.

All functions defined in the XPath Core Function Library are available. It is an error for an expression to include a call to any other function.

The set of namespace declarations are those in scope on the element which has the attribute in which the expression occurs. This includes the implicit declaration of the prefix xml required by the the XML Namespaces Recommendation; the default namespace (as declared by xmlns) is not part of this set.

XPath expressions with namespaces

The term element from the TEI is in a namespace http://www.tei-c.org/ns/1.0.

XPath expressions without namespaces

The term element from DocBook V4.5 is in no namespace.

Relative selector

The relative selector MUST use a RelativeLocationPath as described in XPath 1.0. The XPath expression is evaluated relative to the nodes selected by the selector attribute. The following attributes point to existing information: locNotePointer, locNoteRefPointer, termInfoPointer, termInfoRefPointer, rubyPointer, rtPointer, rpPointer, langPointer, locQualityIssuesRefPointer, locQualityIssueTypePointer, locQualityIssueCommentPointer, locQualityIssueSeverityPointer, locQualityIssueProfileRefPointer.

Make sure that previous list of ..Pointer attributes is complete once spec is stable.

Context for evaluatiation of the XPath expression is same as for absolute selector with the following changes:

Nodes selected by the expression in the selector attribute form the current node list.

Context node comes from the current node list.

The context position comes from the position of the current node in the current node list; the first position is 1.

The context size comes from the size of the current node list.

CSS Selectors

CSS Selectors are identified by css value in queryLanguage attribute.

Absolute selector

Absolute selector MUST be interpreted as selector as defined in Selectors Level 3. Both simple selectors and groups of selectors can be used.

Relative selector

Relative selector MUST be interpreted as selector as defined in Selectors Level 3. Selector is not evaluated against the complete document tree but only against subtrees rooted at nodes selected by selector in the selector attribute.

Additional query languages

ITS processors MAY support additional query languages. For each additional query language processor MUST define:

identifier of query language used in queryLanguage; rules for evaluating absolute selector to collection of nodes; rules for evaluating relative selector to collection of nodes.

Future versions of this specification MAY define additional query languages. The following query language identifiers are reserved: xpath, css, xpath2, xpath3, xquery, xquery3, xslt2, xslt3.

Variables in selectors

A param element (or several ones) can be placed as the first child element(s) of the rules element to define the default values of variables used in the various selectors used in the rules.

Implementation MUST support the param element for all query languages it supports and which at the same time define how variables are bind for evaluation of selector expression. Implementations SHOULD also provide means for changing the default values of the param elements. Such means are implementation-specific.

The param element has a required name attribute. The value of the name attribute is a QName, see . The content of the element is a string used as default value for the corresponding variable.

Using the param element to define the default value of a variable in a selector attribute.

The param element defines the default value for the $LCID variable. In this case, only the msg element with the attribute lcid set to 0x049 is seen as translatable.

In XSLT-based applications, it may make sense to map ITS parameters directly to XSLT parameters. To avoid naming conflicts one can use a prefix with the attribute name's value to distinguish between the ITS parameters and the XSLT parameters.

Link to External Rules

One way to associate a document with a set of external ITS rules is to use the optional XLink href attribute in the rules element. The referenced document must be a valid XML document containing at most one rules element. That rules element can be the root element or anywhere within the document tree (for example, the document could be an XML Schema).

The rules contained in the referenced document MUST be processed as if they were at the top of the rules element with the XLink href attribute.

External file EX-link-external-rules-1.xml with global rules:

The example demonstrates how metadata can be added to ITS rules.

Document with a link to EX-link-external-rules-1.xml

The result of processing the two documents above is the same as processing the following document.

Document with identical rules as in the case of included rules

Applications processing global ITS markup MUST recognize the XLink href attribute in the rules element; they MUST load the corresponding referenced document and process its rules element before processing the content of the rules element where the original XLink href attribute is.

External rules may also have links to other external rules. The linking mechanism is recursive, the deepest rules being overridden by the top-most rules, if any.

Precedence between Selections

The following precedence order is defined for selections of ITS information in various positions (the first item in the list has the highest precedence):

Implicit local selection in documents (ITS local attributes on a specific element)

Global selections in documents (using a rules element)

Inside each rules element the precedence order is: Any rule inside the rules element Any rule linked via the XLink href attribute Define how HTML5 link works with precedence.

If identical selections are defined in different rules elements within one document, the selection defined by the last takes precedence.

ITS does not define precedence related to rules defined or linked based on non-ITS mechanisms (such as processing instructions for linking rules).

Selections via defaults for data categories, see

In case of conflicts between global selections via multiple rules elements, the last rule has higher precedence.

The precedence order fulfills the same purpose as the built-in template rules of . Override semantics are always complete, that is all information that is specified in one rule element is overridden by the next one.

Conflicts between selections of ITS information which are resolved using the precedence order

The two elements title and author of this document should be treated as separate content when inside a prolog element, but as part of the content of their parent element otherwise. In order to make this distinction two withinTextRule elements are used:

The first rule specifies that title and author in general should be treated as an element within text. This overrides the default.

The second rule indicates that when title or author are found in a prolog element their content should be treated separately. This is normally the default, but the rule is needed to override the first rule.

Associating ITS Data Categories with Existing Markup

Some markup schemes provide markup which can be used to express ITS data categories. ITS data categories can be associated with such existing markup, using the global selection mechanism described in .

Associating existing markup with ITS data categories can be done only if the processing expectations of the host markup are the same as, or greater than, those of ITS. For example, the format can use its translate attribute to apply to “transcluded” content, going beyond the ITS 2.0 local selection mechanism, but not contradicting it.

Association of the ITS data categories Translate and Terminology with DITA 1.0 markup

In this example, there is an existing translate attribute in DITA, and it is associated with the ITS semantics using the its:rules section. Similarly, the DITA dt and term elements are associated with the ITS Terminology data category.

Global rules can be associated with a given XML document using different means:

By using an rules element in the document itself:

with the rules directly inside the document, as shown in with a link to an external rules file using the XLink href attribute, as shown in By associating the rules and the document through a tool-specific mechanism. For example, for a command-line tool: providing the paths of both the XML document to process and its corresponding external rules file.

Conversion to NIF and RDFa

This section will be written in an updated version of this document.

Here the algorithm for the conversion and some examples (HTML5 its- input < RDFa and NIF output) need to be added.

Description of Data Categories

This section is normative.

This schema has been developed using the ODD (One Document Does it all) language of the Text Encoding Initiative (). This is a literate programming language for writing XML schemas, with three characteristics: (1) The element and attribute set is specified using an XML vocabulary which includes support for macros (like DTD entities, or schema patterns), a hierarchical class system for attributes and elements, and creation of modules. (2) The content models for elements and attributes is written using embedded RELAX NG XML notation. (3) Documentation for elements, attributes, value lists etc. is written inline, along with examples and other supporting material. XSLT transformations are provided by the TEI to extract documentation in HTML, XSL FO or LaTeX forms, and to generate RELAX NG documents and DTD. From the RELAX NG documents, James Clark's trang can be used to create XML Schema documents.

Position, Defaults, Inheritance and Overriding of Data Categories

The following table summarizes for each data category which selection, default value, and inheritance and overriding behavior applies.

Default values apply if both local or global selection are absent. The default value for the Translate data category for example mandates that elements are translatable, and attributes are not translatable if there is no translateRule element and no translate attribute available. Inheritance describes whether ITS information is applicable to child elements of nodes and attributes related to these nodes or their child notes. The inheritance for the Translate data category for example mandates that all child elements of nodes are translatable whereas all attributes related to these the nodes or their child notes are not translatable. Overriding describes whether ITS information can be overridden or not. Overriding is only applicable for data categories with inheritance. Overriding thus is not applicable for the Terminology and the Ruby data category. Data category Local Usage Global, rule-based selection Global adding of information Global pointing to existing information Default Values Inheritance Overriding HTML5 examples Translate Yes Yes Yes No translate="yes" for elements, and translate="no" for attributes Textual content of element, including content of child elements, but excluding attributes Yes tbd Localization Note Yes Yes Yes Yes None Textual content of element, including content of child elements, but excluding attributes Yes tbd Terminology Yes Yes Yes Yes term="no" None Not applicable tbd Directionality Yes Yes Yes No dir="ltr" Textual content of element, including attributes and child elements Yes tbd Ruby Yes Yes Yes Yes None None Not applicable tbd Language Information No Yes No Yes None Textual content of element, including attributes and child elements Yes tbd Elements Within Text Yes Yes Yes No withinText="no" None Not applicable tbd Domain No Yes Yes Yes None Textual content of element, including attributes and child elements Yes tbd Disambiguation Yes Yes Yes Yes None None Not applicable tbd Locale Filter Yes Yes Yes No localeFilterList="*" Textual content of element, including attributes and child elements Yes tbd External Resource No Yes No Yes None None Not applicable tbd Target Pointer No Yes No Yes None None Not applicable tbd Id Value No Yes No Yes None None Not applicable tbd Preserve Space Yes Yes Yes No default Textual content of element, including attributes and child elements Yes tbd Localization Quality Issue Yes Yes Yes Yes None Textual content of element, including child elements, but excluding attributes Yes tbd Localization Quality Précis Yes Yes Yes Yes None Textual content of element, including child elements, but excluding attributes Yes tbd

Defaults, inheritance and overriding behavior of data categories

In this example, the content of all the data elements is translatable because the default for the Translate data category in elements is yes. The content of revision and locNote is not translatable because the default is overridden by the local its:translate="no" attribute in the prolog element, and that value is inherited by all the children of prolog.

The localization note for the two first data elements is the text defined globally with the locNoteRule element. And this note is overridden for the last data element by the local its:locNote attribute.

The data categories differ with respect to defaults. This is due to existing standards and practices. It is common practice for example that information about translation refers only to textual content of an element. Thus, the default selection for the Translate data category is the textual content.

Translate

Definition

The Translate data category expresses information about whether the content of an element or attribute should be translated or not. The values of this data category are yes (translatable) or no (not translatable).

Implementation

The Translate data category can be expressed with global rules, or locally on an individual element. The information applies to the textual content of the element, including child elements, but excluding attributes. The default is that elements are translatable and attributes are not.

GLOBAL: The translateRule element contains the following:

All selector related definitions has to be update to reflect queryLanguage A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required translate attribute with the value yes or no. The Translate data category expressed globally

The translateRule element specifies that the elements code must not be translated.

LOCAL: The following local markup is available for the Translate data category:

A translate attribute with the value yes or no.

It is not possible to override the Translate data category settings of attributes using local markup. This limitation is consistent with the advised practice of not using translatable attributes. If attributes need to be translatable (e.g., an HTML alt attribute), then this must be declared globally.

The Translate data category expressed locally

The local its:translate="no" specifies that the content of panelmsg must not be translated.

The Translate data category expressed locally in HTML5

The local translate="no" attribute specifies that the content of span must not be translated.

Markup Declarations for Translate The following note may need some finessing

Note: translate has been adopted as a native HTML5 attribute, and so appears in HTML files without the its- prefix, unlike other ITS data categories like localizationNote and Terminology.

Rule about the Translate data category. The Translate data category information to be applied to selected nodes. The nodes need to be translated. The nodes must not be translated. The Translate data category information to be attached to the current node. The nodes need to be translated. The nodes must not be translated. The Translate data category information to be attached to the current node. The nodes need to be translated. The nodes must not be translated.

Localization Note

Definition

The Localization Note data category is used to communicate notes to localizers about a particular item of content.

This data category can be used for several purposes, including, but not limited to:

Tell the translator how to translate parts of the content Expand on the meaning or contextual usage of a specific element, such as what a variable refers to or how a string will be used in the user interface Clarify ambiguity and show relationships between items sufficiently to allow correct translation (e.g., in many languages it is impossible to translate the word enabled in isolation without knowing the gender, number and case of the thing it refers to.) Indicate why a piece of text is emphasized (important, sarcastic, etc.)

Two types of informative notes are needed:

An alert contains information that the translator must read before translating a piece of text. Example: an instruction to the translator to leave parts of the text in the source language. A description provides useful background information that the translator will refer to only if they wish. Example: a clarification of ambiguity in the source text.

Editing tools may offer an easy way to create this type of information. Translation tools can be made to recognize the difference between these two types of localization notes, and present the information to translators in different ways.

Implementation

The Localization Note data category can be expressed with global rules, or locally on an individual element. The information applies to the textual content of the element, including child elements, but excluding attributes.

GLOBAL: The locNoteRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required locNoteType attribute with the value description or alert.

Exactly one of the following:

A locNote element that contains the note itself and allows for local ITS markup. A locNotePointer attribute that contains a relative selector pointing to a node that holds the localization note. A locNoteRef attribute that contains a URI referring to the location of the localization note. A locNoteRefPointer attribute that contains a relative selector pointing to a node that holds the URI referring to the location of the localization note. All *Pointer attributes has to be updated in regard to queryAttribute The locNote element

The locNoteRule element associates the content of the locNote element with the message with the identifier 'DisableInfo' and flags it as important. This would also work if the rule was in an external file, allowing to provide notes without modifying the source document.

The locNotePointer attribute

The locNotePointer attribute is a relative selector pointing to a node that holds the note.

The locNoteRef attribute

The locNoteRule element specifies that the message with the identifier 'NotFound' has a corresponding explanation note in an external file. The URI for the exact location of the note is stored in the locNoteRef attribute.

The locNoteRefPointer attribute

The locNoteRefPointer attribute contains a relative selector pointing to a node that holds the URI referring to the location of the note.

LOCAL: The following local markup is available for the Localization Note data category:

One of the following:

A locNote attribute that contains the note itself. A locNoteRef attribute that contains a URI referring to the location of the localization note. An optional locNoteType attribute with the value description or alert. If the locNoteType attribute is not present, the type of localization note will be assumed to be description. The Localization Note data category expressed locally The Localization Note data category expressed locally in HTML5

It is generally recommended to avoid using attributes to store text, however, in this specific case, the need to provide the notes without interfering with the structure of the host document is outweighing the drawbacks of using an attribute.

Markup Declarations for Localization Note Rule about the Localization Note data category. Relative selector pointing to a node that holds the localization note. The type of localization note. Localization note is an alert. Localization note is a description. URI referring to the location of the localization note. Relative selector pointing to a node that holds the URI referring to the location of the localization note. Contains a localization note. Localization note. The type of localization note. Localization note is an alert. Localization note is a description. URI referring to the location of the localization note. Localization note. The type of localization note. Localization note is an alert. Localization note is a description. URI referring to the location of the localization note.

Terminology

Definition

The Terminology data category is used to mark terms and optionally associate them with information, such as definitions. This helps to increase consistency across different parts of the documentation. It is also helpful for translation.

Existing terminology standards such as and its derived formats are about coding terminology data, while the ITS Terminology data category simply allows to identify terms in XML documents and optionally to point to corresponding information.

Implementation

The Terminology data category can be expressed with global rules, or locally on an individual element. There is no inheritance. The default is that neither elements nor attributes are terms.

GLOBAL: The termRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required term attribute with the value yes or no.

Exactly one of the following:

A termInfoPointer attribute that contains a relative selector pointing to a node that holds the terminology information. A termInfoRef attribute that contains a URI referring to the resource providing information about the term. A termInfoRefPointer attribute that contains a relative selector pointing to a node that holds the URI referring to the location of the terminology information. Usage of the termInfoPointer attribute Usage of the termInfoRef attribute Usage of the termInfoRefPointer attribute

LOCAL: The following local markup is available for the Terminology data category:

A term attribute with the value yes or no. An optional termInfoRef attribute that contains a URI referring to the resource providing information about the term. The Terminology data category expressed locally The Terminology data category expressed locally in HTML5

Markup Declarations for Terminology Rule about the Terminology data category. Indicates whether the selection is a term or not. The value 'yes' means that this is a term. The value 'no' means that this is not a term. URI referring to the resource providing information about the term. Relative selector pointing to a node containing a URI referring to the resource providing information about the term. Relative selector pointing to a node containing information about the term. Pointer to a resource containing information about the term. Indicates a term locally. The value 'yes' means that this is a term. The value 'no' means that this is not a term. Pointer to a resource containing information about the term. Indicates a term locally. The value 'yes' means that this is a term. The value 'no' means that this is not a term.

Directionality

Definition

The Directionality data category allows the user to specify the base writing direction of blocks, embeddings and overrides for the Unicode bidirectional algorithm. It has four values: ltr, rtl, lro and rlo.

ITS defines only the values of the Directionality data category and their inheritance. The behavior of text labeled in this way may vary, according to the implementation. Implementers are encouraged, however, to model the behavior on that described in the CSS 2.1 specification or its successor. In such a case, the effect of the data category's values would correspond to the following CSS rules:

Data category value: ltr (left-to-right text)

CSS rule: *[dir="ltr"] { unicode-bidi: embed; direction: ltr}

Data category value: rtl (right-to-left text)

CSS rule: *[dir="rtl"] { unicode-bidi: embed; direction: rtl}

Data category value: rlo (left-to-right override)

CSS rule: *[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}

Data category value: rlo (right-to-left text)

CSS rule: *[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}

More information about how to use this data category is provided by .

Implementation Examples for HTML5 need to be added; some values need to added to dir to reflect HTML5.

The Directionality data category can be expressed with global rules, or locally on an individual element. The information applies to the textual content of the element, including child elements and attributes. The default is that both elements and attributes have the directionality of left-to-right.

GLOBAL: The dirRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required dir attribute with the value ltr, rtl, lro or rlo. Document which needs global rules for directionality

In this document the right-to-left directionality is marked using a direction attribute with a value rtlText.

The Directionality data category expressed with global rules

The dirRule element indicates that all elements with an attribute direction="rtlText" have right-to-left content.

LOCAL: The following local markup is available for the Directionality data category:

A dir attribute with the value ltr, rtl, lro or rlo. The Directionality data category expressed locally

On the first quote element, the its:dir="rtl" attribute indicates a right-to-left content.

The Directionality data category expressed locally in HTML5

Markup Declarations for Directionality

Note: dir is a native HTML5 data category and so does not require the its- prefix used by most data categories in HTML5 representations.

Rule about the Directionality data category. The text direction for the selection. Left-to-right text. Right-to-left text. Left-to-right override. Right-to-left override. The text direction for the context. Left-to-right text. Right-to-left text. Left-to-right override. Right-to-left override. The text direction for the context. Left-to-right text. Right-to-left text. Left-to-right override. Right-to-left override.

Ruby

Definition

The Ruby data category is used for a run of text that is associated with another run of text, referred to as the base text. Ruby text is used to provide a short annotation of the associated base text. It is most often used to provide a reading (pronunciation) guide.

Implementation Examples for HTML5 need to be added;

The Ruby data category can be expressed with global rules, or locally. There is no inheritance.

GLOBAL: The rubyRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. This is the ruby base text. An optional rubyPointer attribute that contains a relative selector pointing to a node that corresponds to the ruby element. An optional rpPointer attribute that contains a relative selector pointing to a node that corresponds to the ruby parenthesis. An optional rubyText element that contains the ruby text. An optional rtPointer attribute that contains a relative selector pointing to a node that corresponds to the ruby text.

Where legacy formats do not contain ruby markup, it is still possible to associate ruby text with a specified range of document content using the rubyRule element.

Adding ruby text with a rubyRule element

LOCAL: In a document, the Ruby data category is realized with a ruby element. It contains the following:

The ruby base text or span element that contains the ruby base text and allows for local ITS markup. An rp element that contains the ruby parenthesis. It is used in case of simple 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. An rt element that contains the ruby text and allows for local ITS markup.

All these elements share the attributes of the span element.

The Ruby data category expressed locally

The structure of the content model for the ruby element is identical with the structure of ruby markup as defined in .

The structure of ruby defined in section 5.4 of is also compliant with ruby defined in this specification.

Need to reevaluate above statement related to ODF.

Markup Declarations for Ruby Rule about the Ruby data category. Relative selector pointing to a node that corresponds to a ruby element Relative selector pointing to a node that corresponds to a rt element Relative selector pointing to a node that corresponds to a rp element Ruby text. Ruby markup. The ITS namespace http://www.w3.org/2005/11/its A valid XML namespace The ITS namespace http://www.w3.org/2005/11/its A valid XML namespace Ruby text. 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.

Language Information

Definition

The element langRule is used to express the language of a given piece of content. The langPointer attribute points to the markup which expresses the language of the text selected by the selector attribute. This markup MUST use values that conform to . The recommended way to specify language identification is to use xml:lang. The langRule element is intended only as a fall-back mechanism for documents where language is identified with another construct.

Pointing to language information via langRule

The following langRule element expresses that the content of all p elements (including attribute values and textual content of child elements) are in the language indicated by mylangattribute, which is attached to the p elements, and expresses language using values conformant to .

The Language Information data category only provides for rules to be expressed at a global level. Locally users are able to use xml:lang (which is defined by XML) or an attribute specific to the format in question (as in ).

xml:lang is the preferable means of language identification. To ease the usage of xml:lang, a declaration for this attribute is part of the non-normative XML DTD and XML Schema document for ITS markup declarations. There is no declaration of xml:lang in the non-normative RELAX NG document for ITS, since in RELAX NG it is not necessary to declare attributes from the XML namespace.

Applying the Language Information data category to xml:lang attributes using global rules is not necessary, since xml:lang is the standard way to specify language information in XML. xml:lang is defined in terms of RFC 3066 or its successor ( is the "Best Common Practice" for language identification and encompasses and its successors.)

Add something about HTML5 lang

Implementation

The Language Information data category can be expressed only with global rules. The information applies to the textual content of the element, including child elements and attributes. There is no default.

GLOBAL: The langRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required langPointer attribute that contains a relative selector pointing to a node that contains language information.

Markup Declarations for Language Information Rule about the Language Information data category. Relative selector pointing to a node that contains language information.

Elements Within Text

Definition

The Elements Within Text data category reveals if and how an element affects the way text content behaves from a linguistic viewpoint. This information is for example relevant to provide basic text segmentation hints for tools such as translation memory systems. The values associated with this data category are:

yes : The element and its content are part of the flow of its parent element. For example the element strong in :

Appaloosa horses have spotted coats.

nested : The element is part of the flow of its parent element, its content is an independent flow. For example the element fn in :

Palouse horses<fn>A Palouse horse is the same as an Appaloosa.</fn> have spotted coats.

no : The element splits the text flow of its parent element and its content is an independent text flow. For example the element p when inside the element li in DITA or XHTML:

<li>Palouse horses: They have spotted coats. They have been bred by the Nez Perce. </li>

Implementation

The Elements Within Text data category can be expressed with global rules, or locally on an individual element. There is no inheritance. The default is that elements are not within text.

GLOBAL: The withinTextRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required withinText attribute with the value yes, no or nested. Specifying elements within text with a withinTextRule element

LOCAL: The following local markup is available for the Elements Within Text data category:

A withinText attribute with the values yes, no or nested. The Elements Within Text data category expressed locally The Elements Within Text data category expressed locally in HTML5

Markup Declarations for Elements Within Text Rule about the Elements Within Text data category. States whether current context is regarded as "within text". The element and its content are part of the flow of its parent element. The element splits the text flow of its parent element and its content is an independent text flow. The element is part of the flow of its parent element, its content is an independent flow. States whether current context is regarded as "within text". The element and its content are part of the flow of its parent element. The element splits the text flow of its parent element and its content is an independent text flow. The element is part of the flow of its parent element, its content is an independent flow. States whether current context is regarded as "within text". The element and its content are part of the flow of its parent element. The element splits the text flow of its parent element and its content is an independent text flow. The element is part of the flow of its parent element, its content is an independent flow.

Domain

Definition

The Domain data category is used to identify the domain of content.

This data category addresses various challenges:

Often domain related information in content does exist, e.g. keywords in the HTML meta element. The Domain data category addresses this by providing a mechanism to point to this information. There are many flat or structured lists of domain related values, keywords, key phrases, classification codes, ontologies. The Domain data category does not propose a given list; rather it provides a mapping mechanism to associate values in content with consumer tool specific values needed for processing domain information.

Implementation

The Domain data category can be expressed only with global rules. The information applies to the textual content of the element, including child elements and attributes. There is no default.

GLOBAL: The domainRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required domainPointer attribute that contains a relative selector pointing to a node that contains the domain information. An optional domainMapping attribute that contains a comma separated list of mappings between values in the content and consumer tool specific values. The left part of the pair is part of the source content and unique within the mapping. The right part of the mapping belongs to the consumer tool. Several left parts can map to a single right part. The values in the left or the right part of the mapping may contain spaces; in that case they MUST be delimited by quotation marks, that is pairs of APOSTROPHE (Unicode code point U+0027) or QUOTATION MARK (U+0023).

Although the domainMapping attribute it is optional, its usage is recommended. Many commercial machine translation systems use their own domain definitions; the domainMapping attribute will foster interoperability between these definitions and metadata items like DC.subject in Web pages or other types of content.

Values used in the domainMapping attribute are arbitrary strings. In some consumer systems or existing content, the domain may be identified via an URI like http://example.com/domains/automotive. The domainMapping allows for using URIs too. For the mapping, they are regarded as ordinary string values.

The domainRule element

The domainRule element expresses that the content of the HTML body element is in the domain expressed by the HTML meta element with the name attribute, value DC.Subject. The domainPointer attribute points to that meta element.

The domainRule element

The domainRule element expresses that the content of the HTML body element is in the domain expressed by associated values. The domainPointer attribute points to the values in the source content. The domainMapping attribute contains the comma separated list of mappings. In the example, automotive is available in the source content, and auto is used within the consumer tool, e.g. a machine translation system.

In source content, if available, it is recommended to use dublin core subject as the metadata term for domain information. In HTML, this can be achieved via a meta element with the name="DC.subject" attribute.

In the area of machine translation (e.g. machine translation systems or systems harvesting content for machine translation training), there is no agreed upon set of value sets for domain. Nevertheless it is recommended to use a small set of values both in source content and within consumer tools, to foster interoperability. If larger value sets are needed (e.g. detailed terms in the law or medical domain), mappings to the smaller value set needed for interoperability should be provided. An example would be a domainMapping attribute for generalizing the law domain: domainMapping="'criminal law' law, 'property law' law, 'contract law' law".

It is possible to have more than one domain associated with a piece of content. For example, if the consumer tool is a statistical machine translation engine, it could include corpora from all domains available in the source content in training the machine translation engine.

The consumer machine translation engine might choose to ignore the domain and take a one size fits all approach, or may be selective in which domains to use, based on the range of content marked with domain. For example, if the content has hundreds of sentences marked with domain 'automotive' and 'medical', but only a couple of sentences marked with additional domains 'criminal law' and 'property law', the consumer tool may opt to include its domains 'auto' and 'medicine', but not 'law', since the extra training resources does not justify the improvement in the output.

Markup Declarations for Domain Rule about the Domain data category. Relative selector pointing to a node that contains domain information. A comma separated list of mappings between values in the content and workflow specific values. The values may contain spaces; in that case they MUST be delimited by quotation marks.

Disambiguation This data category is not completely stable yet.

Definition

The Disambiguation data category is used to communicate the mentions of specific concepts that may require special handling in the localization of the document.

This data category can be used for several purposes, including, but not limited to:

Informing translation systems that this fragment of text may not be literally translated, but subject to specific proper-name translation rules or official translations, as well as a very specific meaning of the phrases. Informing content management and translation systems about the type of the underlying entity in order to enable processing based on a specific type of the entity, for example, when handling personal names, product names or geographic names, chemical compounds, protein names and similar.

We introduce the following concepts:

Entity Type Source: a domain of valid values, an identifier collection for entity types. Unless specified, it will be derived by default de-referencing mechanisms for the URI. Entity Type: the type of the entity, being one of values within the entity type source identifier collection. Disambiguation type: the level of disambiguation (lexical concept, ontology concept, entity). The disambiguation can happen at multiple levels. For instance, the level of lexical concepts disambiguates individual word surface forms, the level of ontology concepts disambiguates into deeper semantics, and the entity disambiguation works on the level of concrete instances. For instance, the word City in I am going to the City may be disambiguated in one of the WordNet synsets that can be represented by city, an RDF ontology concept of a City that could represent a subclass of a PopulatedPlace, or the center area of a particular city, e.g. London City. Disambiguation Source: the identifier collection source used for locating the correct underlying identifier. It can be anything that can representing a collection of identifiers for words, concepts or entities, for instance, a knowledge base, an ontology or semantic network. Unless specified, it will be derived by default de-referencing mechanisms for the URI. Disambiguation Identifier: an identifier, unique within the current disambiguation identifier collection, specifying the actual identifier (meaning, concept or entity) behind the selected content.

Two types of Disambiguation data categories are needed to identify:

Entity type, which describes the type of the underlying entity within a particular domain of types, as specified by the type source identifier collection. Disambiguation, which describes the actual underlying identifier or meaning that the mention refers to, either in a knowledge base, ontology or in a semantic network.

Text analysis engines, such as named entity recognizers, named entity, concept and word sense disambiguators can offer an easy way to create this information. Content management tools can present and visualize this information or use it to index their content. Machine translations systems may use it for training and translation when dealing with proper names and edge cases.

Implementation

The Disambiguation data category can be expressed with global rules, or locally on an individual element. The information applies to the textual content of the element. There is no inheritance. The entity type follows inheritance rules.

GLOBAL: The disambiguationRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. An optional entityTypeSourceRef attribute that contains a URI specifying the concrete identifier data source (knowledge base, semantic network), used to determine the entity type. An optional entityTypeSourcePointer attribute that contains a relative XPath expression pointing to a node that represents the identifier data source (knowledge base, semantic network), used to determine the entity type. An optional entityTypeSourceRefPointer attribute that contains a relative XPath expression pointing to a node that holds the URI that represents the identifier data source (knowledge base, semantic network), used to determine the entity type. An optional entityTypeRef attribute that contains a URI, specifying the entity type behind the selector. An optional entityTypePointer attribute that contains a relative XPath expression pointing to a node specifying the entity type behind the selector. An optional entityTypeRefPointer attribute that contains a relative XPath expression pointing to a node that holds the URI that specifies the entity type behind the selector. An optional disambigType attribute that contains a string, specifying the specific semantics of the disambiguation. It can be one of "lexicalConcept", "ontologyConcept", or "entity". An optional disambigSourceRef attribute. It contains a URI representing the disambiguation identifier collection source. An optional disambigSourcePointer attribute. It contains a relative XPath expression pointing to a node that represents the disambiguation identifier collection source. An optional disambigSourceRefPointer attribute. It contains a relative XPath expression pointing to a node that holds the URI that represents the disambiguation identifier collection source. An optional disambigIdentRef attribute. It contains a URI that represents a unique identifier within the identifier collection. An optional disambigIdentPointer attribute. It contains a relative XPath expression pointing to a node that represents a unique identifier within the identifier collection. An optional disambigIdentRefPointer attribute. It contains a relative XPath expression pointing to a node that represents a unique identifier within the identifier collection. Usage of entityTypeSourceRef, enttiyTypeRef, disambigSourceRef, disambigIdentRef for both entity and word sense disambiguation.

LOCAL: The following local markup is available for the Disambiguation data category:

An optional entityTypeSourceRef attribute that contains an URI specifying the concrete identifier data source (knowledge base, semantic network), used to determine the entity type. An optional entityTypeRef attribute that contains a URI specifying the entity type behind the selector. An optional disambigType attribute that contains a string, specifying the specific semantics of the disambiguation. It can be one of "lexicalConcept", "ontologyConcept", or "entity". An optional disambigSourceRef attribute. It contains a URI representing the disambiguation identifier collection source. An optional disambigIdentRef attribute. It contains a URI that represents a unique identifier within the identifier collection. Local mixed usage of entityTypeSourceRef, enttiyTypeRef, disambigSourceRef, disambigIdentRef in HTML.

While the entityTypeSourceRef attribute allows for an arbitrary domain of entity types, the implementors are encouraged to use an existing repository of entity types as long as they satisfy their requirements. For example, the Named Entity Recognition and Disambiguation ontology (NERD): http://nerd.eurecom.fr/ontology

The distinction between disambiguating word sense and entities is mainly in the different semantics: whereas word sense disambiguation targets literal words and their senses on the lexical level, entity disambiguation targets real-world concepts that are behind the selected phrases on the conceptual level.

When serializing the ITS markup in HTML5, the preferred way is to serialize in RDFa Lite or Microdata due to the existing search and crawling infrastructure that is able to consume this kind of data.

Local mixed usage of entityTypeSourceRef, entityTypeRef, disambigSourceRef, disambigIdentRef in HTML+RDFa Lite

See for the companion document with the mapping data.

Local mixed usage of entityTypeSourceRef, entityTypeRef, disambigSourceRef, disambigIdentRef in HTML+RDFa Lite

Companion document, having the mapping data for .

Markup Declarations for Disambiguation Rule about the Disambiguation data category. URI specifying the data source. Relative selector pointing to a node specifying the data source. Relative selector pointing to a node containing a URI specifying the data source. URI specifying the entity type. Relative selector pointing to a node specifying the entity type. Relative selector pointing to a node containing a URI specifying the entity type. String specifying the disambiguation semantics. lexicalConcept ontologyConcept entity URI specifying the disambiguation identifier collection source. Relative selector pointing to a node specifying the disambiguation identifier collection source. Relative selector pointing to a node containing a URI specifying the disambiguation identifier collection source. URI specifying a unique identifier in the collection source. Relative selector pointing to a node specifying a unique identifier in the collection source. Relative selector pointing to a node containing a URI specifying a unique identifier in the collection source. URI specifying the data source. String specifying the disambiguation semantics. lexicalConcept ontologyConcept entity URI specifying the disambiguation identifier collection source. URI specifying a unique identifier in the collection source. URI specifying the data source. String specifying the disambiguation semantics. lexicalConcept ontologyConcept entity URI specifying the disambiguation identifier collection source. URI specifying a unique identifier in the collection source.

Locale Filter

Definition

The Locale Filter data category specifies that a node is only applicable to certain locales.

This data category can be used for several purposes, including, but not limited to:

Include a legal notice only in locales for certain regions. Drop editorial notes from all localized output.

The Locale Filter data category associates with each selected node a list of extended language ranges conforming to . The list is comma-separated and can include the wildcard extended language range *. The list can also be empty. Whitespace surrounding language ranges is ignored.

To express that all locales should be included, one can use the wildcard * for the language range. To express that the content should not be included in any local, one can use the empty value.

Implementation

The Locale Filter data category can be expressed with global rules, or locally on an individual element. The information applies to the textual content of the element, including child elements and attributes. The default is that the language range is *.

Implementations MUST NOT combine lists of language ranges from multiple rules or local attributes.

GLOBAL: The localeFilterRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required localeFilterList attribute with a comma-separated list of extended language ranges, or an empty string value. The Locale Filter data category expressed globally

The localeFilterRule element specifies that certain legal notice elements should only be shown in the specified locales. Note that using the extended language range *-CA in the localeFilterList attribute would cover all Canadian locales, including various minority languages in Canada.

The Locale Filter data category expressed globally

The localeFilterRule element specifies that editorial remarks should be removed from all translations.

LOCAL: The following local markup is available for the Locale Filter data category:

A localeFilterList attribute with a comma-separated list of extended language ranges, or an empty string value. The Locale Filter data category expressed locally

Markup Declarations for Locale Filter Rule about the LocaleFilter data category. Comma-separated list of extended language ranges, or an empty string value. Comma-separated list of extended language ranges, or an empty string value. Comma-separated list of extended language ranges, or an empty string value.

Provenance

The Provenance data category will be defined in an updated version of this document. For details of the proposed data category, see the ITS 2.0 Requirements document.

TextAnalyisAnnotation

The TextAnalyisAnnotation data category will be defined in an updated version of this document. For details of the proposed data category, see the ITS 2.0 Requirements document.

External Resource

Definition

The External Resource data category indicates that a node represents or references potentially translatable data in a resource outside the document. Examples of such resources are external images and audio or video files.

Implementation

The External Resource data category can be expressed only with global rules. There is no inheritance. There is no default.

GLOBAL: The externalResourceRefRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required externalResourceRefPointer attribute that contains a relative selector pointing to a node that provides the URI of the external resource. The externalResourceRefRule element

The externalResourceRefRule element expresses that the imagedata, audiodata and videodata elements contain references to external resources. These references are expressed via a fileref attribute. The externalResourceRefPointer attribute points to that attribute.

Two externalResourceRefRule elements used for external resources associated with HTML5 video elements

The two externalResourceRefRule elements select the src and the poster attributes at HTML5 video elements. These attributes identify different external resources, and at the same time contain the references to these resources. For this reason, the externalResourceRefPointer attributes point to the value of src and poster respectively. The underlying HTML5 document is given in .

An HTML5 document that can be used for .

Markup Declarations for External Resource Rule about the External Resource data category. Relative selector pointing to the note that contains the reference to the external resource.

Target Pointer

Definition

Some formats, such as those designed for localization or for multilingual resources, hold the same content in different languages inside a single document. The Target Pointer data category is used to associate the node of a given source content (i.e. the content to be translated) and the node of its corresponding target content (i.e. the source content translated into a given target language).

This specification makes no provision regarding the presence of the target nodes or their content: A target node may or may not exist and it may or may not have content.

This data category can be used for several purposes, including but not limited to:

Extract the source content to translate and put back the translation at its proper location.

Compare source and target content for quality verification.

Re-use existing translations when localizing the new version of an existing document.

Access aligned bi-lingual content to build memories, or to train machine translation engines.

In general, it is recommended to avoid developing formats where the same content is stored in different languages in the same document, unless for very specific use cases. See the best practices Working with multilingual documents from for further guidance.

Implementation

The Target Pointer data category can be expressed only with global rules. The information applies to the textual content of the element. There is no inheritance. There is no default.

GLOBAL: The targetPointerRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required targetPointer attribute. It contains a relative selector that points to the node for the target content corresponding to the selected source node.

The source node and the target node may be of different types, but the target node must be able to contain the same content of the source node (e.g. an attribute node cannot be the target node of a source node that is an element with children).

Defining the target location of a source content with the targetPointerRule element

Markup Declarations for Target Pointer Rule about the Target Pointer data category. Contains a relative selector that points to the node for the target content corresponding to the selected source node.

Id Value

Definition

The Id Value data category indicates a value that can be used as unique identifier for a given part of the content.

The recommended way to specify a unique identifier is to use xml:id (See the best practice Defining markup for unique identifiers from ). The idValueRule element is intended only as a fall-back mechanism for documents where unique identifiers are available with another construct.

Providing a unique identifier that is maintained in the original document can be use for several purposes, for example:

Allow automated alignment between different versions of the source document, or between source and translated documents.

Improve the confidence in leveraged translation for exact matches.

Provide back-tracking information between displayed text and source material when testing or debugging.

The Id Value data category only provides for rules to be expressed at a global level. Locally, users are able to use xml:id (which is defined by XML) or an attribute specific to the format in question (as in ).

Applying the Id Value data category to xml:id attributes using global rules is not necessary, since xml:id is the recommended way to specify an identifier in XML.

Implementation

The id Value data category can be expressed only with global rules. There is no inheritance. There is no default.

GLOBAL: The idValueRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required idValue attribute. It contains an XPath expression which constructs a string corresponding to the identifier of the node to which this rule applies should be located. The identifier MUST be unique at least within the document. If the attribute xml:id is present for the selected node, the value of the xml:id attribute MUST take precedence over the idValue value. Pointing to an ID value with the idValueRule element

The idValueRule element indicates that the unique identifier for each <text> element is the value of the attribute name of its parent element.

Constructing ID values using the idValueRule element.

The idValue attribute allows to build composite values based on different attributes, element or event hard-coded text. Any of the String functions offered by XPath can be used. In the document below, the two elements <text> and <desc> are translatable, but they have only one corresponding identifier, the name attribute in their parent element.

To make sure the identifier is unique for both the content of <text> and the content of <desc>, the XPath expression concat(../@name, '_t') gives the identifier "settingsMissing_t" for the content of <text> and the expression concat(../@name, '_d') gives the identifier "settingsMissing_d" for the content of <desc>.

Using xml:id and idValueRule

When an xml:id attribute is present for a node selected by an idValueRule element, the value of xml:id takes precedence over the value defined by the idValueRule element. In the example below, the unique ID to use is “btnAgain” for the first <res> element, and “retryTip” for the second <res> element.

Markup Declarations for Id Value Rule about the Id Value data category. It contains an XPath expression which constructs a string corresponding to the identifier of the node to which this rule applies should be located.

Preserve Space

Definition

The Preserve Space data category indicates how whitespace should be handled in content. The possible values for the Preserve Space data category are "default" and "preserve" and carry the same meaning as the corresponding values of the xml:space attribute. The default value is "default".

Implementation

The Preserve Space data category can be expressed with global rules, or locally using the xml:space attribute.

The Preserve Space data category is not applicable to HTML5 documents because xml:space (and by extension Preserve Space) has no effect in documents parsed as text/html.

GLOBAL: The preserveSpaceRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies. A required space attribute with the value "default" or "preserve". The Preserve Space data category expressed globally

The preserveSpaceRule element specifies that whitespace in all verse elements must be treated literally.

LOCAL: The xml:space attribute, as defined in section 2.10 of , maps exactly to the Preserve Space data category.

The Preserve Space data category expressed locally

The standard xml:space attribute specifies that the whitespace in the verse element must be treated literally.

Markup Declarations for Preserve Space Rule about the Preserve Space data category. It contains an XPath expression which constructs a string corresponding to the identifier of the node to which this rule applies should be located. Default. Whitespace is to be preserved.

Localization Quality Issue This data category is not completely stable yet.

Definition

The Localization Quality Issue data category is used to express information related to localization quality assessment tasks. Such tasks can be conducted on the translation of some source text into a target language or on the source text itself where its quality may impact on the localization process.

This data category can be used in a number of ways, including the following example scenarios:

An automatic quality checking tool flags a number of potential quality issues in an XML or HTML file and marks them up using ITS 2.0 markup. Other tools in the workflow then examine this markup and decide whether the file needs to be reviewed manually or passed on for further processing without a manual review stage.

A quality assessment process identifies a number of issues and adds the ITS markup to a rendered HTML preview of an XML file along with CSS styling that highlights these issues. The resulting HTML file is then sent back to the translator to assist his or her revision efforts.

A human reviewer working with a web-based tool adds quality markup, including comments and suggestions, to a localized text as part of the review process. A subsequent process examines this markup to ensure that changes were made.

The data category defines four pieces of information:

Information Description Value Notes Type A set of broad types of issues into which tool-specific issues can be categorized. One of the values defined in list of type values. ITS 2.0-compliant tools that use these categories MUST map their internal values to these types. If the type of the issue is set to uncategorized, a comment MUST be specified as well. Comment A human-readable description of the quality issue. Text Severity A decimal value representing the severity of the issue, as defined by the model generating the metadata. A decimal value between 0.0 and 100.0 (inclusive), with higher values indicating greater severity. It is up to tools to map the values of this to their own system to this scale. If needed, the original value can be passed along using a custom namespace for XML, or a data- attribute for HTML. Profile Reference A reference to a document describing the quality assessment model used for the issue. A URI pointing to the reference document. The use of resolvable URI is strongly recommended as it provides a way for human evaluators to learn more about the quality issues in use.

Implementation

The Localization Quality Issue data category can be expressed with global rules, or locally on individual elements. The information applies to the textual content of the element, including child elements, but excluding attributes.

GLOBAL: The locQualityIssueRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies.

At least one of the following:

Exactly one of the following:

A locQualityIssuesRef attribute. Its value is a URI pointing to the locQualityIssues element containing the list of issues related to this content.

A locQualityIssuesRefPointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityIssuesRef.

Exactly one of the following:

A locQualityIssueType attribute that implements the type information.

A locQualityIssueTypePointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityIssueType.

Exactly one of the following:

A locQualityIssueComment attribute that implements the comment information.

A locQualityIssueCommentPointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityIssueComment.

None or exactly one of the following:

A locQualityIssueSeverity attribute that implements the severity information.

A locQualityIssueSeverityPointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityIssueSeverity.

None or exactly one of the following:

A locQualityIssueProfileRef attribute that implements the profile reference information.

A locQualityIssueProfileRefPointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityIssueProfileRef.

The attributes locQualityIssuesRefPointer, locQualityIssueTypePointer, locQualityIssueCommentPointer, locQualityIssueSeverityPointer and locQualityIssueProfileRefPointer do not apply to HTML as local markup is provided for direct annotation in HTML.

Annotating an issue in XML with locQualityIssueRule element

The locQualityIssueRule element associates the issue information with a selected span of content.

Using locQualityIssueRule to map equivalent markup

The locQualityIssueRule element defines what constructs are equivalent to the native ITS markup for the different pieces of information of the data category.

Annotating an issue in HTML5 with locQualityIssueRule element

The locQualityIssueRule element resides in a separate file () that associates the issue information with a selected span of content in the HTML document.

External rule document associated with an HTML5 document

This document is used in :

LOCAL: Using the inline markup to represent the data category locally is limited to a single occurrence for a given content (e.g. one cannot have different locQualityIssueType attributes applied to the same span of text because the inner-most one would override the others). A local standoff markup is provided to allow such cases.

The following local markup is available for the Localization Quality Issue data category:

Either (inline markup):

At least one of the following attributes:

A locQualityIssueType attribute that implements the type information.

A locQualityIssueComment attribute that implements the comment information.

An optional locQualityIssueSeverity attribute that implements the severity information.

An optional locQualityIssueProfileRef attribute that implements the profile reference information.

Or (standoff markup):

A locQualityIssuesRef attribute. Its value is a URI pointing to the locQualityIssues element containing the list of issues related to this content.

An element locQualityIssues (or  in HTML) which contains:

One or more elements locQualityIssue (or  in HTML), each of which contains:

At least one of the following attributes:

A locQualityIssueType attribute that implements the type information.

A locQualityIssueComment attribute that implements the comment information.

An optional locQualityIssueSeverity attribute that implements the severity information.

An optional locQualityIssueProfileRef attribute that implements the profile reference information.

Important: When the attributes locQualityIssueType, locQualityIssueComment, locQualityIssueSeverity and locQualityIssueProfileRef (or their equivalent representations) are used in in a standoff manner, the information they carry pertains to the content of the element that refers to the standoff annotation, not to the content of the element locQualityIssue (or in HTML) where they are declared.

Annotating an issue in XML with local inline markup

The attributes locQualityIssueType, locQualityIssueComment and locQualityIssueSeverity are used to associate the issue information directly with a selected span of content.

Annotating an issue in HTML with local inline markup

In this example several spans of content are associated with a quality issue.

Annotating an issue in XML with local standoff markup

The following example shows a document using local standoff markup to encode several issues. The mrk element delimits the content to markup and holds a locQualityIssuesRef attribute that points to the locQualityIssues element where the issues are listed.

Annotating an issue in XML with local standoff markup and a global rule

The following example shows a document using local standoff markup to encode several issues. But because, in this case, the mrk element does not allow attributes from another namespace we cannot use locQualityIssuesRef directly. Instead, a global rule is used to map the function of locQualityIssuesRef to a non-ITS construct, here the ref attribute of any mrk elements that has its attribute type set to "x-itslq".

Annotating an issue in HTML with local standoff markup

The following example shows a document using local standoff markup to encode several issues. The span element delimits the content to markup and holds a loc-quality-issues-ref attribute that points to a special span element where the issues are listed within a set of other special span elements.

TODO for above: Finalize how HTML its-loc-quality-issues and its-loc-quality-issue should be defined.

Markup Declarations for Localization Quality Issue TODO: update to proper declaration and add markup for HTML. Rule about the Localization Quality Issue data category. TODO TODO TODO terminology mistranslation omission untranslated addition duplication inconsistency grammar legal register locale-specific-content locale-violation style characters misspelling typographical formatting inconsistent-entities numbers markup pattern-problem whitespace internationalization length uncategorized other TODO TODO TODO TODO TODO TODO TODO TODO TODO terminology mistranslation omission untranslated addition duplication inconsistency grammar legal register locale-specific-content locale-violation style characters misspelling typographical formatting inconsistent-entities numbers markup pattern-problem whitespace internationalization length uncategorized other TODO TODO TODO List of locQualityIssue elements. A holder for loaclization quality information. TODO terminology mistranslation omission untranslated addition duplication inconsistency grammar legal register locale-specific-content locale-violation style characters misspelling typographical formatting inconsistent-entities numbers markup pattern-problem whitespace internationalization length uncategorized other TODO TODO TODO TODO TODO terminology mistranslation omission untranslated addition duplication inconsistency grammar legal register locale-specific-content locale-violation style characters misspelling typographical formatting inconsistent-entities numbers markup pattern-problem whitespace internationalization length uncategorized other TODO TODO TODO

Localization Quality Précis This data category is not completely stable yet.

Definition

The Localization Quality Précis data category is used to express an overall measurement of the localization quality of a document.

This data category allows to specify a quality score for a given document, as well as to indicate what constitutes a passing score. It also allows to point to a profile where the quality assessment model used for the scoring is described.

Implementation

The Localization Quality Précis data category can be expressed with global rules, or locally on individual elements. The information applies to the textual content of the element, including child elements, but excluding attributes.

GLOBAL: The locQualityPrecisRule element contains the following:

A required selector attribute. It contains an absolute selector which selects the nodes to which this rule applies.

Exactly one of the following:

A locQualityPrecisScore attribute. Its value is an integer between 0 and 100 (inclusive) with higher values indicating a better score.

A locQualityPrecisScorePointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityPrecisScore.

None or exactly one of the following:

A locQualityPrecisThreshold attribute. Its value is an integer between 0 and 100 (inclusive) which indicates the lowest score value that constitutes a passing score in the profile used.

A locQualityPrecisThresholdPointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityPrecisThreshold.

None or exactly one of the following:

A locQualityPrecisProfileRef attribute. Its value is a URI pointing to the reference document describing the quality assessment model used for the scoring.

A locQualityPrecisProfileRefPointer attribute that contains a relative selector pointing to a node with the exact same semantics as locQualityPrecisProfileRef.

The attributes locQualityPrecisScorePointer, locQualityPrecisThresholdPointer, and locQualityPrecisProfileRefPointer do not apply to HTML as local markup is provided for direct annotation in HTML.

The Localization Quality Précis data category expressed globally in XML

The following example shows how to us the locQualityPrecisRule element to specify the score, threshold and profile for a document.

Using pointers to map the Localization Quality Précis data category in XML

The following example shows how to us the locQualityPrecisScorePointer, locQualityPrecisThresholdPointer and locQualityPrecisProfileRefPointer can be used to map the data category to an equivalent markup.

The Localization Quality Précis data category expressed globally in HTML

The following example shows how to us the locQualityPrecisRule element to specify the score, threshold and profile for an HTML document.

External rule document associated with an HTML5 document

This document is used in :

LOCAL: The following local markup is available for the Localization Quality Précis data category:

A locQualityPrecisScore attribute. Its value is an integer between 0 and 100 (inclusive) with higher values indicating a better score.

An optional locQualityPrecisThreshold attribute. Its value is an integer between 0 and 100 (inclusive) which indicates the lowest score value that constitutes a passing score in the profile used.

An optional locQualityPrecisProfileRef attribute. Its value is a URI pointing to the reference document describing the quality assessment model used for the scoring.

The Localization Quality Précis data category expressed locally in XML

The locQualityPrecisScore, locQualityPrecisThreshold and locQualityPrecisProfileRef are used to score the quality of the document.

The Localization Quality Précis data category expressed locally in HTML

The loc-quality-precis-score, loc-quality-precis-threshold and loc-quality-precis-profile-ref are used to score the quality of the document.

Markup Declarations for Localization Quality Issue Rule about the Localization Quality Précis data category. TODO TODO TODO TODO TODO TODO TODO TODO TODO TODO TODO TODO

MT Confidence

The MT Confidence data category will be defined in an updated version of this document.

References Addison Phillips, Mark Davis. <ref target="http://www.rfc-editor.org/rfc/bcp/bcp47.txt">Tags for Identifying Languages</ref> , September 2009. Available at http://www.rfc-editor.org/rfc/bcp/bcp47.txt. Karl Dubost, Lynne Rosental, Dominique Hazaël-Massieux, Lofton Henderson. <ref target="http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/">QA Framework: Specification Guidelines</ref> . W3C Recommendation 17 August 2005. Available at http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/. The latest version of QAFRAMEWORK is available at http://www.w3.org/TR/qaframe-spec/. Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. International Organization for Standardization (ISO) ISO/IEC 19757-2:2003. S. Bradner. Key Words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt. Martin Dürst, Michel Suignard. <ref target="http://www.ietf.org/rfc/rfc3987.txt">Internationalized Resource Identifiers (IRIs)</ref> . RFC 3987, January 2005. See http://www.ietf.org/rfc/rfc3987.txt. Steve DeRose, Eve Maler, David Orchard, Norman Walsh. <ref target="http://www.w3.org/TR/2010/REC-xlink11-20100506/">XML Linking Language 1.1</ref> . W3C Recommendation 6 May 2010. Available at . The latest version of XLink 1.1 is available at http://www.w3.org/TR/xlink11/. Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, et al., editors. <ref target="http://www.w3.org/TR/2006/REC-xml-20060816/">Extensible Markup Language (XML) 1.0 (Fourth Edition)</ref> , W3C Recommendation 16 August 2006. Available at http://www.w3.org/TR/2006/REC-xml-20060816/. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml/. John Cowan, Richard Tobin. <ref target="http://www.w3.org/TR/2004/REC-xml-infoset-20040204/">XML Information Set (Second Edition)</ref> . W3C Recommendation 4 February 2004. Available at http://www.w3.org/TR/2004/REC-xml-infoset-20040204/. The latest version of XML Infoset is available at http://www.w3.org/TR/xml-infoset/. Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin. <ref target="http://www.w3.org/TR/2006/REC-xml-names-20060816/">Namespaces in XML (Second Edition)</ref> . W3C Recommendation 16 August 2006. Available at http://www.w3.org/TR/2006/REC-xml-names-20060816/. The latest version of XML Names is available at http://www.w3.org/TR/REC-xml-names/. Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn. <ref target="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">XML Schema Part 1: Structures Second Edition</ref> . W3C Recommendation 28 October 2004. Available at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. The latest version of XML Schema is available at http://www.w3.org/TR/xmlschema-1/. James Clark. <ref target="http://www.w3.org/TR/1999/REC-xpath-19991116/">XML Path Language (XPath) Version 1.0</ref> . W3C Recommendation 16 November 1999. Available at http://www.w3.org/TR/1999/REC-xpath-19991116/. The latest version of XPath 1.0 is available at http://www.w3.org/TR/xpath/ .

Values for the Localization Quality Issue Type

The locQualityIssueType attribute provides a basic level of interoperability between different localization quality assurance systems. It offers a list of high-level quality issue types common in automatic and human localization quality assessment. Tools can map their internal categories to these categories in order to exchange information about the kinds of issues they identify and take appropriate action even if another tool does not know the specific issues identified by the generating tool.

The values listed in the following table are allowed for locQualityIssueType. The values a tool implementing the data category produces for the attribute MUST match one of the values provided in this table and MUST be semantically accurate. If a tool can map its internal values to these categories it MUST do so and MUST NOT use the value other, which is reserved strictly for values that cannot be mapped to these values.

Value Description Example Scope Notes terminology An incorrect term or a term from the wrong domain was used or terms are used inconsistently. The localization had “Pen Drive” when corporate terminology specified that “USB Stick” was to be used. The localization text inconsistently used "Start" and "Begin". S or T mistranslation The content of the target mistranslates the content of the source. The English source reads "An ape succeeded in grasping a banana lying outside its cage with the help of a stick" but the Italian translation reads "l'ape riuscì a prendere la banana posta tuori dall sua gabbia aiutandosi con un bastone" ("A bee succeeded...") T Issues related to translation of specific terms related to the domain or task-specific language should be categorized as terminology issues. omission Necessary text has been omitted from the localization or source. One or more segments found in the source that should have been translated are missing in the target. S or T This type should not be used for missing whitespace or formatting codes, but instead should be reserved for linguistic content. untranslated Content that should have been translated was left untranslated. The source segment reads "The Professor said to Smith that he would hear from his lawyer" but the Hungarian localization reads "A professzor azt modta Smithnek, hogy he would hear from his lawyer." T omission takes precedence over untranslated. Omissions are distinct in that they address cases where text is not present, while untranslated addresses cases where text has been carried from the source untranslated. addition The translated text contains inappropriate additions. The translated text contains a note from the translator to himself to look up a term; the note should have been deleted but was not. T duplication Content has been duplicated improperly. A section of the target text was inadvertently copied twice in a copy and paste operation. T inconsistency The text is inconsistent with itself (NB: not for use with terminology inconsistency). The text states that an event happened in 1912 in one location but in another states that it happened in 1812. S or T grammar The text contains a grammatical error (including errors of syntax and morphology). The text reads "The guidelines says that users should use a static grounding strap." S or T legal The text is legally problematic (e.g., it is specific to the wrong legal system). The localized text is intended for use in Thailand but includes U.S. regulatory notices. A text translated into German contains comparative advertising claims that are not allowed by German law. S or T register The text is written in the wrong linguistic register of uses slang or other language variants inappropriate to the text. A financia text in U.S. English refers to dollars as "bucks". S or T locale-specific-content The localization contains content that does not apply to the locale for which it was prepared. A text translated for the Japanese market contains call center numbers in Texas and refers to special offers available only in the U.S. S or T Legally inappropriate material should be classified as legal. locale-violation Text violates norms for the intended locale. A text localized into German has dates in YYYY-MM-DD format instead of in DD.MM.YYYY. A text for the Irish market uses American-style foot and inch measurements instead of centimeters. S or T style The text contains stylistic errors. Company style guidelines dictates that all individuals be referred to as Mr. or Ms. with a family name, but the text refers to “Jack Smith”. S or T characters The text contains characters that are garbled or incorrect or that are not used in the language in which the content appears. A text should have a '•' but instead has a '¥' sign. A text translated into German omits the umlauts over 'ü', 'ö', and 'ä'. S or T misspelling The text contains a misspelling. A German text misspells the word "Zustellung" as "Zustellüng". S or T typographical The text has typographical errors such as omitted/incorrect punctuation, incorrect capitalization, etc. An English text has the following sentence: "The man whom, we saw, was in the Military and carried it's insignias". S or T formatting The text is formatted incorrectly. Warnings in the text are supposed to be set in italic face, but instead appear in bold face. Margins of the text are narrower than specified. S or T inconsistent-entities The source and target text contain different named entities (dates, times, place names, individual names, etc.) The name "Thaddeus Cahill" appears in an English source but is rendered as "Tamaš Cahill" in the Czech version. The date "February 9, 2007" appears in the source but the translated text has "2. September 2007". S or T numbers Numbers are inconsistent between source and target. A source text states that an object is 120 cm long, but the target text says it is 129 cm. long. S or T Some tools may correct for differences in units of measurement to reduce false positives. markup There is an issue related to markup or a mismatch in markup between source and target. The source segment has five markup tags but the target has only two. An opening tag in the text is missing a closing tag. S or T pattern-problem The text fails to match a pattern that defines allowable content (or matches one that defines non-allowable content). The tool disallows the regular expression pattern ['"”’][\.,] but the translated text contains "A leading “expert”, a political hack, claimed otherwise." S or T whitespace There is a mismatch in whitespace between source and target content. A source segment starts with six space characters but the corresponding target segment has two non-breaking spaces at the start. S or T internationalization There is an issue related to the internationalization of content. A line of programming code has embedded language-specific strings. A user interface element leaves no room for text expansion. A form allows only for U.S.-style postal addresses and expects five digit U.S. ZIP codes. S or T There are many kinds of internationalization issues. This category is therefore very heterogeneous in what it can refer to. length There is a significant difference in source and target length. The translation of a segment is five times as long as the source. T or S What constitutes a "significant" difference in length is determined by the model referred to in the locQualityIssueProfileRef. uncategorized The issue has not been categorized. A new version of a tool returns information on an issue that has not been previously checked and that is not yet classified. S or T This category has two uses: A tool can use it to pass through quality data from another tool in cases where the issues from the other tool are not classified (for example, a localization quality assurance tool interfaces with a third-party grammar checker). A tool's issues are not yet assigned to categories, and, until an updated assignment is made, they may be listed as uncategorized. In this case it is recommended that issues be assigned to appropriate categories as soon as possible since uncategorized does not foster interoperability. other Any issue that cannot be assigned to any values listed above. S or T This category allows for the inclusion of any issues not included in the previously listed values. This value MUST NOT be used for any tool- or model-specific issues that can be mapped to the values listed above. In addition, this value is not synonymous with uncategorized in that uncategorized issues may be assigned to another precise value, while other issues cannot. If a system has an "miscellaneous" or "other" category, it MUST be mapped to this value even if the specific instance of the issue might be mapped to another category.

References Richard Ishida. <ref target="http://www.w3.org/International/articles/inline-bidi-markup/">What you need to know about the bidi algorithm and inline markup</ref>. Article of the W3C Internationalization Activity, June 2005. Bert Bos, Tantek Çelik, Ian Hickson Håkon Wium Lie. <ref target="http://www.w3.org/TR/2011/REC-CSS2-20110607/">Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification</ref> . W3C Recommendation 7 June 2011. Available at http://www.w3.org/TR/2011/REC-CSS2-20110607/. The latest version of CSS2 is available at http://www.w3.org/TR/CSS21/. Michael Priestley, JoAnn Hackos, et. al., editors. <ref target=" https://www.oasis-open.org/committees/download.php/15316/dita10.zip">OASIS Darwin Information Typing Architecture (DITA) Language Specification v1.0</ref>. OASIS Standard 9 May 2005. Available at https://www.oasis-open.org/committees/download.php/15316/dita10.zip. Norman Walsh and Leonard Muellner. <ref target="http://www.docbook.org/">DocBook: The Definitive Guide</ref> . Available at http://www.docbook.org/. Richard Ishida, Susan Miller. Localization vs. Internationalization. Article of the W3C Internationalization Activity, January 2006. Ian Hickson <ref target="http://www.w3.org/TR/html5/">HTML5 – A vocabulary and associated APIs for HTML and XHTML</ref> . W3C Working Draft 29 March 2012. Available at http://www.w3.org/TR/html5/. (International Organization for Standardization). TermBase eXchange (TBX). [Geneva]: International Organization for Standardization, 2008. Yves Savourel. <ref target="http://www.w3.org/TR/2006/WD-itsreq-20060518/">Internationalization and Localization Markup Requirements</ref> . W3C Working Draft 18 May 2006. Available at http://www.w3.org/TR/2006/WD-itsreq-20060518/. The latest version of ITS REQ is available at http://www.w3.org/TR/itsreq/. Richard Ishida, Yves Savourel <ref target="http://people.w3.org/rishida/localizable-dtds/">Requirements for Localizable DTD Design</ref>. Working Draft 7 July 2003. Available at http://people.w3.org/rishida/localizable-dtds/. Tantek Çelik, Elika J. Etemad, Daniel Glazman, Ian Hickson, Peter Linss, John Williams <ref target="http://www.w3.org/TR/css3-selectors/">Selectors Level 3</ref> . W3C Recommendation 29 September 2011. Available at http://www.w3.org/TR/css3-selectors/. Information technology -- Document Schema Definition Languages (DSDL) -- Part 4: Namespace-based Validation Dispatching Language (NVDL). International Organization for Standardization (ISO) ISO/IEC 19757-4:2003. Michael Brauer et al. <ref target=" https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office">OASIS Open Document Format for Office Applications (OpenDocument).</ref> . Oasis Standard 1 May 2005. Available at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office. The latest version of OpenDocument is available at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office. Harald Alvestrand. <ref target="http://www.ietf.org/rfc/rfc3066.txt">Tags for the Identification of Languages</ref>. RFC 3066, January 2001. Available at http://www.ietf.org/rfc/rfc3066.txt. Marcin Sawicki (until 10 October, 1999), Michel Suignard, Masayasu Ishikawa (石川雅康), Martin Dürst, Tex Texin, <ref target="http://www.w3.org/TR/ruby/">Ruby Annotation</ref> . W3C Recommendation 31 May 2001. Available at http://www.w3.org/TR/2001/REC-ruby-20010531/ . The latest version of Ruby Annotation is available at http://www.w3.org/TR/ruby/. Information technology -- Document Schema Definition Languages (DSDL) -- Part 3: Rule-based validation -- Schematron. International Organization for Standardization (ISO) ISO/IEC 19757-3:2003. Lou Burnard and Syd Bauman (eds). <ref target="http://www.tei-c.org/Guidelines/P5/">Text Encoding Initiative Guidelines development version (P5)</ref> . TEI Consortium, Charlottesville, Virginia, USA, Text Encoding Initiative. Steven Pemberton et al. <ref target="http://www.w3.org/TR/2002/REC-xhtml1-20020801/">XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition)</ref> . W3C Recommendation 26 January 2000, revised 1 August 2002. Available at http://www.w3.org/TR/2002/REC-xhtml1-20020801/. The latest version of XHTML 1.0 is available at http://www.w3.org/TR/xhtml1/. Yves Savourel, Jirka Kosek, Richard Ishida. <ref target="http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/">Best Practices for XML Internationalization</ref>. Available at http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/. The latest version of xml-i18n-bp is available at http://www.w3.org/TR/xml-i18n-bp/. <ref target="http://www.w3.org/2002/xmlspec/">The XML Spec Schema and Stylesheets</ref> . Available at http://www.w3.org/2002/xmlspec/. James Clark. <ref target="http://www.w3.org/TR/1999/REC-xslt-19991116">XSL Transformations (XSLT) Version 1.0</ref> . W3C Recommendation 16 November 1999. Available at http://www.w3.org/TR/1999/REC-xslt-19991116. The latest version of XSLT 1.0 is available at http://www.w3.org/TR/xslt. <ref target="http://www.xulplanet.com/">exTensible User Interface Language</ref> . Available at http://www.xulplanet.com/.

Summary of ITS Markup

This section is informative.

Needs to be updated with the additional data categories, once available.

The following list summarizes elements relating to global rules and their attributes:

<rules> Container for global rules.

href

Pointer to external rules files.

type

Type of pointer to external rules files.

Legal values are:

simple

version

Version of the ITS schema.

<dirRule> Rule about the Directionality data category.

dir

The text direction for the selection.

Legal values are:

ltr

rtl

lro

rlo

selector

Absolute selector identifying the nodes to be selected.

<langRule> Rule about the Language Information data category.

langPointer

Relative selector pointing to a node that contains language information.

selector

Absolute selector identifying the nodes to be selected.

<locNote> Contains a localization note.

translate

The Translate data category information to be attached to the current node.

locNote

Localization note.

locNoteType

The type of localization note.

locNoteRef

URI referring to the location of the localization note.

termInfoRef

Pointer to a resource containing information about the term.

term

Indicates a term locally.

dir

The text direction for the context.

<locNoteRule> Rule about the Localization Note data category.

locNotePointer>

Relative selector pointing to a node that holds the localization note.

locNoteType

The type of localization note.

Legal values are:

alert

description

locNoteRef

URI referring to the location of the localization note.

locNoteRefPointer

Relative selector pointing to a node that holds the URI referring to the location of the localization note.

selector

Absolute selector identifying the nodes to be selected.

<termRule> Rule about the Terminology data category.

term

Indicates whether the selection is a term or not.

Legal values are:

yes

termInfoRef

URI referring to the resource providing information about the term.

termInfoRefPointer

Relative selector pointing to a node containing a URI referring to the resource providing information about the term.

termInfoPointer

Relative selector expression pointing to a node containing information about the term.

selector

Absolute selector identifying the nodes to be selected.

<translateRule> Rule about the Translate data category.

translate

The Translate data category information to be applied to selected nodes.

Legal values are:

yes

selector

Absolute selector identifying the nodes to be selected.

<withinTextRule> Rule about the Elements Within Text data category.

withinText

States whether current context is regarded as "within text".

Legal values are:

yes

nested

selector

Absolute selector identifying the nodes to be selected.

<rubyRule> Rule about the Ruby data category.

rubyPointer

Relative selector pointing to a node that corresponds to a ruby element

rtPointer

Relative selector pointing to a node that corresponds to a rt element

rpPointer

Relative selector pointing to a node that corresponds to a rp element

selector

Absolute selector identifying the nodes to be selected.

The following list summarizes elements that are available for local use:

Inline element to contain ITS information.

<rp> 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.

<rt> Ruby text.

<ruby> Ruby markup.

The following list summarizes attributes that are available for local use, with the local elements mentioned above, or with other elements in a host schema:

translate

The Translate data category information to be attached to the current node.

locNote

Localization note.

locNoteType

The type of localization note.

locNoteRef

URI referring to the location of the localization note.

termInfoRef

Pointer to a resource containing information about the term.

term

Indicates a term locally.

dir

The text direction for the context.

Schemas for ITS

This section is informative.

This section needs to be written with a schema for HTML5; the existing schemas need to be updated with the data categories new in ITS 2.0.

The following schemas define ITS elements and attributes and could be used as building blocks when you want to integrate ITS markup into your own XML vocabulary. You can see examples of such integration in Best Practices for XML Internationalization. The schemas are not intended to be used alone for validation of documents with ITS markup.

The following schemas are provided:

DTD for ITS

XML Schema document for ITS

RELAX NG compact syntax document for ITS

RELAX NG XML syntax document for ITS

Checking ITS Markup Constraints With Schematron

This section is informative.

Several constraints of ITS markup cannot be validated with ITS schemas. The following document allows for validating some of these constraints.

Testing constraints in ITS markup

Checking ITS Markup with NVDL

This section is informative.

The following document allows validation of ITS markup which has been added to a host vocabulary. Only ITS elements and attributes are checked. Elements and attributes of host language are ignored during validation against this NVDL document/schema.

NVDL schema for ITS <rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"> <namespace ns="http://www.w3.org/2005/11/its"> <validate schema="its-elements.rng"/> </namespace> <namespace ns="http://www.w3.org/2005/11/its" match="attributes"> <validate schema="its-attributes.rng"/> </namespace> <anyNamespace> <allow/> </anyNamespace> </rules>

[Source file: its.nvdl]

The NVDL schema depends on the following two schemas:

These schemas need to be provided in an updated draft.

RELAX NG schema for ITS elements

RELAX NG schema for ITS attributes

Revision Log

The following log records major changes that have been made to this document since the ITS 2.0 Working Draft 31 July 2012.

Added . Added . Added . Added support for different query language and reworked whole XPath and CSS Selectors integration. Added examples to . Simplified . Added a note about HTML5 and the attributes dir and translate to . Added definition of param element to . Added . Original Ruby markup model changed to HTML5 Ruby model. Updated references. Added . Added and the related . Added . Added a placeholder .

The following log records major changes that have been made to this document since the ITS 2.0 Working Draft 26 June 2012.

Various editorial changes (non-normative references update, style & grammar fixes). Made clarifications to , . Added explanatory note on precedence and overriding in . Reordered some components in . Restructured . Added as a stub. Added . Added . Added . Added local markup in . Added . Updated examples to use the version attribute with the value 2.0.

The following log records major changes that have been made to this document between the ITS 1.0 Recommendation and this document.

Clarified introduction to cover ITS 2.0 Added a subsection on the relation to ITS 1.0 to the introduction, see Created HTML5 based declarations for various data categories, see e.g. HTML5 declarations for the Terminology data category and the summary for local data categories in Created examples for these declarations, see e.g. Added placeholders for new data categories to Added a placeholder section

Acknowledgements

This document has been developed with contributions by the MultilingualWeb-LT Working Group: Mihael Arcan (DERI Galway at the National University of Ireland, Galway, Ireland), Pablo Badía (Linguaserve), Aaron Beaton (Opera Software), Luis Bellido (Universidad Politécnica de Madrid), Aljoscha Burchardt (German Research Center for Artificial Intelligence (DFKI) Gmbh), Nicoletta CalzolarI (CNR--Consiglio Nazionale delle Ricerche), Giuseppe Deriard (Linguaserve), Pedro Luis Díez Orzas (Linguaserve), David Filip (University of Limerick), Leroy Finn (Trinity College Dublin), Karl Fritsche (Cocomore AG), Daniel Grasmick (Lucy Software and Services GmbH), Declan Groves (Centre for Next Generation Localisation), Moritz Hellwig (Cocomore AG), Tao Hong (Baidu, Inc.), Dominic Jones (Trinity College Dublin), Milan Karásek (Moravia Worldwide), Jirka Kosek (University of Economics, Prague), Michael Kruppa (Cocomore AG), Maxime Lefrançois (Institut National de Recherche en Informatique et en Automatique (INRIA)), David Lewis (Trinity College Dublin), Fredrik Liden (ENLASO Corporation), Arle Lommel (German Research Center for Artificial Intelligence (DFKI) Gmbh), Shaun McCance ((public) Invited expert), Jan Nelson (Microsoft Corporation), Des Oates (Adobe Systems Inc.), Carina Pellar (Cocomore AG), Georg Rehm (German Research Center for Artificial Intelligence (DFKI) Gmbh), Phil Ritchie (VistaTEC), Thomas Rüdesheim (Lucy Software and Services GmbH), Nieves Sande (German Research Center for Artificial Intelligence (DFKI) Gmbh), Felix Sasaki (W3C Staff), Yves Savourel (ENLASO Corporation), Jörg Schütz (W3C Invited Experts), Ankit Srivastava (Centre for Next Generation Localisation), Tadej Štajner (Jozef Stefan Institute), Olaf-Michael Stefanov ((public) Invited expert), Najib Tounsi (Ecole Mohammadia d'Ingenieurs Rabat (EMI)), Ronny Unger (Cocomore AG), Piek Vossen (Vrije Universiteit).