Introduction

This section is informative.

This document defines a standard for high-quality, cost efficient internationalization and localization of schemas and XML instances (both existing ones and new ones). On the one hand, the standard is defined conceptually through the notion of data categories. On the other hand, the standard defines implementations of these data categories as a set of elements and attributes called the Internationalization Tag Set (ITS). The document provides examples of how ITS can be used with existing popular markup schemes such as DocBook. Furthermore, the document provides implementations for three schema languages: XML DTD Extensible Markup Language (XML) 1.0 (Third Edition), XML Schema XML Schema Part 1: Structures Second Edition and RELAX NG RELAX NG Specification. Feedback related to this document is especially appreciated on the general concept of ITS and the mechanisms defined for the selection of ITS-specific information in documents, and on the design of the individual data categories.

Requirements for this document are formulated in Internationalization and Localization Markup Requirements. Not all requirements listed there are addressed in this document. Those which are not addressed here are either covered in Best Practices for XML Internationalization or may be addressed in a future version of this specification.

This document covers the following requirements:

- R002 - span-like element, see span
- R006 - identifying language/locale, see Language Information
- R007 - identifying Terms, see Terminology
- R008 - purpose specification/mapping, see Associating ITS Data Categories with Existing Markup
- R011 - bidirectional text support, see Directionality
- R012 - indicator of translatability, see Translatability
- R014 - limited impact, see Associating ITS Data Categories with Existing Markup
- R017 - localization notes, see Localization Information
- R020 - annotation markup, see Ruby
- R025 - elements and segmentation, see Elements Within Text

The following requirements will be addressed in Best Practices for XML Internationalization:

- R003 - CDATA Section
- R004 - Unique Identifier
- R005 - Handling of Entities
- R015 - Attributes and Translatable Text
- R016 - Naming Scheme
- R019 - Multilingual Documents
- R022 - Nested Elements

The Working Group decided not to cover the following requirements at this time to be able to focus on the most important ones.

- R001 - Indicator of Constraints
- R009 - Content Style
- R010 - Link to Internal/External Text
- R013 - Metrics Count
- R018 - Handling of White-Spaces
- R021 - Identifying Date and Time
- R023 - Linguistic Markup
- R024 - Variables
- R026 - Associated Objects

The Working Group will cover some of the requirements which currently are not covered here in a separate document Best Practices for XML Internationalization on best practices for internationalization and localization of schemas and XML documents.

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.

- Schema developers who start a schema from ground up

This type of user will find proposals for attribute and element names to be included in their new schema (aka “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 the required markup is available, and that the behaviour of that markup meets established needs.

- Schema developers who work 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, and the ITS specification provides examples of how those formats (aka “host vocabulary”) could be used with ITS.

[^1]

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 Associating ITS Data Categories with Existing Markup). The developer should, however, check that the behaviour 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 users encompasses companies which provide tools for authoring, translation or other flavours 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 standardising 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 users comprises authors, translators and other types of content authors. The markup proposed in this specification may be used by them to mark up specific bits of content. Aside: The burden of inserting markup should 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.

[^1: The Working Group covers the question “How use ITS with existing popular markup schemes?” in more detail in a separate document Best Practices for XML Internationalization.]

In order to support all of these users, the information about what markup should be supported to enable worldwide use and effective internationalization and localization of content is provided in this specification in two ways:

- abstractly in the data category descriptions: Description of Data Categories
- concretely in the ITS schemas: Schemas for ITS

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 answer the question, 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

- 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

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

Use of ITS by processor

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

The first two approaches above can be likened to the use of CSS in XHTML. Using a @style attribute, an XHTML content author may assign a colour 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 coloured red.

Motivation for ITS

Content or software that is authored in one language (so-called 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 demarcate 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 Richard Ishida, Susan Miller. Localization vs. Internationalization. Article of….

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 exTensible User Inferface Language) creates challenges and opportunities in the domain of XML internationalization and localization.

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

Document with partially translatable content

<PhaseCode> should not be translated; the @title attribute sometimes has to be translated and sometimes must not be translated.

Document with partially translatable content

The first file name in the first <component> element would not be translated.

Document with partially translatable content

In the example below, there are no clear mechanisms allowing one to know which <string> element needs to be translated.

Out of Scope

This standard does not exhaustively cover all mechanisms and data formats which might be needed for configuring localization workflows or tools to process a specific format. These mechanisms and data formats, sometimes called Localization Properties, however, possibly may be implemented by the framework put forth in this standard.

