Internationalization Tag Set (ITS)
ITS
W3C Working Draft
22
February
2006
http://www.w3.org/TR/2005/WD-its-20060222/
http://www.w3.org/TR/its
http://www.w3.org/TR/2005/WD-its-20051122/
Christian Lieske
SAP
Felix Sasaki
W3C
This document defines data categories and their implementation as a set of elements and
attributes called the Internationalization Tag Set
(ITS). ITS is designed to be
used with new and existing schemas to support the internationalization and localization of
schemas and documents. An implementations is provided for three schema languages: XML
DTDs, XML Schema and RELAX NG. The document provides examples
of how ITS can be used with existing
vocabularies. The definition of the data
categories is still in an early draft
stage. Feedback is especially appreciated on
the general concept of ITS and the mechanisms
defined for the selection of ITS specific
information in documents and schemata.
This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.
This is a First Public Working Draft of "Internationalization Tag Set
(ITS)".
This document defines data categories and their implementation as a set of elements and
attributes called the Internationalization Tag Set
(ITS). ITS is designed to be
used with new and existing schemas to support the internationalization and localization of
schemas and documents. An implementations is provided for three schema languages: XML
DTDs, XML Schema and RELAX NG. The document provides examples
of how ITS can be used with existing vocabularies. The definition of the data categories is still in an early draft stage. Feedback is especially appreciated on the general concept of ITS and the mechanisms
defined for the selection of ITS specific information in documents and schemata.
This document was developed by the ITS Working Group, part of the W3C Internationalization Activity.
The Working Group expects to advance this Working Draft to Recommendation Status (see W3C document
maturity levels).
the Working Group is tracking comments on
this document using W3C's public
Bugzilla system. We recommend using Bugzilla
for making comments (instructions can be found
at TODO). If this is not feasible, comments may also be sent to www-i18n-comments@w3.org. Use "Comment on its tagset WD" in the subject line of your email.
ITS comments and issues in
Bugzilla and the www-
i18n-comments archives are publicly available.
Per section
4 of the W3C Patent Policy, Working Group participants have 150 days from the title
page date of this document to exclude essential claims from the W3C RF licensing
requirements with respect to this document series. Exclusions are with respect to the
exclusion reference document, defined by the W3C Patent Policy to be the latest version of a
document in this series that is published no later than 90 days after the title page date of
this document.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a
draft document and may be updated, replaced or obsoleted by other documents at any time. It
is inappropriate to cite this document as other than work in progress.
This document was produced under the 5 February 2004 W3C Patent
Policy. Since the Working Group expects this document to become a W3C
Recommendation, under that policy it has associated W3C Royalty-Free Licensing oblications.
The Working Group maintains a public list of patent disclosures relevant to this document; that page also
includes instructions for disclosing a patent. An individual who has actual knowledge of a
patent which the individual believes contains Essential Claim(s) with respect to this
specification should disclose the information in accordance with section 6 of
the W3C Patent Policy.
en
This is the first version of this document.
Introduction
This section is informative.
This document defines data categories and their implementation as a schema that can be
used with new and existing schemas to support the internationalization and localization
of schemas and documents. An implementation is provided for three schema languages: XML
DTDs , XML Schema and RELAX NG . The document provides examples of how ITS can be used with existing vocabularies.
Requirements for the internationalization and localization of markup are formulated in
. This working draft responds to only a part of
these requirements. Some of the following items are mentioned in , but are not covered in this working draft:
-
R001 - Indicator of Constraints
-
R005 - Handling Entities
-
R023 - Linguistic Markup
These requirements have not been addressed at this point in time since the ITS Working
Group expects that it will take a substantial amount of time to address them, but that
the framework suggested in this document will accomodate them.
Other requirements will also be addressed in the future in a document on techniques for internationalization and localization of XML schemas and XML instances.
Background: Motivation for ITS
Content or software that is authored in one language (i.e. source language) is often
made available in additional languages. This is done through a process called
localization, where the original material is translated and adapted to the target
audience.
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
.
The increasing usage of XML as a medium for documentation-related content (e.g.
DocBook , a format for writing structured documentation, well suited to computer
hardware and software manuals) and software-related content (e.g. the eXtensible User
Interface Language ) creates challenges and
opportunities in the domain of XML internationalization and localization. In the following examples, the text in bold face [...] shows the parts that need to be localized.
Document with localizable content
Without localization-specific information it is difficult for tools to detect that PhaseCode should not be translated, or that the title attribute sometimes does and sometimes does not.
<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>
Document with localizable information
In this example the first file name in the first
component would normally 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>
Document with localizable information
In the example below, there are no clear mechanism 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>
Out of Scope
The data categories and their implementation as a schema does not address
document-external mechanisms or data formats for describing localization-relevant
information over and above what is appropriate for inclusion in the format itself. Such
mechanisms and data formats, also sometimes called XML Localization
Properties, are out of the scope of this document. However, this document
specifies a methodology how localization properties and information about
internationalization and localization can be applied to various places in schemas and
instance documents. See .
Important Design Principles
Data categories: ITS defines data categories as a description of information for internationalization and
localization of XML schemas and documents. This description is independent of its
implementation e.g. via an element or attribute. See for a definition of the term data categories, for the definition of the various ITS data categories, and for the data category implementations.
Selection
mechanisms: Content
authors need a simple way to
express whether the content of
an element or attribute should
be translated or not, e.g. a
translate
attribute. On the other hand,
for translations of large
document sets based on the
same schema, a specification
of defaults for
translatability and exceptions
from the defaults is of
importance (e.g. all
p elements should
be translated, but not
p elements inside
of an index
element). This specification
responds to these conflicting
requirements by introducing
mechanisms for selecting ITS
information in
XML documents or schemata, see
. The
methodology also provides a
means for selecting ITS
information in attributes (a task for which no standard means exists yet). The ITS mechanisms for selection need to consider the following:
-
viable for both XML schemata and XML instances
-
viable in situ (at the XML node to which it pertains) or dislocated (not at the XML node to which it pertains)
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 general extension mechanism, since ordinary XML mechanisms (e.g. XML Namespaces ) may be used.
Easy of
integration:
-
ITS follows the example from section 4 of , by providing mostly
global attributes for the implementation of ITS data categories. Avoiding elements for ITS purposes as much as
possible assures easy of integration into existing markup schemes, see section 3.14 in . Only for some requirements additional child
elements have to be used, see for example .
-
No dependence on technologies which are yet to be developed
-
Fit with existing work in the W3C architecture (e.g. use of
XPath as a selection mechansim)
Development of this Specification
This specification has been developed using the ODD (One
Document Does it all) language of the Text Encoding Initiative
(). This is a literate
programming language for writing XML schemas, with three
characteristics:
-
The element and attribute set is specified using an XML
vocabulary which includes support for macros (like DTD entities, or
schema patterns), a hierarchical class system for attributes and
elements, and creation of modules.
-
The content models for elements and attributes 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
DTDs. From the Relax NG documents, James Clark's trang can be
used to create XML Schema documents.
Notation and Terminology
This section is normative.
Notation
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
The namespace URI that must be used by
implementations of this specification is:
http://www.w3.org/2005/11/its
The namespace prefix used
in this specification for this
URI is "its". It is recommended that implementations of this specification use
this prefix.
In addition, the following namespaces are used in this document:
-
http://www.w3.org/2001/XMLSchema for the XML Schema namespace,
here used with the prefix "xs"
-
http://relaxng.org/ns/structure/1.0 for the RELAX NG namespace, here
used with the prefix "rng"
Schema Language and
Schema Annotation
The term schema language refers in
this specification to XML DTDs, XML Schema or RELAX NG.
Schema
annotation is a schema language specific means to provide information about
element, attribute, type etc. declarations. This information is not used by the
schema processor, but for external, validation independent
applications.
Data category
ITS defines data category as an abstract concept for a particular type of information for internationalization and localization of XML schemas and documents. The concept of a data category is independent of its implementation in an XML environment (e.g. via an element or attribute).
For each data category, ITS distinguishes between the following:
-
the prose description, see
-
schema language independent formalization, see
-
schema language specific implementations, see
Data categories and their implementation
The data category translatability conveys mainly information 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.
An alternative formalization on a schema language independent level is a schemaRule element which conveys via a translate attribute information about translatability. An implementation on a schema language specific level is the declaration of the schemaRule element.
Selection
The term
selection
encompasses
mechanisms to
specify to
what parts of
an XML
document or
schema an ITS data category and its values
should be applied to.. Selection is discussed in detail in .
Selection of ITS information
This section is normative.
Relation between Data
Categories and Selection Mechanisms
A selection of parts of
an document or schema is
always made for a single data category. The
selection can be made in various positions, which are defined in .
Example for the
selection of
information about translatability, expressed
via a translateSelector attribute
<text its:translate="yes" its:translateSelector="//p">...
<!-- all p elements should be translated, except the following one -->
<p its:translate="no" its:translateSelector="."/>
</text>
Locations of Data
Categories and Selection Mechanisms
Selections of ITS
Information can appear in three places:
-
in
a schema: ITS
data categories are expressed as schema annotation, and the selection is the element or attribute declaration which is being annotated
-
dislocated:
the selection
is realized as
a selector attribute,
which which appears
together with
a datacategory
attribute. The selector
attribute
contains
an AbsoluteLocationPath as described in
-
in
an instance
document:
the selection
is realized as
a selector
attribute,
which appears
together with
a datacategory
attribute. The selector
attribute contains a RelativeLocationPath or AbbreviatedStep as described in
The various selection mechanisms are defined in detail below.
Schema Annotation
In Schemas,
selection of ITS
information is
realized via schema
annotation. The
selection for a data category depends on the position of
the schema annotation. Since schema annotation mechanisms are schema language
specific, the following definitions are made:
-
selection of elements in XML Schema is expressed via an
xs:appinfo element which is a direct child of the
xs:element element and which contains a
schemaRule
element,
which has
one
or
more datacategory
attributes.
Selection of elements in an XML Schema
<xs:element name="p">
<xs:annotation>
<xs:appinfo>
<its:schemaRule translate="yes"/>
</xs:appinfo>
</xs:annotation> ...
</xs:element>
-
selection
of
attributes in XML Schema is expressed via an
xs:appinfo element which is a direct child of the
xs:attribute element and which
contains
a schemaRule
element,
which has
one
or
more datacategory
attributes.
Selection
of attributes in an XML Schema
<xs:attribute name="alt">
<xs:annotation>
<xs:appinfo>
<its:schemaRule translate="yes"/>
</xs:appinfo>
</xs:annotation> ...
</xs:attribute>
-
selection
of
elements
in RELAX NG is expressed via a schemaRule element which is a direct child of the
rng:element element, and which has
one
or
more datacategory
attributes.
Selection
of elements in Relax NG
<element name="p">
<its:schemaRule translate="yes"/> ...
</element>
-
selection
of
attributes in RELAX NG is expressed via a schemaRule element which is a direct child of the
rng:attribute element, and which has one
or
more datacategory
attributes.
Selection of attributes in Relax NG
<attribute name="p">
<its:schemaRule translate="yes"/> ...
</attribute>
As for XML DTD,
this specification
defines no selection mechanism within the DTD.
To be able
to select
elements or
attributes
defined within
a XML DTDs, the mechanisms described in
can be used.
Several data categories on the same element or attribute declaration should be expressed at the same schemaRule element.
Several data categories at the same element
<its:schemaRule translate="yes" locInfo="This has to be handled carefully"
locInfoType="alert"/>
Dislocated Selection
Dislocated
selection is realized via a documentRules element. It contains one or more documentRule elements. Each documentRule
element has one or more data category attributes, and for each data
category attribute an selector attribute
which points to the selected information.
The naming convention for the selector attributes is datacategory +
Selector, e.g. translateSelector. As
for dislocated selections, the value of the attribute
must be an XPath
expression which starts with "/", that is, it must be an AbsoluteLocationPath as described in . Only in this way it is assured that the selection can be applied in a dislocated way.
Dislocated selection can appear in a schema (e.g. as content of the
xs:appinfo element), in an instance file or in a separate XML document.
The precedence of the processing of the selection information depends on these variations. See also .
The difference between schemaRule and documentRule is that schemaRule has no selector attributes, e.g. no translateSelector attribute. The reason is that
schemaRule always refers to the element or
attribute declaration of which it is part of. In
contrast, documentRule can be used
everywhere in a schema to express
dislocated selection information. It is possible to use schemaRule and documentRule together in a
schema.
Example for using schemaRule and documentRules together in a schema.
<xs:schema>
<xs:annotation>
<xs:appinfo>
<its:documentRules>
<its:documentRule translate="no" translateSelector="//p[@editor='john']"/>
<!-- This rule holds for p elements which are edited by John. -->
</its:documentRules>
</xs:appinfo>
</xs:annotation>
<xs:element name="p">
<xs:annotation>
<xs:appinfo>
<its:schemaRule translate="yes"/>
<!-- This rule holds for all p elements -->
</xs:appinfo>
</xs:annotation> ...
</xs:element> ...
</xs:schema>
Selection in an Instance Document
In instance
documents, selection
of ITS information is
realized via a
combination of a datacategory
attribute
and a selector attribute for the data category. The naming convention for the selector attributes is datacategory + Selector, e.g. translateSelector. This is identical to .
Selection of the content of an element and all attributes attached to the element.
<p its:translate="yes"> ... <em>...</em> ... </p>
equals
<p its:translate="yes" its:translateSelector="descendant-or-self::*">
... <em>...</em> ... </p>
Selection in an instance document must be either expressed via an AbbreviatedStep
"."
or it must
be a RelativeLocationPath
as described in . If
the value of the selector attribute is the AbbreviatedStep ".", its evaluation must always be interpreted as the textual value of the current node, that is, the textual value of an element to which the selector attribute is attached to. For example, <p its:dir="ltr" dirSelector="."> ... </p> is used to select the textual content of a p element.
To avoid mismatches between the multiple
selector attributes, only the following axis should be used in the XPath expression:
child, descendant, attribute,
descendant-or-self.
Selector attributes with various axis
<text its:translate="yes"
its:translateSelector="child::body/descendant::p">
<body its:translate="no" its:translateSelector="descendant::p/attribute::id"> ...
<p its:translate="no" its:translateSelector="descendant-or-self::*"> ... </p>
</body>
</text>
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):
-
In situ selector
attributes take precedence over the value inherited from other selector attributes.
-
Selections in instance documents (in situ, realized with selector attributes or the default selector rules
in )
-
Selections in instance documents (dislocated, using documentRule)
-
Selections in an external file (using documentRule)
-
In a
schema,
dislocated
selections
expressed via
a documentRule
element
-
Selections
expressed via schemaRule (See also the
note
in )
The
precedence
order fulfills the same purpose as the built-in template rules of .
Conflicts
between
selections of
ITS information which are resolved via the precedence order
Due to the rules described above, the
translatability information via the translate attribute at the p element has precedence over the translatability information at the documentRule element.
<text>
<head>
<its:documentRule its:translate="yes" its:translateSelector="//p"/>
</head>
<body> ...
<p its:translate="no"> ... </p>
</body>
</text>
Mapping In Situ Selector Attributes to Dislocated Selector Attributes
Both in situ selections of
ITS information and dislocated
selections apply to instance
documents. It must
be possible to map the values
of the in situ selector attributes
to dislocated selector
attributes at documentRule elements. This conversion can only be executed in a
generic way, if the in situ selector
attributes contain only relative path expressions.
Mapping of in situ selector
attributes to selector
attributes in a dislocated position
<body its:translate="no" its:translateSelector="child::p[1]/attribute::*">
<p its:translate="yes" its:translateSelector="descendant-or-self::*"/>
<p its:translate="yes" its:translateSelector="preceding-sibling::p/attribute::title"/>
</body>
<its:documentRules>
<its:documentRule its:translate="no"
translateSelector="/body/child::p[1]/attribute::*"/>
<its:documentRule its:translate="yes"
its:translateSelector="/body/child::p[1]/descendant-or-self::*"/>
<its:documentRule its:translate="yes"
its:translateSelector="/body/child::p[2]/preceding-sibling::p/attribute::title"/>
</its:documentRules>
Mapping of ITS Data Categories to Existing Markup
Some markup schemes provide markup which can be used to express ITS
datacategories. ITS data categories can be
mapped to such existing markup, using the dislocated selection
mechanism described in . In this way, there is no need to
integrate ITS markup into documents.
Mapping of the ITS data categories translatability and terminology to DITA markup
<dita:topic xmlns:dita="http://dita.oasis-open.org/architecture/2005/"
xmlns:its="http://www.w3.org/2005/11/its"
DITAArchVersion="1.0" id="myTopic">
<dita:title>Some little topic</dita:title>
<its:documentRules>
<its:documentRule
its:translateSelector="//*[@dita:translate='yes']" its:translate="yes" />
<its:documentRule
its:translateSelector="//*[@dita:translate='no']" its:translate="no" />
<its:documentRule
its:termSelector="//dita:term" its:term="yes" />
<its:documentRule its:termSelector="//dita:dt" its:term="yes" />
</its:documentRules>
<dita:body>[...]
<dita:dlentry id="tDataCat">
<dita:dt>Data category</dita:dt>
<dita:dd>ITS defines <dita:term>data category</dita:term> as an abstract
concept for a particular type of information for internationalization and
localization of XML schemas and documents.</dita:dd>
</dita:dlentry> […]
<dita:p>As for the implementation of ITS: just apply the rules in the order:</dita:p>
<dita:ul>
<dita:li>Default</dita:li>
<dita:li>Rules in the schema</dita:li>
<dita:li>Dislocated rules</dita:li>
<dita:li>in situ rules</dita:li>
</dita:ul>
<dita:p><dita:ph translate="no" xml:lang="fr">Et voila !</dita:ph> The last
rule wins</dita:p>
</dita:body>
</dita:topic>
Description of Data Categories
This section is normative.
The following table summarizes the
relations between data categories,
location of their selection mechanisms, and
default selections in instance documents.
| Data category |
Applicable in schema |
dislocated selection applicable |
default selection in instance document |
|
Translatability
|
+ |
+ |
Textual content
of element,
including
content of child elements, but
excluding attributes |
|
Localization information
|
+ |
+ |
Textual content
of element,
including
content of child elements, but
excluding attributes |
|
Terminology
|
+ |
+ |
Textual content
of element,
including
content of child
elements, but
excluding
attributes |
|
Directionality
|
- |
+ |
Textual content of element, including attributes and child elements |
|
Ruby
|
- |
+ |
Textual content
of element,
including
content of child
elements, but
excluding attributes |
The data categories differ with respect to defaults in the instance document for
compatibility reasons with existing standards and practices. For example, the
dir attribute in refers to the
content of the element and all attributes and child
elements. Hence, the data category of
directionalty selects the same information as the default. On the other
hand, it is common practice that information about translatability refers only to
textual content of an element. Hence, the data category of
translatability selects as a default the same information.
Translatability
Definition
The data category
translatability expresses information about whether the content of an
element or attribute should be translated or not.. The values of this
data category are yes (translatable) or no (not
translatable).
This definition of translatability is identical to the definition in . The implementation of this data category is
different from
since the former allows to specify the selected
information in
an XML
document or schema.
Implementation
Translatability can be expressed in a schema, dislocated or in an instance document.
In a schema, translatability is expressed via a schemaRule element with a translate attribute. The attribute has the values yes or
no.
Translatability expressed in a schema
<xs:element name="p">
<xs:annotation>
<xs:appinfo>
<its:schemaRule translate="yes"/>
</xs:appinfo>
</xs:annotation> ...
</xs:element>
Dislocated, translatability is expressed via a documentRule element with a translate attribute. The attribute has the values yes or
no. In addition, a translateSelector attribute is required.
Translatability expressed dislocated
<its:documentRules>
<its:documentRule translate="yes" translateSelector="//p"/>
<!-- All p elements should be translated-->
</its:documentRules>
In an instance document, translatability is expressed via a translate attribute with the values
yes or no. If no translateSelector attribute is
present, the selection is the textual content of the element, including child
elements, but excluding attributes. If a translateSelector attribute is
present, the selection is defined by the value of this attribute which is an XPath
expression.
Translatability expressed in an instance document
In the body element, all elements and attributes except id attributes should be translated. The content of the specified quote element, however, must not be translated.
<book>
<head>...</head>
<body its:translate="yes" its:translateSelector=".//* or .//@*[not(name()='id')]"> ...
<p>And he said: you need a new <quote its:translate="no">motherboard</quote>
</p> ...
</body>
</book>
Localization Information
Definition
The data category
localization information is used to communicate information to
localizers about a particular item of content.
This data category has several purposes:
-
Tell the translator how to translate parts of the content
-
Expand on the meaning or contextual usage of a particular element, such as what
a variable refers to or how a string will be used on the user interface
-
Clarify ambiguity and show relationships between items sufficiently to allow
correct translation (e.g. in many languages it is impossible to translate the word
enabled
in isolation without knowing the gender, number and case of
the thing it refers to.)
-
Indicate why a piece of text is emphasized (important, sarcastic, etc.)
Two types of informative notes are needed
-
An alert contains information that the translator must read before translating a
piece of text. Example: an instruction to the translator to leave parts of the text
in the source language.
-
A description provides useful background information that the translator will
refer to only if they wish. Example: a clarification of ambiguity in the source
text.
Implementation
Localization information can be expressed in a schema, dislocated or in an instance
document.
In a schema, localization information is expressed via a schemaRule element with a locInfo attribute. The type of the localization information is expressed via
a locInfoType attribute with
the values alert or description.
Localization information expressed in a schema
<xs:element name="p">
<xs:annotation>
<xs:appinfo>
<its:schemaRule locInfo="This has to be handled carefully" locInfoType="alert"/>
</xs:appinfo>
</xs:annotation> ...
</xs:element>
Dislocated, localization information is expressed via a documentRule element with the attributes locInfo and locInfoType. In addition, a locInfoSelector attribute is required.
Localization information expressed dislocated
<its:documentRules>
<its:documentRule locInfo="This p element has to be handled carefully"
locInfoType="alert" locInfoSelector="/body/p[1]"/>
</its:documentRules>
In an instance document, localization information is expressed via the attributes
locInfo and locInfoType. If no locInfoSelector attribute is present,
the selection is the textual content of element, including child elements,
but excluding attributes. If a locInfoSelector attribute is present,
the selection is defined by the value of this attribute which is an XPath expression.
Localization information expressed in an instance document
<book>
<head>...</head>
<body its:locInfo="Just translate all p elements." its:locInfoType="alert"
its:locInfoSelector="//p"> ...
<p its:locInfo="This p element has to be handled
carefully" its:locInfoType="alert">And he said: you need a new
<quote>motherboard</quote>
</p> ...
</body>
</book>
Terminology
Definition
The terminology data category is used to mark terms. This helps to increase consistency across different
parts of the documentation. It is also helpful for translation.
Implementation
The terminology data category can be expressed in a schema, dislocated or in an
instance document.
In a schema, the terminology data category is expressed via a schemaRule element with a term attribute, which has the value
yes.
The terminology data category expressed in a schema
<xs:element name="span">
<xs:annotation>
<xs:appinfo>
<its:schemaRule term="yes"/>
<!-- All span elements are used to mark up terms-->
</xs:appinfo>
</xs:annotation> ...
</xs:element>
Dislocated, the terminology data category is expressed via a documentRule element with the term attribute, which has the value
yes. A termSelector
attribute is required. In addition, an optional termRef attribute can be used to
refer to external information about the term. The datatype of termRef is xs:anyURI.
The terminology data category expressed dislocated
<its:documentRules>
<its:documentRule term="yes" termSelector="/body/p[1]/span"
termRef="http://example.com/termdatabase/#x142539"/>
</its:documentRules>
In an instance document, the terminology data category is expressed via a term attribute, which has the value
yes, and an optional termRef attribute. If no termSelector attribute is present, the selection is the textual content of the
element, without elements / attributes. If a termSelector attribute is present, the
selection is defined by the value of this attribute which is an XPath expression.
The terminology data category expressed in an instance document
<book>
<head>...</head>
<body> ...
<p>And he said: you need a new <quote its:term="yes">motherboard</quote></p> ...
</body>
</book>
Directionality
Definition
This data category expresses the directionality of a piece of text. Its values are
ltr, rtl, lro or rlo. This definition is compliant with the dir attribute in , except that does not allow for scoping.
Implementation
The dir attribute is used for the
implementation of the directionality data category. It has the four values ltr, rtl, lro or rlo.
Directionality can be expressed dislocated or in an instance document.
Dislocated, directionality is expressed via a documentRule element with the dir attribute. In
addition, a dirSelector attribute is
required.
Directionality expressed dislocated
<its:documentRules>
<its:documentRule dir="rtl" dirSelector="/body/p[1]/quote[xml:lang='he']"/>
<!-- Some Hebrew quotation -->
</its:documentRules>
In an instance document, directionality is expressed via a dir attribute. If no dirSelector attribute is present, the
selection is the textual content of the element, including all child element
and attributes. If a dirSelector
attribute is present, the selection is defined by the value of this attribute which is an
XPath expression.
Directionality expressed in an instance document
<book>
<head>...</head>
<body> ...
<p>And he said: <quote its:dir="rtl"> ... a Hebrew quotation ... </quote></p> ...
</body>
</book>
Ruby
Definition
The data category ruby is used for a run of text that is associated with another run of text,
referred to as the base text. Ruby text is used to provide a short annotation of the
associated base text. It is most often used to provide a reading (pronunciation)
guide.
Implementation
Ruby can be expressed in an instance document with or without selections.
Ruby in an instance document without selections is realized with a ruby element which contains a rubyBase and a rubyText element.
Ruby in an instance document without selection
<text>
<head> ... </head>
<body>
<p>This is about the <its:ruby>
<its:rubyBase>W3C</its:rubyBase>
<its:rubyText>World Wide Web Consortium</its:rubyText>
</its:ruby>.</p>
</body>
</text>
Handling Legacy Content
In legacy sitations, where one
cannot change the element markup and there one want to apply ruby text to
an attribute or existing element content, then the following
approaches can be used.
Ruby in an instance document with selections is expressed via two attributes:
-
A rubyText attribute
contains the ruby text (corresponding to the rubyText
element in the case of no selections)
-
A rubySelector attribute
contains the selector, that is the XPath expression. The XPath expression in this attribute selects the
ruby base text, corresponding to the rubyBase element
in the case of no selection.
Ruby in an instance document with selection
<text>
<head> ... </head>
<body>
<img src="w3c_home.png" alt="W3C"
its:rubySelector="@alt" its:rubyText="World Wide Web Consortium"/> ...
</body>
</text>
The structure of the content model for the ruby element
without selection is identical with the structure of ruby in section 5.4 of , and simple ruby markup as defined in section
1.2.1 in .
Schemas for ITS
This section is informative.
The following schemas are provided :
-
DTD for ITS
-
XML Schema document for ITS
-
RELAX NG compact syntax document for ITS
-
RELAX NG XML syntax document for ITS
References
James Clark, Makoto Murata. RELAX
NG Specification. OASIS Committee Specification 3 December 2001. Available at http://www.oasis-open.org/committees/relax-ng/spec-20011203.html. The latest
version of RELAX
NG is available at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=relax-ng.
S. Bradner.
Key Words for use in RFCs to
Indicate Requirement Levels. IETF RFC 2119. Available at http://www.ietf.org/rfc/rfc2119.txt.
Jonny Axelsson, Mark Birbeck, Micah Dubinko, Beth Epperson, Masayasu Ishikawa, Shane McCarron, Ann Navarro, Steven Pemperton. XHTML™ 2.0. W3C Working Draft 27 May 2005. Available at http://www.w3.org/TR/2005/WD-xhtml2-20050527. The latest version of XHTML 2.0 is available at http://www.w3.org/TR/xhtml2.
Steve DeRose, Eve Maler, David Orchard, Norman Walsh. XML Linking Language
(XLink) Version 1.1. W3C Working Draft 7 July 2005. Available at http://www.w3.org/TR/2005/WD-xlink11-20050707/. The latest version of XLink 1.1 is available at
http://www.w3.org/TR/xlink11/.
Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, et al.,
editors. Extensible Markup Language
(XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004. Available at http://www.w3.org/TR/2004/REC-xml-20040204/. The latest version of XML 1.0 is available at
http://www.w3.org/TR/REC-xml/.
Tim Bray, Dave Hollander, Andrew Layman. Namespaces in XML. W3C Recommendation 14 January 1999. Available at http://www.w3.org/TR/1999/REC-xml-names-19990114/. The latest version of XML Names is available at http://www.w3.org/TR/REC-xml-names/.
Henry S. Thompson, David Beech, Murray Maloney,
Noah Mendelsohn. XML Schema Part 1:
Structures Second Edition. W3C Recommendation 28 October 2004. Available at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. The latest version of XML Schema is
available at http://www.w3.org/TR/xmlschema-1/.
James Clark. XML Path Language (XPath)
Version 1.0. W3C Recommendation 16 November 1999. Available at http://www.w3.org/TR/1999/REC-xpath-19991116. The latest version of XPath 1.0 is available at
http://www.w3.org/TR/xpath.
References
OASIS
DITA Architectural Specification Committee Draft 01. Oasis Committee Specification 3 May 2005. Available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita.
Norman Walsh and Leonard Muellner. DocBook: The Definitive Guide. Available at
http://www.docbook.org/.
Richard Ishida, Susan
Miller. Localization
vs. Internationalization. Article of the W3C Internationalization
Activity, Januare 2006.
Yves Savourel. Internationalization and
Localization Markup Requirements. W3C Working Draft 5 August 2005. Available at http://www.w3.org/TR/2005/WD-itsreq-20050805/. The latest version of ITS REQ is available at
http://www.w3.org/TR/itsreq/.
Michael Brauer et al. OASIS Open Document Format for Office Applications (OpenDocument).. Oasis Standard 1 May 2005. Available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office. The latest
version of OpenDocument is available at
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office.
Marcin Sawicki (until 10 October, 1999), Michel
Suignard, Masayasu Ishikawa (石川 雅康), Martin
Dürst, Tex Texin, Ruby Annotation. W3C Recommendation 31 May 2001. Available at http://www.w3.org/TR/2001/REC-ruby-20010531/ . The latest version of Ruby Annotation is available at
http://www.w3.org/TR/ruby/.
Lou Burnard and Syd Bauman (eds). Text Encoding Initiative Guidelines development version (P5). TEI Consortium, Charlottesville, Virginia, USA, Text Encoding Initiative.
Steven Pemperton et al. XHTML™ 1.0 The Extensible
HyperText Markup Language (Second Edition). W3C Recommendation 26 January 2000, revised 1 August 2002. Available at http://www.w3.org/TR/2002/REC-xhtml1-20020801/. The latest version of XHTML 1.0 is available at
http://www.w3.org/TR/xhtml1/.
James Clark. XSL Transformations (XSLT)
Version 1.0. W3C Recommendation 16 November 1999. Available at http://www.w3.org/TR/1999/REC-xslt-19991116. The latest version of XSLT 1.0 is available at
http://www.w3.org/TR/xslt.
exTensible User Inferface Language. Available at http://www.xulplanet.com/.
Acknowledgements
This document has been developed with contributions by the ITS Working Group. At the date
of publication, the members of the Working Group were: Damien Donlon (Sun Microsystems),
Martin Dürst (Invited Expert), Richard Ishida (W3C), Masaki Itagaki (Invited Expert),
Christian Lieske (SAP), Naoyuki Nomura (Ricoh), Sebastian Rahtz (Invited Expert), François
Richard (HP), Goutam Saha (CDAC), Felix Sasaki (W3C), Yves Savourel (ENLASO), Dianne
Stoick (Boeing), Najib Tounsi (Ecole Mohammadia d'Ingeniéurs Rabat (EMI)) and Andrzej Zydroń (Invited Expert).
A special thanks goes to Sebastian Rahtz who introduced us to the ODD language, which was
used to create this document, and who provided the stylesheets to generate schemas and the
XHTML version (via xmlspec) out of an ODD document.
$Id: xmlspec2-input.xml,v 1.1 2006/02/01 09:17:57 fsasaki Exp $