1 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 [XML 1.0], XML
Schema [XML Schema] and RELAX NG [RELAX NG]. 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 [ITS REQ]. Not all of these requirements are
addressed in this document, for example:
The Working Group will cover some of the requirements in a separate
document on techniques for internationalization and localization
of schemas and XML documents.
1.1 Users and Usages of ITS
1.1.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 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.
Note:
The
Working Group intends to cover the question “How use ITS with existing
popular markup schemes?” in more detail in a separate document/note
on “Modularizations for ITS”.
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 relating ITS markup with markup
in the host vocabulary which serves a similar purpose (see Section 5.4: Mapping of ITS Data Categories to 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.
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.1.2 Ways to Use ITS
The ITS specification proposes several mechanisms for supporting
worldwide use and effective localization of content. We will sketch
them below by looking at 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.
<book>
<head>...</head> <body> ... <p>And he said: you need a
new <quote its:translate="no">T-Model</quote></p> ...
</body>
</book>
<text>
<head>
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<its:translateRule its:translate="no" its:selector="//dt"/>
<its:rules>
</head>
<body> ...
<p> ... <dl><dt>...</dt><dd>...</dd></dl></p>
</body>
</text>
<text>
<head>
<its:rules xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="myRules.xml">
</its:rules>
</head>
<body> ...
<p> ... <dl><dt>...</dt><dd>...</dd></dl></p>
</body>
</text>
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.
1.2 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 [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.
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 (the text in bold face shows the parts that need
to be translated). Tools often cannot automatically do this identification.
PhaseCode should not be translated;
the title attribute sometimes has to be translated and
sometimes must not be translated.
<Manual>
<Info>
<PhaseCode>Review Level</PhaseCode>
<FormNo>8U81-GS-52C</FormNo>
<Name>Owner's Manual</Name>
...
</Info>
<Section id="0" title="#Introduction#">
<Ltitle id="005" title="#ZOOM#">
<Mtitle id="00501" title="Getting started" option="no" cols="1">
<MultiCol cols="1">
<Text>Some text to localize</Text>
...
</Multicol>
</Mtitle>
</Ltitle>...
</Manual>The first file name in the first component element would
not be translated.
<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>
</rsrc>
</dialogue>
In the example below, there are no clear mechanisms allowing one
to know which string element needs to be translated.
<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>
1.3 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 (see in particular Section 5:
Processing of ITS information) documents.
Note:
“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.
1.4 Important Design Principles
[Ed. note: Attention: The design
of the ITS schema in Section 5:
Processing of ITS information and Section 6: Description of Data Categories is still under development.
Thus, the ITS schema structure may change. However, the Working Group
does 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 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.
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 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 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 [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 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 [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 is 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 transform 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.
2 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 [CSS2]. 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 XSD 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.
<article xmlns="http://docbook.org/ns/docbook"
xmlns:its="http://www.w3.org/2005/11/its"
its:translate="yes">
<info>
<title>An example article</title>
<author its:translate="no">
<personname>
<firstname>John</firstname>
<surname>Doe</surname>
</personname>
<affiliation>
<address><email>foo@example.com</email></address>
</affiliation>
</author>
</info>
</article>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.
<topic id="myTopic" xml:lang="en-us">
<title>Using ITS</title>
<prolog>
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<its:translateRule its:selector="//term" its:translate="no" />
</its:rules>
</prolog>
<body>
<p>An <term>ITS namespace</term> definition exists...</p>
</body>
</topic>
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 translate 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 its:translate='no'. This piece of ITS markup can be interpreted as follows:
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 map to existing
markup (for example the term element
in DITA)
The power of ITS selector attributes comes at a price:
rules related to overriding/precedence, and inheritance,
have to be established.
<text>
<head>
<its:rules>
<its:translateRule its:translate="yes" its:selector="//p"/>
<its:rules>
</head>
<body>
<p its:translate="no"> ... <dl><dt>...</dt><dd>...</dd></dl></p>
</body>
</text>
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 translate 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 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
localization information can be used for adding information to selected
nodes, or for pointing to 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: 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"
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 which 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 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.
4 Conformance
This section is normative.
[Ed. note: 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 [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 are defined complementary. An implementation of this specification may use them together.
4.1 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 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 6: Description of Data Categories
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: ITS markup declarations are to be integrated 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 facultative.
Conformance clauses:
1-1: The
rules
element must be part of the content model of at least one element declared in the schema. It should be in a document model for meta information, if this is available in that schema (e.g. the head element in XHTML).
1-2:
All
local ITS attributes
should be declared at all elements which are part of the schema.
1-3:
The ruby element must be declared as an inline element (the definition of inline depends on the schema.)
1-4:
The span element may be declared as an inline element (the definition of inline depends on the schema.).
Examples: Examples of the usage of ITS markup declarations in various existing schemas are given in Section 7: Modularizations of ITS with Existing Markup Schemes.
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 which uses parameter entities). The ITS schemas in the format of XML DTD, XML Schema and RELAX NG in Appendix A: 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.
4.2 Conformance Type 2: The Processing Expectations for ITS Markup
Description:
The
processing expectations for ITS markup define how ITS markup found in XML documents has to be interpreted by an application. The markup may be generated or validated relying on a schema which is conform to the conformance 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 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: Processing expectations for ITS markup are used by any application which needs to process for internationalization or localization the element or attribute nodes captured by a data category.
Conformance clauses:
Examples: Examples of applications which are 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.
Note:
Applications which are conform to the clauses above can be, for example: ITS markup aware editors, or translation tools which make use of ITS markup to filter translatable text as an input to the localization process. Their only common property is that they are able to process ITS markup in the way described above. Further processing is not subject to this specification.
5
Processing of ITS information
This section is normative.
5.1 Locations of Data Categories
ITS data categories can appear in two places:
The two
locations are described in detail below.
5.1.1 Global, Rule-based Selection
Global, rule-based selection is implemented using the
rules
element. It
contains one or more
rule elements. Each
rule element has a mandatory selector attribute.
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, an 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.
[Ed. note: The working group is looking for feedback on a proposal to group rule elements.]
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].
This ensures that the selection is not relative to a specific location.
As for data category specific attributes like locInfoPointer which point to existing information in the document, a RelativeLocationPath as described in [XPath 1.0]
must be used. The XPath expression is evaluated relative to the nodes which are selected via the selector attribute.
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 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.
The term element from the TEI is in a namespace
http://www.tei-c.org/ns/1.0. The qterm element from DocBook
is in no namespace.
<!-- Definitions for TEI -->
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<its:ns its:prefix="tei" its:uri="http://www.tei-c.org/ns/1.0"/>
<termRule its:selector="//tei:term"/>
</its:rules>
<!-- Definitions for DocBook -->
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<termRule its:selector="//qterm"/>
</its:rules>
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.3: Precedence between Selections.
Markup for global, rule-based selection is defined as follows.
- rules
- att.xlink
| [4] | att.xlink.attributes | ::= |
att.xlink.attribute.href, empty |
| [5] | att.xlink.attribute.href | ::= | attribute href { xsd:anyURI }? |
- ns
- att.nsident
- att.selector
5.1.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 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 Section 6.1: Position and Default Selections of 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".
<text>
<head its:translate="no"> ... </head>
<body its:translate="yes" its:dir="ltr"> ... </body>
</text>
Markup for local selection is defined as follows.
- span
5.2 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.
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.
<myFormatInfo>
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<its:translateRule its:selector="//header" its:translate="no"/>
<its:translateRule its:selector="//term" its:translate="no"/>
<its:termRule its:selector="//term"/>
<its:withinText its:selector="//term | //b"/>
</its:rules>
...
</myFormatInfo>
<myDoc>
<header>
<its:rules xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="myRules.xml">
<its:translateRule its: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>
The result of processing the two documents above is the same as processing the following document.
<myDoc>
<header>
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<its:translateRule its:selector="//header" its:translate="no"/>
<its:translateRule its:selector="//term" its:translate="no"/>
<its:termRule its:selector="//term"/>
<its:withinText its:selector="//term | //b"/>
<its:translateRule its: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>
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.
5.3 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 Section 6.1: Position and Default Selections 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].
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).
<text>
<head>
<its:rules>
<its:translateRule its:translate="yes" its:selector="//p"/>
<its:translateRule its:translate="no" its:selector="//index/entry/p"/>
<its:rules>
</head>
<body> ...
<p its:translate="no"> ... </p>
</body>
<back><index>
<entry><p> ... </p></entry>
</index></back>
</text>
5.4 Mapping of ITS Data Categories to Existing Markup
Some markup schemes provide markup which can be used to express ITS data categories. ITS
data categories can be mapped to such existing markup, using the global selection mechanism
described in Section 5.1.1: Global, Rule-based Selection. In this way, there is
no need to integrate ITS markup into documents.
<topic id="myTopic">
<title>The ITS Topic</title>
<prolog>
<its:rules xmlns:its="http://www.w3.org/2005/11/its">
<its:translateRule its:selector="//*[@translate='no']" its:translate="no"/>
<its:translateRule its:selector="//*[@translate='yes']" its:translate="yes"/>
<its:termRule its:selector="//term | //dt"/>
</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 for 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>Default</li>
<li>Rules in the schema</li>
<li>Rules in the document instance</li>
<li>Local attributes</li>
</ul>
<p><ph translate="no" xml:lang="fr">Et voilà !</ph>.</p>
</body>
</topic>