[“XML localization properties” is a generic term to name the mechanisms and data formats that allows 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

[^2]

[^2: Attention: The design of the ITS schema in Processing of ITS information and Description of Data Categories is still under development. Thus, the ITS schema structure may change. However, the Working Group does not intend extensive changes to the element and attribute names and their functionality.]

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

Powerful selection mechanism: For ITS markup which appears in an XML instance, it has to be clearly defined to which XML nodes the ITS-related information pertains. 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 XML Information Set (Second Edition). ITS applications may implement inclusion mechanisms such as XInclude or DITA's OASIS Darwin Information Typing Architecture (DITA)… conref.

Content authors need for example a simple way to work with the translatability data category in order to express whether the content of an element or attribute should be translated or not. Localization coordinators, on the other hand, need an efficient way for managing translations of large document sets based on the same schema. This could by realized by a specification of defaults for translatability and exceptions from the defaults (e.g. all <p> elements should be translated, but not <p> elements inside of an <index> element).

This specification responds to these requirements by introducing mechanisms for specifying ITS information in XML documents, see Processing of ITS information. These mechanisms also provide a means for specifying ITS information for attributes (a task for which no standard means yet exists). The ITS mechanisms for selection are:

- as for XML documents, usable local (at the XML node to which it pertains) or globally (not at the XML node to which it pertains)
- as for global usage: possibly in the target XML 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 Namespaces in XML) may be used.

Ease of integration:

- ITS follows the example from section 4 of XML Linking Language 1.0, 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 Internationalization and Localization Markup Requirements. Only for some requirements additional child elements have to be used, see for example Ruby.
- ITS has no dependency on technologies which are still under development
- ITS fits with existing work in the W3C architecture (e.g. use of XPath XML Path Language (XPath) Version 1.0 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 (Text Encoding Initiative Guidelines development version (P5)). 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 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.

Basic Concepts

This section is informative.

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

The mechanisms defined for ITS selection resemble those defined in Cascading Style Sheets, level 2. The local approach can be compared to the @style attribute in CSS, and the approach with global rules is similar to the <style> element in CSS. In contrast to CSS, ITS uses XPath for identifying nodes. 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.

The following two examples sketch the distinction between the local and global approaches.

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

The example above shows how a content author may use the ITS @translate attribute to indicate what text should be translated and what text 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.

For this 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.

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

The example above shows a different approach to identifying non-translatable content, similar to that used with a <style> element in XHTML, but using an ITS-defined element called <rules>. It works as follows: A document can contain a <rules> element (it is recommended to use a “head” section), which contains one or more data category specific ITS elements (for example <translateRule>). Each of these specific elements contains a @selector attribute. As its name suggests, this attribute selects (or designates) the XML node or nodes to which a corresponding ITS information pertains. The values of ITS selector attributes are XPath absolute location paths. Information for the handling of namespaces in these path expressions is contained in the ITS element <ns> which is a child of <rules>.

For this to work, the schema developer needs to add the <rules> element and associated markup to the schema. In some cases this may allow the schema developer to avoid adding other ITS markup (such as an @translate attribute) to the elements 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 translatability 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 XML nodes (for example all <p> elements in an XML instance)
- Changes can be done in a single location, rather than by searching and modifying the 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 data category translatability
- the attribute @translate holds a value of "no"

To summarize: The examples with global and local usage of ITS markup show that ITS markup, in some cases, appears in elements defined by ITS itself (the <translateRule> element (embedded within a <rules> element)) and in other cases appears in elements of the host vocabulary. In addition to one or more ITS data category specific attributes, <translateRule> or other rule elements contain a corresponding @selector attribute. As their name suggests, a @selector selects (or designates) one or more XML nodes (namely those to which a corresponding ITS data category attribute pertains). The value of ITS selector attributes are XPath absolute location paths. Information for to the handling of namespaces in these path expression is contained in the ITS element <ns> which is a child of <rules>.

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)

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

Overriding and Inheritance

In this example, the ITS data category attribute @translate appears twice: in a <rules> element, and on a specific <p> element. Since the ITS @selector attribute in the <rules> element selects all <p> elements, a question arises: What is the value for the translatability data category of the <p> element which has local markup? ITS provides precedence and inheritance rules which answer questions like this. In the example, the value is "no" (that is to say, the content of the <p> element should not be translated).

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 data category for localization information can be used to add information to selected nodes, or to point at existing information in the document. For the former purpose, a <locInfo> element can be used. For the latter purpose, a @locInfoPointer attribute can be used.

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 which express a closed set of values, that is: translatability, directionality 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 S. Bradner. Key Words for use in RFCs to Indicate Requirement Levels. IETF RFC….

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 modelling 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 which 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 Description of Data Categories
- schema language independent formalization, see the "markup declarations" subsections in Description of Data Categories
- schema language specific implementations, see Schemas for ITS

A data category and its implementation

