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.
Example 1: Document with partially translatable contentIn 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]
Example 2: Document with partially translatable contentEven 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 standardizing the format and
processing expectations of certain relevant markup
items, and allowing them to more effectively identify
how content should be handled.
-
Content producers
This type of user comprises
authors, translators and other types of content
author. The markup proposed in this specification may
be used by them to mark up specific bits of
content. Aside: The burden of inserting markup can be
removed from content producers by relating the ITS
information to relevant bits of content in a global
manner (see global,
rule-based approach). This global work, however,
may fall to information architects, rather than the
content producers themselves.
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.
Example 3: Use of ITS by content authorThe its:translate="no" attributes indicate that the path and the cmd elements should not be translated.
<help
xmlns:its="http://www.w3.org/2005/11/its"
its:version="1.0">
<head>
<title>Building the Zebulon Toolkit</title>
</head>
<body>
<p>To re-compile all the modules of the Zebulon toolkit you need to go in the
<path
its:translate="no">\Zebulon\Current Source\binary</path> directory.
Then from there, run batch file <cmd
its:translate="no">Build.bat</cmd>.</p>
</body>
</help>
[Source file: EX-ways-to-use-its-1.xml]
Example 4: Use of ITS by information architectThe translateRule element is used in the header of the document to indicate that none of the path or cmd elements should be translated.
<help
xmlns:its="http://www.w3.org/2005/11/its"
its:version="1.0">
<head>
<title>Building the Zebulon Toolkit</title>
<its:rules version="1.0">
<its:translateRule selector="//path | //cmd" translate="no"/>
</its:rules>
</head>
<body>
<p>To re-compile all the modules of the Zebulon toolkit you need to go in the
<path>\Zebulon\Current Source\binary</path> directory.
Then from there, run batch file <cmd>Build.bat</cmd>.</p>
</body>
</help>
[Source file: EX-ways-to-use-its-2.xml]
Example 5: Use of ITS by processorA 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.
<help
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xlink="http://www.w3.org/1999/xlink"
its:version="1.0">
<head>
<title>Building the Zebulon Toolkit</title>
<its:rules version="1.0" xlink:href="EX-ways-to-use-its-4.xml" xlink:type="simple"/>
</head>
<body>
<p>To re-compile all the modules of the Zebulon toolkit you need to go in the
<path>\Zebulon\Current Source\binary</path> directory.
Then from there, run batch file <cmd>Build.bat</cmd>.</p>
</body>
</help>
[Source file: EX-ways-to-use-its-3.xml]
Example 7: An XSD schema with ITS declarationThe 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="help">
<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="path"/>
<xs:element ref="cmd"/>
</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="path">
<xs:complexType mixed="true">
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
<xs:element name="cmd">
<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.
Example 8: ITS markup on elements in an XML document (local approach)
<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//*/@*
Example 9: ITS global markup in an XML document (rule-based approach)
<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 the term 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.
Example 10: Overriding and Inheritance
<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 modeling 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:
Example 11: A data category and its implementationThe 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.
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 implementers to write applications that
support the ITS specifications. The test suite
provides pairs of input and output files.
Conformance clauses:
-
2-1: A processor
MUST implement at least one data category.
For each implemented data category, the following
MUST be taken into account:
-
2-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.