1 Introduction
This section is informative.
ITS is a technology to easily create XML which is internationalized and can be localized effectively. On the one hand, the ITS specification identifies concepts (such as "directionality") which are important for
internationalization and localization. On the other hand, the ITS specification 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 three schema languages: XML DTD [XML 1.0], XML Schema [XML Schema] and RELAX NG [RELAX NG].
This document aims to realize many of the ideas formulated in [Localizable DTDs].
Requirements for this document are formulated in [ITS REQ]. Not all requirements listed there
are addressed in this document. Those which are not addressed here
are either covered in [XML i18n BP] 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 Section 6.7: Language Information
R007 -
identifying Terms, see Section 6.4: Terminology
R008 -
purpose specification/mapping, see Section 5.5: Associating ITS Data Categories with Existing Markup
R011 -
bidirectional text support, see Section 6.5: Directionality
R012 -
indicator of translatability, see Section 6.2: Translate
R014 -
limited impact, see Section 5.5: Associating ITS Data Categories with Existing Markup
R017 -
localization notes, see Section 6.3: Localization Note
R020 -
annotation markup, see Section 6.6: Ruby
R025 -
elements and segmentation, see Section 6.8: Elements Within Text
The following requirements will be addressed in [XML i18n BP]:
The Working Group decided not to cover the following
requirements
at this time to be able to focus on the most important ones.
1.1 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
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 [l10n i18n].
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 [XUL]) creates challenges and
opportunities in the domain of XML internationalization and
localization.
1.1.1 Typical Problems
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.
In this document it is difficult to make distinction between the string elements that are translatable and the ones that are not. Only the addition of flags could resolve the issue.
<resources>
<section id="Homepage">
<arguments>
<string>page</string>
<string>childlist</string>
</arguments>
<variables>
<string>POLICY</string>
<string>Corporate Policy</string>
</variables>
<keyvalue_pairs>
<string>Page</string>
<string>ABC Corporation - Policy Repository</string>
<string>Footer_Last</string>
<string>Pages</string>
<string>bgColor</string>
<string>NavajoWhite</string>
<string>title</string>
<string>List of Available Policies</string>
</keyvalue_pairs>
</section>
</resources>
[Source file: EX-motivation-its-1.xml]
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.
<dialogue xml:lang="en-gb">
<rsrc id="123">
<component id="456" type="image">
<data type="text">images/cancel.gif</data>
<data type="coordinates">12,20,50,14</data>
</component>
<component id="789" type="caption">
<data type="text">Cancel</data>
<data type="coordinates">12,34,50,14</data>
</component>
<component id="792" type="string">
<data type="text">Number of files: </data>
</component>
</rsrc>
</dialogue>
[Source file: EX-motivation-its-2.xml]
1.2 Users and Usages of ITS
1.2.1 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
(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 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.
Note:
The question
"How to use ITS with existing popular markup schemes?"
is covered in more details (including examples) in a separate document: [XML i18n BP].
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 Section 5.5: Associating ITS Data Categories with Existing Markup). 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 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 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.
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:
1.2.2 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.
The its:translate="no" attributes indicate that the fexp elements should not be translated.
<book
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EX-ways-to-use-its-5.xsd"
its:version="1.0">
<head>
<title>The Life of a Simple Man</title>
</head>
<body>
<p>Everything started when Zebulon discovered that he had
a <fexp
its:translate="no">doppelgänger</fexp> who was a
serious baseball <fexp
its:translate="no">aficionado</fexp>.</p>
</body>
</book>
[Source file: EX-ways-to-use-its-1.xml]
The translateRule element is used in the header of the document to indicate that none of the fexp elements should be translated.
<book
xmlns:its="http://www.w3.org/2005/11/its" >
<head>
<its:rules version="1.0">
<its:translateRule selector="//fexp" translate="no"/>
</its:rules>
<title>The Life of a Simple Man</title>
</head>
<body>
<p>Everything started when Zebulon discovered that he had
a <fexp>doppelgänger</fexp> who was a serious
baseball <fexp>aficionado</fexp>.</p>
</body>
</book>
[Source file: EX-ways-to-use-its-2.xml]
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.
<book
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xlink="http://www.w3.org/1999/xlink" >
<head>
<its:rules version="1.0" xlink:href="EX-ways-to-use-its-4.xml" xlink:type="simple"/>
<title>The Life of a Simple Man</title>
</head>
<body>
<p>Everything started when Zebulon discovered that he had
a <fexp>doppelgänger</fexp> who was a serious
baseball <fexp>aficionado</fexp>.</p>
</body>
</book>
[Source file: EX-ways-to-use-its-3.xml]
The rules element contains several ITS rules that are common to different documents. One of them is a translateRule element that indicates that no fexp element should be translated.
<its:rules
xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
<its:translateRule selector="//fexp" translate="no"/>
<its:withinTextRule selector="//fexp|//strong" withinText="yes"/>
<its:termRule selector="//term|//fexp" term="yes"/>
</its:rules>
[Source file: EX-ways-to-use-its-4.xml]
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 Example 3.
<xs:schema
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/2005/11/its" schemaLocation="its.xsd"/>
<xs:attributeGroup name="commonAtts">
<xs:attributeGroup ref="its:att.local.with-ns.attribute.translate"/>
<xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:attributeGroup>
<xs:element name="book">
<xs:complexType>
<xs:sequence>
<xs:element name="head">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
</xs:sequence>
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
<xs:element name="body">
<xs:complexType>
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="p">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="fexp"/>
</xs:choice>
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attributeGroup ref="its:att.version.attribute.version"/>
</xs:complexType>
</xs:element>
<xs:element name="fexp">
<xs:complexType mixed="true">
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
</xs:schema>
[Source file: EX-ways-to-use-its-5.xsd]
The first two approaches above can be likened to the
use of CSS in [XHTML 1.0]. 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.
1.3 Out of Scope
This standard does not cover all mechanisms and data formats (sometimes called Localization Properties), which might be needed for configuring localization workflows or tools to process a specific format. However, these mechanisms and data formats may be implemented using the framework described in this standard.
Note:
"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.
1.4 Important Design Principles
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 using for example an
element or attribute. See Section 3.3: Data category for a definition of the term data
categories, Section 6: Description of Data Categories for the definition of the various ITS data
categories, and subsections in Section 6: 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 Infoset]. ITS applications may implement inclusion mechanisms
such as XInclude or DITA's [DITA 1.0] conref.
Content authors need, for example, 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 coordinators, on the other hand, need an
efficient way of managing translations of large document
sets based on the same schema. This could by realized by a
specification of defaults for the Translate data category and exceptions
from the 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 Section 5: 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 selection mechanisms allows you to provide information about content locally (specified at the XML node 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 [XML Names]) may be used.
Ease of integration:
ITS follows the example from section
4 of [XLink 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 [ITS REQ]. Only
for some requirements do additional child elements have to be
used, see for example Section 6.6: 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 1.0] for the selection mechanism)
1.5 Development of this Specification
This specification has been developed using the ODD (One Document Does it
all) language of the Text Encoding Initiative ([TEI]). 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.
2 Basic Concepts
This section is informative.
2.1 Selection
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 [CSS 2.1]. 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. 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.
2.1.1 Local Approach
The document in Example 8 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.
<dbk:article
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:dbk="http://docbook.org/ns/docbook"
its:version="1.0" version="5.0" xml:lang="en">
<dbk:info>
<dbk:title>An example article</dbk:title>
<dbk:author
its:translate="no">
<dbk:personname>
<dbk:firstname>John</dbk:firstname>
<dbk:surname>Doe</dbk:surname>
</dbk:personname>
<dbk:affiliation>
<dbk:address>
<dbk:email>foo@example.com</dbk:email>
</dbk:address>
</dbk:affiliation>
</dbk:author>
</dbk:info>
<dbk:para>This is a short article.</dbk:para>
</dbk:article>
[Source file: EX-basic-concepts-1.xml]
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.
2.1.2 Global Approach
The document in Example 9 shows a different approach to identifying
non-translatable content, similar to that used with a
style element in [XHTML 1.0], 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, like 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 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 taken from namespace
declarations [XML Names] at the current rules element.
Note:
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:
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//*/@*
<myTopic
xmlns:its="http://www.w3.org/2005/11/its"
xmlns="myNamescapeURI" id="topic01" xml:lang="en-us">
<prolog>
<title>Using ITS</title>
<its:rules version="1.0">
<its:translateRule selector="//n:term" translate="no"/>
</its:rules>
</prolog>
<body>
<p>ITS defines <term>data category</term> as an abstract
concept for a particular type of information for
internationalization and localization of XML schemas and
documents.</p>
</body>
</myTopic>
[Source file: EX-basic-concepts-2.xml]
For this approach 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
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 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:
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 theterm element in DITA)
2.2 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 Example 10 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.
<text
xmlns:its="http://www.w3.org/2005/11/its" >
<head>
<revision>Sep-10-2006 v5</revision>
<author>Ealasaidh McIan</author>
<contact>ealasaidh@hogw.ac.uk</contact>
<title
its:translate="yes">The Origins of Modern Novel</title>
<its:rules version="1.0">
<its:translateRule translate="no" selector="/text/head"/>
</its:rules>
</head>
<body>
<div xml:id="intro">
<head>Introduction</head>
<p>It would certainly be quite a <span
its:translate="no">faux pas</span>
to start a dissertation on the origin of modern novel without
mentioning the <tl>Epic of Gilgamesh</tl>...</p>
</div>
</body>
</text>
[Source file: EX-basic-concepts-3.xml]
2.3 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 at 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 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.
3 Notation and Terminology
This section is normative.
3.1 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 [RFC 2119].
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"
3.2 Schema Language
[Definition:
Schema language refers in this
specification to an XML-related modelling or validation
language such as XML DTD, XML Schema or RELAX
NG.]
Note:
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.
3.3 Data category
[Definition: 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 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.
3.4 Selection
[Definition:
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 Section 5: Processing of ITS information. Selection can be
applied globally, see Section 5.2.1: Global, Rule-based Selection, and locally, see Section 5.2.2: 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 that is
given in the XML Information Set [XML Infoset]. ITS applications MAY implement inclusion mechanisms
such as XInclude or DITA's [DITA 1.0] conref.
Note:
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.
<text
xmlns:its="http://www.w3.org/2005/11/its" >
<its:rules version="1.0">
<its:translateRule translate="yes" selector="//p/img/@src"/>
</its:rules> ...
<p>As you can see in
<img src="instructions.jpg"/>,
the truth is not always out there.</p>
</text>
[Source file: EX-notation-terminology-1.xml]
3.5 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, [RFC 3987] or its successor) to ease the adoption of ITS
in international application scenarios.
Note:
The ITS schemas in Appendix D: Schemas for ITS 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 [XML Infoset], where no difference between IRIs and URIs exists.
4 Conformance
This section is normative.
The usage of the term conformance clause in
this section is in compliance with [QAFRAMEWORK].
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.
4.1 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 Section 4.2: Conformance Type 2: The Processing Expectations for ITS Markup.
Definitions related to this conformance
type: ITS markup declarations are defined in various
subsections in Section 5: Processing of ITS information and
Section 6: Description of Data Categories
(e.g. Section 6.3.3: Markup Declarations for Localization Note) 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:
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.0]).
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 [XML i18n BP].
Note:
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 Appendix D: Schemas for ITS are only
informative examples.
4.2 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 Section 4.1: 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 Section 5: Processing of ITS information. The individual data
categories defined in Section 6: Description of Data Categories 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 for internationalization or
localization the nodes captured by a data category. 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.
Note:
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.
Note:
The ITS Working group provides a
test suite
to help implementors 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-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.
5 Processing of ITS information
This section is normative.
5.1 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 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.
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.
5.2 Locations of Data Categories
ITS data categories can appear in two places:
The two locations are described in detail below.
5.2.1 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 you 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 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.
Another difference between adding and
pointing is the usage of XPath:
The value of the selector attribute MUST be an XPath expression
which starts with "/". That is, it must
be an
AbsoluteLocationPath as described in XPath 1.0 or its successor. This ensures that
the selection is not relative to a specific
location. The resulting nodes MUST be either element or
attribute nodes.
Attributes that point to existing information in the document, i.e. attributes whose name ends in ...Pointer, MUST use a RelativeLocationPath as described in XPath 1.0 or its successor. 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, rbcPointer, rtcPointer, rbspanPointer, langPointer.
If namespaces [XML Names] 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 xmlns attribute at the same rule element which allows to resolve the namespace URI of the prefix.
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.
The term element from the TEI is in a
namespace http://www.tei-c.org/ns/1.0.
<its:rules
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:tei="http://www.tei-c.org/ns/1.0" version="1.0">
<its:termRule selector="//tei:term" term="yes"/>
</its:rules>
[Source file: EX-selection-global-1.xml]
The qterm element from DocBook is in no
namespace.
<its:rules
xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
<its:termRule selector="//qterm" term="yes"/>
</its:rules>
[Source file: EX-selection-global-2.xml]
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 Section 5.4: Precedence between Selections.
Markup for global, rule-based selection is defined as
follows.
- rules
- att.selector
- att.version
5.2.2 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 rb and rt elements themselves can contain span. An application of ruby MUST not use such arbitrary nesting.
The data category determines what is being selected.
The necessary data category specific defaults
are described in Section 6.1: Position, Defaults, Inheritance and Overriding of 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.
<text
xmlns:its="http://www.w3.org/2005/11/its"
its:version="1.0" xml:lang="en">
<head
its:translate="no">
<author>Sven Corneliusson</author>
<date>2006-09-26T17:34:04Z</date>
<title
its:translate="yes" role="header">Bidirectional Text</title>
</head>
<body>
<par>In Arabic, the title <quote xml:lang="ar"
its:dir="rtl">نشاط التدويل، W3C</quote>
means <quote>Internationalization Activity, W3C</quote>.</par>
</body>
</text>
[Source file: EX-selection-local-1.xml]
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, rb, rt, rbc, rtc and rp. The attribute group att.local.with-ns.attributes contains namespace qualified ITS attributes and is used with elements from different namespaces.
- att.local.no-ns
- att.local.with-ns
- span
5.3 Link to External Rules
One way to associate a document with a set of external
ITS rules is to use the optional XLink [XLink 1.0]
href attribute in the
rules element, accompanied by the XLink type attribute whith the value "simple". 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.
The example demonstrates how metadata can be added to
ITS rules.
<myFormatInfo
xmlns:its="http://www.w3.org/2005/11/its" >
<desc>ITS rules used by the Open University</desc>
<hostVoc>http://www.tei-c.org/ns/1.0</hostVoc>
<rulesId>98ECED99DF63D511B1250008C784EFB1</rulesId>
<rulesVersion>v 1.81 2006/03/28 07:43:21</rulesVersion> ...
<its:rules version="1.0">
<its:translateRule selector="//header" translate="no"/>
<its:translateRule selector="//term" translate="no"/>
<its:termRule selector="//term" term="yes"/>
<its:withinTextRule withinText="yes" selector="//term | //b"/>
</its:rules>
</myFormatInfo>
[Source file: EX-link-external-rules-1.xml]
<myDoc
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xlink="http://www.w3.org/1999/xlink" >
<header>
<its:rules version="1.0" xlink:href="EX-link-external-rules-1.xml" xlink:type="simple">
<its:translateRule selector="//term" translate="yes"/>
</its:rules>
<author>Theo Brumble</author>
<lastUpdate>Apr-01-2006</lastUpdate>
</header>
<body>
<p>A <term>Palouse horse</term> has a spotted coat.</p>
</body>
</myDoc>
[Source file: EX-link-external-rules-2.xml]
The result of processing the two documents above is the
same as processing the following document.
<myDoc
xmlns:its="http://www.w3.org/2005/11/its" >
<header>
<its:rules version="1.0">
<its:translateRule selector="//header" translate="no"/>
<its:translateRule selector="//term" translate="no"/>
<its:termRule selector="//term" term="yes"/>
<its:withinTextRule withinText="yes" selector="//term | //b"/>
<its:translateRule selector="//term" translate="yes"/>
</its:rules>
<author>Theo Brumble</author>
<lastUpdate>Apr-01-2006</lastUpdate>
</header>
<body>
<p>A <term>Palouse horse</term> has a spotted coat.</p>
</body>
</myDoc>
[Source file: EX-link-external-rules-3.xml]
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.
5.4 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 rules inside the rules element
Any rules linked via the XLink href attribute
Note:
If identical selections are defined in different rules elements
within one document, the selection defined by the last takes
precedence.
Note:
ITS doesn't 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 Section 6.1: Position, Defaults, Inheritance and Overriding of Data Categories
In case of conflicts between global selections via
multiple rule
elements, the last selector has higher precedence.
Note:
The precedence order fulfills the same purpose as the
built-in template rules of [XSLT 1.0].
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.
<text
xmlns:its="http://www.w3.org/2005/11/its" >
<prolog>
<its:rules version="1.0">
<its:withinTextRule withinText="yes" selector="//title|//author"/>
<its:withinTextRule withinText="no" selector="//prolog/title|//prolog/author"/>
</its:rules>
<title>Designing User Interfaces</title>
<author>Janice Prakash</author>
<keywords>user interface, ui, software interface</keywords>
</prolog>
<body>
<p>The book <title>Of Mice and Screens</title> by <author>Aldus
Brandywine</author> is one of the best introductions to the vast
topic of designing user interfaces.</p>
</body>
</text>
[Source file: EX-selection-precedence-1.xml]
5.5 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 Section 5.2.1: Global, Rule-based Selection.
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.
<topic
xmlns:its="http://www.w3.org/2005/11/its" id="myTopic">
<title>The ITS Topic</title>
<prolog>
<its:rules version="1.0">
<its:translateRule selector="//*[@translate='no']" translate="no"/>
<its:translateRule selector="//*[@translate='yes']" translate="yes"/>
<its:termRule selector="//term | //dt" term="yes"/>
</its:rules>
</prolog>
<body>
<dl>
<dlentry id="tDataCat">
<dt>Data category</dt>
<dd>ITS defines <term>data category</term> as an abstract concept for
a particular type of information related to internationalization and
localization of XML schemas and documents.</dd>
</dlentry>
</dl>
<p>For the implementation of ITS, apply the rules in the order:</p>
<ul>
<li>Defaults</li>
<li>Rules in external files</li>
<li>Rules in the document</li>
<li>Local attributes</li>
</ul>
<p>
<ph translate="no" xml:lang="fr">Et voilà !</ph>.</p>
</body>
</topic>
[Source file: EX-associating-its-with-existing-markup-1.xml]
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 Example 20
with a link to an external rules file using the XLink href attribute, as shown in Example 16
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.