The data category translatability 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 e.g. an XML DTD, an XML Schema document or an RELAX NG document. A different implementation would be a <translateRule> element which allows for specifying global rules about translatability.

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 Processing of ITS information. Selection can be applied globally, see Global, Rule-based Selection, and locally, see Local Selection in an XML Document. 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 which is given in the XML Information Set XML Information Set (Second Edition). ITS applications MAY implement inclusion mechanisms such as XInclude or DITA's OASIS Darwin Information Typing Architecture (DITA)… conref.

[The selection of the ITS data categories applies to text 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 translatability 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]

Conformance

This section is normative.[^3]

[^3: The working group is looking for feedback on the feasibility of the ITS conformance clauses.]

The usage of the term conformance clause in this section is in compliance with QA Framework: Specification Guidelines.

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 which 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 Conformance Type 2: The Processing Expectations for ITS Markup.

Definitions related to this conformance type: ITS markup declarations are defined in various subsections in Processing of ITS information and Description of Data Categories (e.g. Markup Declarations for Localization Information) 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 XHTML).

- 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 Best Practices for XML Internationalization.

[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 which uses parameter entities). The ITS schemas in the format of XML DTD, XML Schema and RELAX NG in Schemas for ITS are only informative examples.

Since the goal of the ITS Working Group is to deliver one set of declarations, the conformance clauses defined in this section do not allow a schema to use only parts of the ITS markup declarations. However, this concerns only the ITS markup declarations in a schema.]

Conformance Type 2: The Processing Expectations for ITS Markup

Description: Processors need to compute the ITS information which 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, and precedence. The markup MAY be valid against a schema which conforms to the clauses in Conformance Type 1: ITS Markup Declarations.

Definitions related to this conformance type: The processing expectations for ITS markup make use of selection mechanisms defined in Processing of ITS information. The individual data categories defined in Description of Data Categories have default selections, and allow for using ITS markup in various positions (global and local). In addition, a set of processing expectations specific to the ruby data category and the directionality data category, refer to external specifications.

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

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

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 Precedence between Selections, for the type of selections it processes.

- 2-2: If an application claims to process ITS markup for the ruby data category or the directionality data category, it MUST be compliant with the external specifications referenced for ruby or directionality.

- 2-3: 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.

[^4]

[^4: Examples of applications which conform to the processing expectations for ITS markup will be given in a test suite, which will be developed for a subsequent version of this document.]

Processing of ITS information

This section is normative.

Summary of ITS Markup

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

The following list summarizes elements and attributes to be used locally:

Indicating the Version of ITS

The version of the ITS schema defined in this specification is "1.0". The version is indicated by the ITS @version attribute. This attribute is mandatory for the <rules> element, where it MUST be in the ITS namespace and use its prefix, e.g. its:version. If there is no <rules> element in an XML document, the ITS @version attribute MUST be provided on 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.

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 an @selector attribute and possibly other attributes. The @selector attribute contains an AbsoluteLocationPath as described in XML Path Language (XPath) Version 1.0.
- locally in a document: the selection is realized using ITS local attributes, which are attached to the selected 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 Position and Default Selections of Data Categories.

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 at 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 data category localization information can be used for adding information to selected nodes, or for pointing to existing information in the document. For the former purpose, an <locInfo> element can be used. For the latter purpose, a @locInfoPointer attribute can be used.

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 which express a closed set of values, that is: translatability, directionality 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 at the same rule element.

Another difference between adding and pointing is the usage of XPath:

- [^5]

The value of the @selector attribute MUST be an XPath expression which starts with "/". That is, it must be an AbsoluteLocationPath as described in XML Path Language (XPath) Version 1.0. This ensures that the selection is not relative to a specific location. The resulting nodes MUST be either element or attribute nodes.

- As for data category specific attributes like @locInfoPointer which point to existing information in the document, a RelativeLocationPath as described in XML Path Language (XPath) Version 1.0 MUST be used. The XPath expression is evaluated relative to the nodes which are selected via the @selector attribute.

[^5: The working group is looking for feedback on a proposal to group rule elements.]

If namespaces Namespaces in XML are used in XPath expressions in the @selector attribute or the pointing attributes, the following rules MUST be applied while processing XPath:

- For each prefix, there MUST be an <ns> element as a child of the <rules> element. The <ns> element has two attributes @prefix (for the namespace prefix) and @uri (for the namespace URI).
- Element and attribute names without a prefix are interpreted as having no namespace.
- To avoid a conflict with rule 2., default namespaces MUST NOT be used in the XPath expressions.

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 <qterm> element from DocBook is in no namespace.

[The usage of the <ns> element is inspired by Schematron - A Language for Making Assertions about… and compliant to the requirements on namespace bindings described in Using Qualified Names (QNames) as Identifiers in XML Content.]

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 Precedence between Selections.

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

<rules>
Container for global rules.

@xmlns
The ITS namespace.

http://www.w3.org/2005/11/its A valid XML namespace
@xmlns:its
The ITS namespace.

http://www.w3.org/2005/11/its A valid XML namespace
@href
Pointer to external rules files.

<ns>
An element to describe namespace URIs and prefixes within XPath expressions in <rules> elements.
@prefix
The namespace prefix used in selection expressions.
@uri
The namespace being identified.

att.selector
XPath selection attribute.
@selector
Expression identifing the nodes to be selected.

att.version
ITS version attribute.
@version
Version of the ITS schema.
1.0

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 wrapper for the local ITS attributes and <ruby>.

It depends on the data category what is being selected. The necessary data category specific defaults are described in Position and Default Selections of Data Categories.

Defaults for various data categories

its:translate="no" at the head element means that the textual content of this element, including child elements, should not be translated. its:translate="yes" at the body element means that the textual content of this element, including child elements, should be translated. Attribute values of the selected elements or their children's are not affected by local @translate attributes. By default they are not translatable.

its:dir="ltr" at the <body> element means that the directionality of the textual content of this element, including child elements and attributes, is "left-to-right".

Markup for local selection is defined as follows.

<span>
Inline element to contain ITS information.

@xmlns
The ITS namespace.

http://www.w3.org/2005/11/its A valid XML namespace
@xmlns:its
The ITS namespace.

http://www.w3.org/2005/11/its A valid XML namespace

Link to External Rules

One way to associate a document with a set of external ITS rules is to use the optional XLink XML Linking Language 1.0@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 myRules.xml with global rules:

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

Document with a link to myRules.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

Application 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)
- Global selections in an external file (using a <rules> element), linked via the XLink @href attribute or a different mechanism
- Selections via defaults for data categories, see Position and Default Selections of Data Categories

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

[The precedence order fulfills the same purpose as the built-in template rules of XSL Transformations (XSLT) Version 1.0.]

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

Due to the rules described above, the local translatability information from the @translate attribute on the <p> element has precedence over the translatability information on the first <translateRule> element. A conflict occurs for <p> elements inside of <entry> elements, because of the two <translateRule> elements. This conflict is resolved via the order of the <translateRule> elements (the last one has higher precedence).

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 Global, Rule-based Selection. In this way, there is no need to integrate ITS markup into documents.

Associating existing markup with ITS data categories can be only done if the processing expectations are the same or if the processing expectations of the host markup cover at least the same as ITS.

Association of the ITS data categories translatability and terminology with OASIS Darwin Information Typing Architecture (DITA)… markup

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 (Text Encoding Initiative Guidelines development version (P5)). 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 and Default Selections of Data Categories

The following table summarizes the relations between data categories, location of their selection mechanisms, and default selections in XML documents.

Data category	Local Usage	Global, rule-based selection	Global adding of information	Global pointing to existing information	Default selection in document
Translatability	+	+	+	-	Textual content of element, including content of child elements, but excluding attributes
Localization information	+	+	+	+	Textual content of element, including content of child elements, but excluding attributes
Terminology	+	+	+	+	Textual content of element, including content of child elements, but excluding attributes
Directionality	+	+	+	-	Textual content of element, including attributes and child elements
Ruby	+	+	+	+	Textual content of element, including content of child elements, but excluding attributes
Language Information	-	+	-	+	Textual content of element, including attributes and child elements
Elements within Text	-	+	+	-	Textual content of element, excluding child elements

[The data categories differ with respect to defaults in the XML document for compatibility reasons with existing standards and practices. For example, the @dir attribute taken from XHTML™ 2.0 refers to the content of the element and all attributes and child elements. Hence, the data category of directionality selects the same information as the default. On the other hand, it is common practice that information about translatability refers only to textual content of an element. Hence, the data category of translatability selects as a default the same information.]

Translatability

Definition

The data category translatability 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

Translatability can be expressed with global rules, or locally on an individual element.

As for global rules, translatability is expressed with a <translateRule> element with a @translate attribute. The attribute has the values "yes" or "no". In addition, a @selector attribute is required.

Translatability expressed globally

Locally, translatability is expressed with a @translate attribute with the values "yes" or "no" The selection is the textual content of the element, including child elements, but excluding attributes.

Translatability expressed locally

In the <body> element, its textual content and the content of all elements should be translated. The content of the specified quote element, however, must not be translated.

Markup Declarations for Translatability

<translateRule>
Rule about translatability.
@translate
The translatability information to be applied to selected nodes.
"yes"
The nodes need to be translated.
"no"
The nodes must not be translated.

att.translate
Translatability information to be attached to current node.
@translate
"yes"
The nodes need to be translated.
"no"
The nodes must not be translated.

Localization Information

Definition

The data category localization information is used to communicate information to localizers about a particular item of content.

This data category has several purposes:

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

Implementation

Localization information can be expressed with global rules, or locally on an individual element.

Using global rules, addition of localization information to selected nodes is achieved with a <locInfoRule> element, which has a mandatory @selector attribute and a mandatory @locInfoType attribute. The information associated to the selection can be indicated in different ways using either a <locInfo> element, a @locInfoRef attribute, a @locInfoPointer attribute, or a @locInfoRefPointer attribute. The <locInfo> element, @locInfoRef attribute, @locInfoPointer attribute, and @locInfoRefPointer MUST NOT occur together.

Localization information expressed in rules

Pointing to existing localization information is provided by a @locInfoPointer attribute or a @locInfoRefPointer attribute on the <locInfoRule> element. These two attributes MUST NOT occur together. The @selector attribute is mandatory.

The <locInfo> element contains the information itself.

The <locInfo> element

The @locInfoRef attribute is an URI referring to the location of the information.

The @locInfoRef attribute

The @locInfoPointer attribute is a relative XPath expression pointing to a node that holds the information.

The @locInfoPointer attribute

The @locInfoRefPointer attribute contains a relative XPath expression pointing to a node that holds the URI referring to the location of the information.

The @locInfoRefPointer attribute

Locally in a document, localization information is expressed with the attributes @locInfo or @locInfoRef, and @locInfoType. @locInfo and @locInfoRef MUST NOT occur together. If the @locInfoType attribute is not present, the type of localization information will be assumed as description. The selection is the textual content of element, including child elements, but excluding attributes.

Localization information expressed locally in a document

Markup Declarations for Localization Information

<locInfoRule>
Rule about localization information.
@locInfoPointer
Relative XPath expression pointing to a node that holds the localization information.
@locInfoType
The type of localization information.
"alert"
Localization information is an alert.
"description"
Localization information is a description.
@locInfoRef
URI referring to the location of the localization information.
@locInfoRefPointer
Relative XPath expression pointing to a node that holds the URI referring to the location of the localization information.

<locInfo>
Contains localization information.

att.locInfo
@locInfo
Localization information.
@locInfoType
The type of localization information.
"alert"
Localization information is an alert.
"description"
Localization information is a description.
@locInfoRef
URI referring to the location of the localization information.

Terminology

Definition

The terminology data category is used to mark terms. This helps to increase consistency across different parts of the documentation. It is also helpful for translation.

Implementation

The terminology data category can be expressed with global rules, or locally on an individual element.

As for global rules, identifying terminology information at selected nodes is realized with a <termRule> element with a mandatory @selector attribute. In addition, an optional @termInfoRef attribute can be used to refer to external information about the term. The datatype of @termInfoRef is xs:anyURI. To point to a link to a term reference in the current document, a @termInfoRefPointer attribute can be used. @termInfoRef and @termInfoRefPointer MUST NOT be used together.

Usage of the @termInfoRefPointer attribute

Locally in a document, the terminology data category is expressed with a @term attribute, which has the value "yes", and an optional @termInfoRef attribute. The selection is the textual content of the element, including content of child elements, but excluding attributes.

The terminology data category expressed in an instance document

Markup Declarations for Terminology

<termRule>
Rule about terminological information.
@termInfoRef
Pointer to a resource containing information about the term.
@termInfoRefPointer
The location of a local pointer to a resource containing information about the term.

att.term
@termInfoRef
Pointer to a resource containing information about the term.
@term
Indicates a term locally.
"yes"
Only the value 'yes' is possible for the term attribute.

Directionality

Definition

This data category expresses the directionality of a piece of text. Its values are "ltr", "rtl", "lro" or "rlo". This definition is compliant with the dir attribute in XHTML™ 2.0, except that XHTML™ 2.0 does not allow for rule-based, global selection. An implementation of the directionality data category MUST follow the XHTML family user agent conformance critera defined in that specification.

Implementation

The @dir attribute is used for the implementation of the directionality data category. It has the four values "ltr", "rtl", "lro" or "rlo".

Directionality can be expressed with global rules or locally on an individual element.

As for global rules, directionality is expressed in rules using a <dirRule> element with the @dir attribute. In addition, a @selector attribute is required.

Directionality expressed with global rules

Locally in a document, directionality is expressed with a @dir attribute. The selection is the textual content of the element, including all child elements and attributes.

Directionality expressed in an instance document

Markup Declarations for Directionality

<dirRule>
Rule about directionality.
@dir
The text direction for the selection.
"ltr"
Left-to-right text.
"rtl"
Right-to-left text.
"lro"
Left-to-right override.
"rlo"
Right-to-left override.

att.dir
@dir
The text direction for the context.
"ltr"
Left-to-right text.
"rtl"
Right-to-left text.
"lro"
Left-to-right override.
"rlo"
Right-to-left override.

Ruby

Definition

The data category ruby 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

Ruby can be expressed locally in a document or with global rules.

Locally in a document, Ruby is realized with a <ruby> element.

Ruby locally in a document

The structure of the content model for the <ruby> element is identical with the structure of ruby markup as defined in Ruby Annotation. An implementation of the ruby data category MUST follow the conformance critera for ruby defined in that specification.

[The structure of ruby defined in section 5.4 of OASIS Open Document Format for Office Applications… is compliant with ruby defined in this specification.]

The functionality of pointing to existing ruby markup is realized with various pointer attributes for ruby. There is a pointer attribute for the <ruby> element and each element within its content model.

Handling Legacy Content

In legacy situations, where one cannot change the element markup and there one wants to apply ruby text to an attribute or existing element content, then the following approach can be used.

A <rubyRule> element can be used with two attributes:

- A @rubyText attribute contains the ruby text (corresponding to the <rt> element in the case of no selections)
- A @selector attribute contains the selector. It selects the ruby base text, corresponding to the <rb> element in the case of no selection.

Adding ruby text with a <rubyRule> element

Markup Declarations for Ruby

<rubyRule>
Rule about Ruby markup.
@rubyPointer
Relative XPath expression pointing to a node which corresponds to a <ruby> element
@rbPointer
Relative XPath expression pointing to a node which corresponds to a <rb> element
@rtPointer
Relative XPath expression pointing to a node which corresponds to a <rt> element
@rpPointer
Relative XPath expression pointing to a node which corresponds to a <rp> element
@rbcPointer
Relative XPath expression pointing to a node which corresponds to a <rbc> element
@rtcPointer
Relative XPath expression pointing to a node which corresponds to a <rtc> element
@rubyText
Ruby text.
@rbspanPointer
Relative XPath expression pointing to a node which corresponds to a @rbspan attribute.

<ruby>
Ruby markup.

@xmlns
The ITS namespace

http://www.w3.org/2005/11/its A valid XML namespace
@xmlns:its
The ITS namespace

http://www.w3.org/2005/11/its A valid XML namespace

<rb>
Ruby base text.

<rt>
Ruby text.

@rbspan
Allows an <rt> element to span multiple <rb> elements in complex ruby markup.

<rbc>
Container for <rb> elements in the case of complex ruby markup.

<rtc>
Container for <rt> elements in the case of complex ruby markup.

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

Language Information

Definition

The element <langRule> is used to express that a given piece of content (selected by the attribute @langPointer) is used to express language information as defined by Tags for the Identification of Languages.

Pointing to language information via <langRule>

The following <langRule> element expresses that all <p> elements (including attributes and textual content of child elements) have a language value conformant to Tags for the Identification of Languages. The value is given by the @mylangattribute attached to the <p> elements.

Markup Declarations for Language Information

<langRule>
Rule about language identification markup.
@langPointer
Relative XPath expression pointing to a node which contains language information.

Elements Within Text

Definition

The data category elements within text expresses information about how elements should affect the flow of the content. In this context the flow of the content represents how the nodes of the elements should be treated as a single unit for linguistic purposes. Sometimes, a flow can be nested within another one. The values associated with this data category are:

- "yes" (the element and its content are part of the flow of its parent element)
- "nested" (the element is part of the flow of its parent element, its content is an independent flow)
- "no" (the element splits the text flow of its parent element and its content is an independent text flow)

Elements not listed are considered to have the value "no".

Implementation

This data category can be expressed only in a set of rules. It cannot be expressed as local markup on an individual element.

Element within text is expressed with a <withinTextRule> element with a @withinText attribute. The attribute has the values "yes", "no" or "nested". In addition, a @selector attribute is required.

Elements within text

Markup Declarations for Elements within Text

<withinTextRule>
Rule about markup of "intext" elements.
@withinText
States whether current context is regarded as "within text".
"yes"
The element and its content are part of the flow of its parent element.
"no"
The element splits the text flow of its parent element and its content is an independent text flow.
"nested"
The element is part of the flow of its parent element, its content is an independent flow.

Schemas for ITS

This section is informative.

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

This section is informative.

Several constraints of ITS markup cannot be validated with ITS schemas. The following Schematron - A Language for Making Assertions about… document allows for validating some of these constraints.

Testing constraints in ITS markup

References

Karl Dubost, Lynne Rosental, Dominique Hazaël-Massieux, Lofton Henderson. QA Framework: Specification Guidelines . 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/.
James Clark, Makoto Murata. RELAX NG Specification . OASIS Committee Specification 3 December 2001. Available at http://www.oasis-open.org/committees/relax-ng/spec-20011203.html. The latest version of RELAX NG is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=relax-ng.
S. Bradner. Key Words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119. Available at http://www.ietf.org/rfc/rfc2119.txt.
Addison Phillips, Mark Davis. Tags for the Identification of Languages . IETF Internet-Draft, October 2005. See http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt.
Marcin Sawicki (until 10 October, 1999), Michel Suignard, Masayasu Ishikawa (石川 雅康), Martin Dürst, Tex Texin, Ruby Annotation . 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/.
Jonny Axelsson, Mark Birbeck, Micah Dubinko, Beth Epperson, Masayasu Ishikawa, Shane McCarron, Ann Navarro, Steven Pemperton. XHTML™ 2.0 . W3C Working Draft 27 May 2005. Available at http://www.w3.org/TR/2005/WD-xhtml2-20050527/. The latest version of XHTML 2.0 is available at http://www.w3.org/TR/xhtml2.
Steve DeRose, Eve Maler, David Orchard. XML Linking Language 1.0 . W3C Recommendation 27 June 2001. Available at http://www.w3.org/TR/2001/REC-xlink-20010627/. The latest version of XLink 1.0 is available at http://www.w3.org/TR/xlink/.
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, et al., editors. Extensible Markup Language (XML) 1.0 (Third Edition) , W3C Recommendation 04 February 2004. Available at http://www.w3.org/TR/2004/REC-xml-20040204/. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml/.
John Cowan, Richard Tobin. XML Information Set (Second Edition) . 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. Namespaces in XML . W3C Recommendation 14 January 1999. Available at http://www.w3.org/TR/1999/REC-xml-names-19990114/. 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. XML Schema Part 1: Structures Second Edition . 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. XML Path Language (XPath) Version 1.0 . 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.

References

Cascading Style Sheets, level 2 . W3C Recommendation 12 May 1998. Available at http://www.w3.org/TR/1998/REC-CSS2-19980512. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2/.
Michael Priestley, JoAnn Hackos, et. al., editors. OASIS Darwin Information Typing Architecture (DITA) Language Specification v1.0. OASIS Standard 9 May 2005. Available at http://www.oasis-open.org/committees/download.php/15316/dita10.zip.
Norman Walsh and Leonard Muellner. DocBook: The Definitive Guide . Available at http://www.docbook.org/.
Richard Ishida, Susan Miller. Localization vs. Internationalization. Article of the W3C Internationalization Activity, January 2006.
Yves Savourel. Internationalization and Localization Markup Requirements . W3C Working Draft 18 May 2006. Available at http://www.w3.org/TR/2005/WD-itsreq-20060518/. The latest version of ITS REQ is available at http://www.w3.org/TR/itsreq/.
Michael Brauer et al. OASIS Open Document Format for Office Applications (OpenDocument). . Oasis Standard 1 May 2005. Available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office. The latest version of OpenDocument is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office.
Schematron - A Language for Making Assertions about Patterns Found in XML Documents . Available at http://www.schematron.com/.
Norman Walsh. Using Qualified Names (QNames) as Identifiers in XML Content . TAG Finding 17 March 2004. Available at http://www.w3.org/2001/tag/doc/qnameids.html.
Lou Burnard and Syd Bauman (eds). Text Encoding Initiative Guidelines development version (P5) . TEI Consortium, Charlottesville, Virginia, USA, Text Encoding Initiative.
Steven Pemperton et al. XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) . 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, Diane Stoick. Best Practices for XML Internationalization. Available at http://www.w3.org/TR/2006/WD-xml-i18n-bp-20060518/. The latest version of xml-i18n-bp is available at http://www.w3.org/TR/xml-i18n-bp/.
The XML Spec Schema and Stylesheets . Available at http://www.w3.org/2002/xmlspec/.
James Clark. XSL Transformations (XSLT) Version 1.0 . 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.
exTensible User Inferface Language . Available at http://www.xulplanet.com/.

Revision Log

The following log records major changes that have been made to this document since the publication in November 2005.

- A section about basic concepts of ITS has been created.
- Terminology has been modified: the terms for position of ITS information in situ versus dislocated have been replaced by selection in an instance document versus global, rule-based selection.
- The definition of the directionality data category has been changed, to be compliant to various other specifications. See the comment on bidirectionality for further information.
- Terminology within the text of this document and within the markup declarations has been modified: scope of ITS information has been replaced with selection of ITS information.
- The schemaRules element has been removed. For ITS information as schema annotation, where is now only a <schemaRule> element.
- All ITS attributes are now defined as qualified attributes. This leads to changes in the generated ITS schemas, for example the generation of parameter entities for prefixes in the XML DTD. This allows for easy changing of prefixes in element or attribute names.
- The possibility of selector attributes in instance documents (in the previous draft this was called scope in an instance document) has been removed. Local selection in an instance document now relies only on default selections of data categories. Due to this change, the definition of precedence between selections and conformance criteria have been simplified, and the issue on namespace requirements and selector values could be resolved.
- Definitions of default selections of data categories have been modified.
- An <ns> element has been added to the <rules> element to allow for specifying namespace bindings.
- The implementation of the ruby data category has been modified, to reflect the removal of selector attributes in instance documents.
- A section on mapping of ITS data categories to existing markup has been created.
- Examples of integrating ITS markup into a TEI schema and into XML Spec have been created.
- A <span> element has been created.
- The examples have been modified to reflect changes mentioned above.
- For clarity, various sections have been reworded and re-structured, and the visualization of ITS markup within the text of this document has been modified.
- Tracking of issues is now handled via Bugzilla.
- A revision log has been added.

The following log records major changes that have been made to this document since the publication in February 2006.

- The <schemaRule> element, and the notion of schema annotation which was connected to it, have been abandoned.
- The section on conformance has been rewritten and placed at the beginning of the document.
- In global rules, the <documentRule> element has been replaced with elements which have data category specific names. This eases the creation and validation of global rules.
- In global rules, instead of rule specific attributes for selection, there is now just one @selector attribute.
- In global rules, the <documentRules> element has been renamed to <rules>.
- In global rules, in addition to the existing functionality of adding ITS information to selected nodes, a new functionality of pointing to information in an XML document has been created.
- An XLink @href attribute has been added to the <rules> element to allow for links to external rules. The precedence between selections has been modified to reflect this change.
- Two new data categories language information and elements within text have been defined.
- The data category ruby has been redefined, to be conforming to Ruby Annotation.
- The declarations for ITS markup have been rewritten, to adopt the changes mentioned above.
- The declarations for ITS markup (formally all assembled in a single section) have been separated and placed in the sections there they are described.
- A modularization of ITS and XHTML 1.0 has been created.
- The informative Introduction and Basic Concepts have been rewritten.
- Examples and the modularizations of ITS with existing markup schemes have been changed to reflect the modifications mentioned above.

The following log records major changes that have been made to this document since the publication in April 2006.

- The conformance section has been rewritten.
- The terminology of mapping ITS data categories with existing markup has been changed to associating ITS Data Categories with existing markup.
- The global rule elements have been rewritten to have attributes in the empty namespace.
- The examples have been validated, partially modified and extended.
- Documentation strings have been added to elements and attributes.
- The data category elements within text has been redefined.
- Clarifications about ITS and inclusion mechanisms and selections of pointers to external (possibly non-textual) objects have been made.
- The local attributes have been reorganised into various data category specific groups.
- A versioning mechanism has been introduced
- A summary of ITS markup has been created.
- The automatically generated ITS schemas have been augmented with element and attribute documentations.
- A description of ITS markup constraints not covered by the ITS schemas has been created.
- The attributes termRef and termRefPointer have been renamed to @termInfoRef and @termInfoRefPointer.
- A list of requirements which are formulated in Internationalization and Localization Markup Requirements, but not covered in this document, has been created. See Introduction.

Acknowledgements

This document has been developed with contributions by the ITS Working Group. At the date of publication, the members of the Working Group were: Damien Donlon (Sun Microsystems), Martin Dürst (Invited Expert), Richard Ishida (W3C), Masaki Itagaki (Invited Expert), Christian Lieske (SAP AG), Naoyuki Nomura (Ricoh), Sebastian Rahtz (Invited Expert), François Richard (HP), Goutam Saha (CDAC), Felix Sasaki (W3C), Yves Savourel (ENLASO), Dianne Stoick (Boeing), Najib Tounsi (Ecole Mohammadia d'Ingénieurs Rabat (EMI)) and Andrzej Zydroń (Invited Expert).

A special thanks goes to Sebastian Rahtz who introduced us to the ODD language, which was used to create this document, and who provided the stylesheets to generate schemas and the XHTML version out of an ODD document. The generation of XHTML from ODD takes an intermediate step through the xmlspec-i18n.dtd.

$Id: itstagset.odd,v 1.124 2006/04/20 14:24:12 fsasaki Exp $