The presentation of this document has been augmented to identify changes from a previous version. Three kinds of changes are highlighted: new, added text, changed text, and deleted text.
This document is also available in these non-normative formats: ODD/XML document and XHTML Diff markup to publication from 18 May 2006.
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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 the 2 November 2006 Candidate Recommendation of Internationalization Tag Set (ITS) Version 1.0. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. The Internationalization Tag Set (ITS) Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has demonstrated a) an updated Public Working Draft of [XML i18n BP] which contains at least two schemas in the formats of XML Schema and XML DTD which conform to the conformance clauses 1-1, 1-2, 1-3 and 1-4 formulated in Section 4.1: Conformance Type 1: ITS Markup Declarations; and b) at least two interoperable implementations of the conformance clauses 2-1 and 2-2 for each ITS data category, described in Section 4.2: Conformance Type 2: The Processing Expectations for ITS Markup, and linking of external rules. The Internationalization Tag Set (ITS) Working Group, working closely with the developer community, expects to show these implementations by December 2006. This estimate is based on the Working Group's preliminary implementation report. The Working Group expects to revise this report over the course of the implementation period. The Working Group does not plan to request to advance to Proposed Recommendation prior to 10 December 2006.
The following parts of the specification are considered at risk: a) the attributes rubyPointer, rtPointer, rpPointer, rbcPointer, rtcPointer and rbspanPointer b) the statement in Section 6.7.1: Definition on conformance to [RFC 4646], including the normative reference to [RFC 4646] c) the ns element defined in Section 5.2.1: Global, Rule-based Selection. The Working Group may recommend removing a) and b) from the specification, depending on their use and implementation experience. The Working Group may recommend removing c) (the ns element) if there is an implementation of Section 5.2.1: Global, Rule-based Selection in [XSLT 1.0] that uses the namespace binding mechanism via a prefixed prefixed namespace attribute. That implementation must be capable of processing namespace information in the selector attribute gathered from external rules as defined in Section 5.3: Link to External Rules.
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 schemas to support the internationalization and localization of schemas and documents. An implementation is provided for three schema languages: XML DTD, XML Schema and RELAX NG.
The Last Call Working Draft for this specification resulted in a number of Last Call comments which have all been addressed by the Internationalization Tag Set (ITS) Working Group; a list of all Last Call comments can be found in the Last Call Comments List. The list of changes made since the last public Working Draft is available in the changelog since the Last Call Working Draft from May 2006.
This document was developed by the Internationalization Tag Set (ITS) Working Group, part of the W3C Internationalization Activity. The Working Group expects to advance this Working Draft to Recommendation Status. A complete list of changes to this document is available.
Please make comments about this document using W3C's public Bugzilla system. We recommend using Bugzilla for making comments (instructions can be found at How to use the Issues Tracking System for the ITS Tagset Working Draft). If this is not feasible, comments may also be sent to www-i18n-comments@w3.org. Use "[Comment on ITS WD]" in the subject line of your email. A list of ITS tagset related comments and issues in Bugzilla and the www- i18n-comments archives are publicly available.
Publication as a Candidate Recommendation 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 by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; 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) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Motivation for ITS
1.2 Users and Usages of ITS
1.3 Out of Scope
1.4 Important Design Principles
1.5 Development of this Specification
2 Basic Concepts
2.1 Selection
2.2 Overriding and Inheritance
2.3 Addingthere Informationare
additional or Pointing to Existing Information
3 Notation and Terminology
3.1 Notation
3.2 Schema Language
3.3 Data category
3.4 Selection
3.5 Usage of Internationalized Resource Identifiers in ITS
4 Conformance
4.1 Conformance Type 1: ITS Markup Declarations
4.2 Conformance Type 2: The Processing Expectations for ITS Markup
5 Processing of ITS information
5.1 Indicating the Version of ITS
5.2 Locations of Data Categories
5.3 Link to External Rules
5.4 Precedence between Selections
5.5 Associating ITS Data Categories with Existing Markup
6 Description of Data Categories
6.1 Position, Defaults, Inheritance and OverridingSelections of Data Categories
6.2 Translate
6.3 Localization Note
6.4 Terminology
6.5 Directionality
6.6 Ruby
6.7 Language Information
6.8 Elements Within Text
A References
B References (Non-Normative)
C Summary of ITS Markup (Non-Normative)
D Schemas for ITS (Non-Normative)
E Checking ITS Markup Constraints (Non-Normative)
F Revision Log (Non-Normative)
G Acknowledgements (Non-Normative)
ITSThis document is a technologystandard for to easilycost efficient create XML which is internationalized and XML instances (both existing can be localized effectively. On the one hand, the ITS specification identifies concepts (such as "directionality")notion of which are important for internationalization and localization.categories. 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 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].
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:
R006 - identifying language/locale, see 6.7 Language Information
R008 - purpose specification/mapping, see 5.5 Associating ITS Data Categories with Existing Markup
R014 - limited impact, see 5.5 Associating ITS Data Categories with Existing Markup
R025 - elements and segmentation, see 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.
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.
Schema developers who work with an existing schema
The Working Group covers the question "How to“How use ITS with existing popular markup schemes?" is covered in more details (includingdetail 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 5.5 Associating ITS Data Categories with Existing Markup). The developer should, however, check that the behavior associated with the markup in their own schema is fully compatible with the expectations described in this specification.
Vendors of content-related tools
This type of user includes companies which provide tools for authoring, translation or other flavors of content-related software solutions. It is important to ensure that such tools enable worldwide use and effective localization of content. For example, translation tools should prevent content marked up as not for translation from being changed or translated. It is hoped that the ITS specification will make the job of vendors easier by standardising the format and processing expectations of certain relevant markup items, and allowing them to more effectively identify how content should be handled.
Content producers
This type of user comprises authors, translators and other types of content author. The markup proposed in this specification may be used by them to mark up specific bits of content. Aside: The burden of inserting markup can be removed from content producers by relating the ITS information to relevant bits of content in a global manner (see global, rule-based approach). This global work, however, may fall to information architects, rather than the content producers themselves.
In order to support all of these users, the information about what markup should be supported to enable worldwide use and effective internationalization and localization of content is provided in this specification in two ways:
abstractly in the data category descriptions: 6 Description of Data Categories
concretely in the ITS schemas: D Schemas for ITS
A content author or information architect uses markup at the top of the document to identify a particular type of element or context in which the content should not be translated.
The
translateRule
element is used in the header of the document to indicate that none of the fexp
elements should be translated.
<book xmlns:its="http://www.w3.org/2005/11/its" > <head> <its:rules its:version="1.0"> <its:translateRule selector="//fexp" translate="no"/> </its:rules> <title>The Life of a Simple Man</title> </head> <body> <p>Everything started when Zebulon discovered that he had a <fexp>doppelgänger</fexp> who was a serious baseball <fexp>aficionado</fexp>.</p> </body> </book>
[Source file: EX-ways-to-use-its-2.xml]
A processor may insert markup at the top of the document which links to ITS information outside of the document.
A rules schema developer element is insertedmarkup declarations in his schema to allow users to indicate that specific parts of the headercontent should not be translated.The first two approaches above can be likened to the use of theCSS in XHTML. Using a style attribute, an XHTML content author may assign document. It has a particular paragraph. That author XLink href also attribute used the style element at the top of the page to linksay that all paragraphs of a particular class to an ITSa externalparticular context rulewould document.
<book xmlns:its="http://www.w3.org/2005/11/its" xmlns:xlink="http://www.w3.org/1999/xlink" > <head> <its:rules its:version="1.0" xlink:href="EX-ways-to-use-its-4.xml"/> <title>The Life of a Simple Man</title> </head> <body> <p>Everything started when Zebulon discovered that he had a <fexp>doppelgänger</fexp> who was a serious baseball <fexp>aficionado</fexp>.</p> </body> </book>
[Sourcebe file: EX-ways-to-use-its-3.xml]red.
Theis
rules
often element contains severalin
additional ITS rules that are common to differentother
cultural documents. One of them is a
translateRule
process called
localization, where element that indicates that no fexp
and
adapted element should be translated.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <its:translateRule selector="//fexp" translate="no"/> <its:withinTextRule selector="//fexp|//strong" withinText="yes"/> <its:termRule selector="//term|//fexp" term="yes"/> </its:rules>
[SourceIn addition, document formats expressed by schemas may be used by people in different parts of the file: EX-ways-to-use-its-4.xml]
Aand schemathese people developer integrates ITS markup declarations to support the local language or script. For example, people authoring in hislanguages such as Arabic, Hebrew, Persian or Urdu need special schema to demarcate directionality allow users to indicate thattext.From specific parts of feasibility, cost, and efficiency, it is important that the contentoriginal material should notbe suitable for localization. be translated.
Theand declarations for the
translate
corresponding attribute is
referred addedto as internationalization. to a groupdetailed
explanation of commonthe terms "localization" and
"internationalization", attributes commonAtts
.The increasing usage of XML as Thisa medium for
documentation-related content (e.g. DocBook, and DITA as
formats for writing structured documentation, well allows to
computer hardware and software manuals) and software-related
content use the
translate
eXtensible User Interface attribute within) the documents likeand
opportunities in Examplethe domain of 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.translate.attributes"/> <xs:attribute name="id" type="xs:ID" use="optional"/> </xs:attributeGroup> <xs:element name="book"> <xs:complexType> <xs:sequence> <xs:element name="head"> <xs:complexType> <xs:sequence> <xs:element name="title" type="xs:string"/> </xs:sequence> <xs:attributeGroup ref="commonAtts"/> </xs:complexType> </xs:element> <xs:element name="body"> <xs:complexType> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element name="p"> <xs:complexType mixed="true"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="fexp"/> </xs:choice> <xs:attributeGroup ref="commonAtts"/> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> <xs:attributeGroup ref="its:att.version.attributes"/> </xs:complexType> </xs:element> <xs:element name="fexp"> <xs:complexType mixed="true"> <xs:attributeGroup ref="commonAtts"/> </xs:complexType> </xs:element> </xs:schema>
[SourceXML file: EX-ways-to-use-its-5.xsd]and localization.
The firstfollowing examples sketch one of two approaches abovethat
currently can be likened to the
use
lack of a standard, declarative mechanism which identifies
which parts of CSSan XML document need to be translated. Tools often cannot automatically do this inidentification.Document [XHTML 1.0].with Using a content
style
attribute,
anshould XHTML content author maythe
title assign a color to a
particularbe
translated and sometimes must not be translated.[Source file: EX-motivation-its-1.xml]Document with paragraph. That authorcontentThe could also have used the
first style
element would not be translated.[Source file: elementEX-motivation-its-2.xml]Document at the top ofcontentIn the pageexample below, to say that
allno paragraphs ofmechanisms
allowing a particular class or instring a particular
context would betranslated.[Source colored red.EX-motivation-its-3.xml]
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 for example an element or attribute. See 3.3 Data category for a definition of the term data categories, 6 Description of Data Categories for the definition of the various ITS data categories, and subsections in 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 Translatetranslatability 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 categorytranslatability and exceptions
from the defaults (e.g. all p
elements should be
translated, but not p
elements inside of an
index
element).
ToThis specification responds meet these requirements this specification introduces mechanisms that add ITS information to XML documents, see 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 toare:as provide information about content locally (specified at(at the XML node to which it pertains) or globally (specified in another partXML node of the document). Globalpertains)as selection mechanisms can be in the same document,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 do additional child elements have to be used, see for example 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]XPath for the selection mechanism)
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.
The mechanisms defined for ITS selection resemble those
defined in [CSS 2.1]. 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
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.
The document inEX-basic-concepts-1.xml]The Exampleexample 8above shows how a content author may use the
ITS
translate
attribute to indicate what text
that all content inside the author
elementtext 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.
The document inEX-basic-concepts-2.xml]The Exampleexample 9above shows a different approach to identifying
non-translatable content, similar to that used with a
style
element in [XHTML 1.0],XHTML, 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 theuse
structure of the document, like in a "head" section). It contains one or more data category
specific ITS rule 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 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 datatranslatability 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:
it pertains to the Translate data category translatability
the attribute translate holds a value of "no"
To summarize: The examples with global and local usage of ITS markup show that ITS markup, in some cases, appears in elements defined by ITS itself (the translateRule element (embedded within a rules element)) and in other cases appears in elements of the host vocabulary. In addition to one or more ITS data category specific attributes, translateRule or other rule elements contain a corresponding selector attribute. As their name suggests, a selector selects (or designates) one or more XML nodes (namely those to which a corresponding ITS data category attribute pertains). The value of ITS selector attributes are XPath absolute location paths. Information for to the handling of namespaces in these path expression is contained in the ITS element ns which is a child of rules . The ITS selector attribute allows:
ITS data category attributes to appear in global rules (even outside of an XML document or schema)
ITS data categories attributes to pertain to sets of
XML nodes (for example all p
elements in an XML
document)
ITS markup to pertain to attributes
ITS markup to
associate with existing markup (for example theterm
element in DITA)
The power of the ITS selection mechanisms comes at a price: rules related to overriding/precedence, and inheritance, have to be established.
TheOverriding document inInheritance[Source Examplefile: 10EX-basic-concepts-3.xml] shows how inheritance and overriding work for the
Translateattribute
translate
data category. By default elements
rules
element, are translatable. Here, the
translateRule
p element declared inSince the headerITS
selector
overrides the default forin the head
rules
element
selects inside text
and for all its children. Because the title
value element is actuallyfor translatable, the globaltranslatability rule needs to be overridden by a local the
its:translate="yes"
. Note that the global rulelocal is processed first,provides
precedence regardless of its position inside the document.like
this. In the main body of the document,no the default applies,to
say, and here it is its:translate="no"
that is used tobe
translated).Depending set "faux pas" as non-translatable.
Forto some dataselected nodes, categories, special attributes add or point toexisting information about the selected nodes. document. For example, the Localizationdata Notecategory data categorylocalization information can be used to add information to selected nodesnodes, or to point at existing information (using a locNote document. For element),the former or point at locInfo existing information elsewhere in For the document (using a locNotePointer locInfoPointer attribute can be 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.
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"
[Definition: Schema language refers in this specification to an XML-related modelling or validation language such as XML DTD, XML Schema or RELAX NG.]
Note:
This specification provides schemas in the format of XML DTD, XML Schema or RELAX NG. However, these schemas are only non-normative; conformance for ITS markup declarations defines only mandatory positions of ITS declarations in schemas. This makes it possible to use ITS with any schema language that allows for using these positions.
[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 prose description, see 6 Description of Data Categories
schema language independent formalization, see the "markup declarations" subsections in 6 Description of Data Categories
schema language specific implementations, see D Schemas for ITS
The Translate 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, forin 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.translatability.
[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 5 Processing of ITS information. Selection can be applied globally, see 5.2.1 Global, Rule-based Selection, and locally, see 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 text nodes. In
some cases these nodes form pointers to other resources; a well-known
example is the src
attribute on the img
element in
HTML. The ITS Translatetranslatability 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.
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 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.
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.
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 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 5 Processing of ITS information and 6 Description of Data Categories (e.g. 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:
rules element
one of the local ITS attributes
span element
ruby element
1-2: If the
rules
element is
used, it MUST be part of the
content model of at least one element declared in the
schema. It SHOULD be in a
content model for meta information, if this is available
in that schema (e.g. the head
element in
[XHTML 1.0]).XHTML).
1-3: If the ruby element is used, it SHOULD be declared as an inline element.
1-4: If the span element is used, it SHOULD be declared as an inline element.
Full implementations of this conformance type will implement all markup declarations for ITS. Statements related to this conformance type MUST list all markup declarations they implement.
Examples: Examples of the usage of ITS markup declarations in various existing schemas are given in a separate document [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 D Schemas for ITS are only informative examples.
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 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 5 Processing of ITS information. The individual data categories defined in 6 Description of Data Categories have defaults / inheritance / overriding characteristicsselections, and allow for using ITS markup in various positions (global and local). In addition, a set of processing expectations specific to the ruby data category and the directionality data category, refer to external specifications.
Who uses this conformance type: Applications 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 Translatetranslatability data category is not covered by the conformance clauses below.
Conformance clauses:
2-1: A processor MUST implement at least one data category. For each implemented data category, the following MUST be taken into account:
2-1-1: processing of at least one selection mechanism (global or local).
2-1-2: the default selections for the data category.
2-1-3: the precedence definitions for selections defined in 5.4 Precedence between Selections, for the type of selections it processes.
2-2: If an application claims to process ITS markup for the ruby data category or the directionality data category, it MUST be compliant with the external specifications referenced for ruby or directionality. 2-3: If an application claims to process ITS markup for the global selection mechanism, it MUST process an XLink href attribute found on a rules elements.
Statements related to this conformance type MUST list all data categories they implement, and for each data category which type of selection they support.
The version of the ITS schema defined in this specification is
"1.0". The version is indicated by the ITS
version
attribute. This attribute is mandatory for the
rules
element, where it MUST be in the ITS namespace and use its prefix, for examplee.g. its:version
. If there is no
rules
element in an
XML document, the ITS
version
attribute
MUST be provided on the
root element of the document. If there is both a
version
attribute at the root element and a
rules
element in a
document, they MUST NOT specify
different versions.
Each XML document can have a different version. That is: if external rules are linked via an XLink href attribute on the rules element, they can specify a different version than the rules element.
ITS data categories can appear in two places:
Global rules: the selection is realized within a rules element. It contains rule elements for each data category. Each rule element has a selector attribute and possibly other attributes. The selector attribute contains an AbsoluteLocationPath as described in XPath 1.0 or its successor..
Locally in a document: the selection is realized using ITS local attributes, which are attached to anthe selected element node, or the span or ruby element. There is no additional selector attribute. The default selection for each data category defines whether the selection covers attributes and child elements. See 6.1 Position, Defaults, Inheritance and OverridingSelections of Data Categories.
The two locations are described in detail below.
Global, rule-based selection is implemented using the rules element. It contains zero or more rule elements. Each rule element has a mandatory selector attribute. This attribute and all other possible attributes on rule elements are in the empty namespace and used without a prefix.
If there is more than one rules element in an XML document, the rules from each section are to be processed at the same precedence level. The rules sections are to be read in document order, and the ITS rules with them processed sequentially. The versions of these rules elements MUST NOT be different.
Depending on the data category and its usage, there are additional attributes for adding information to the selected nodes, or for pointing to existing information in the document. For example, the Localization Note data category localization information can be used for adding notes to selected nodes, or for pointing to existing notes in the document. For the former purpose, a locNote element can be used. For the latter purpose, a locNotePointer attribute can be used.
Each data category allows you to addadding information to the selected nodes nodes except 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: markup for pointing and adding MUST NOT appear in the same rule element.
Another difference between adding and pointing is the usage of XPath:
The value of the
selector
attribute MUST be an XPath expression
which starts with "/
". That is, it must
be an
AbsoluteLocationPath as described in XPath 1.0 or its successor.. This ensures that
the selection is not relative to a specific
location. The resulting nodes MUST be either element or
attribute nodes.
AttributesAs for data category specific attributes like
locInfoPointer
that point to existing information in the document, i.e. attributes whose name ends in ...Pointer
, MUST use a
RelativeLocationPath as described in XPath
MUST 1.0be or its successor. The XPath expression is evaluated relative to the nodes which
are selected by the
selector
attribute. The following attributes point to existing information:
locNotePointer
,
locNoteRefPointer
,
termInfoPointer
,
termInfoRefPointer
,
rubyPointer
,
rtPointer
,
rpPointer
,
rbcPointer
,
rtcPointer
,
rbspanPointer
,
langPointer
.
If namespaces [XML Names] are used in XPath expressions in the selector attribute or the pointing attributes, the following rules MUST be applied while processing XPath:
For each prefix, there MUST be an 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.
Note:
The usage of the ns element is inspired by [Schematron] and compliant to the requirements on namespace bindings described in [Tag Namespace Finding].
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 5.4 Precedence between Selections.
Markup for global, rule-based selection is defined as follows.
[1] | rules | ::= | element its:rules { rules.content, rules.attributes } |
[2] | rules.content | ::= |
ns*,
(
translateRule
| locNoteRule
| termRule
| dirRule
| rubyRule
| langRule
| withinTextRule
)* |
[3] | rules.attributes | ::= |
att.version.attributes, attribute xlink:href { xsd:anyURI }? |
[4] | ns | ::= | element its:ns { ns.content, ns.attributes } |
[5] | ns.content | ::= | empty |
[6] | ns.attributes | ::= | attribute prefix { xsd:NCName }, attribute uri { xsd:anyURI } |
[7] | att.selector.attributes | ::= |
att.selector.attribute.selector
|
[8] | att.selector.attribute.selector | ::= | attribute selector { string } |
[9] | att.version.attributes | ::= |
att.version.attribute.version
|
[10] | att.version.attribute.version | ::= | attribute its:version { xsd:float } |
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 .
The content model of span permits arbitrary nesting of ruby markup,on since the rb and rt elements themselves can contain span . An application of ruby MUST not use such arbitrary nesting.
The data category determines what is being selected. selected. The necessary data category specific defaults are described in 6.1 Position, Defaults, Inheritance and OverridingSelections of Data Categories.
By default the content of all elements in a document is translatable. The attribute
its:translate="no"
in the head
element means that the textual content of this element, including child elements, should not be translated. The attribute its:translate="yes"
in the title
element means that the textual content of this element, should be translated (overriding the its:translate="no"
in head
. be
translated. Attribute values of the selected elements or their children are not affected by local
translate
attributes. By default they are not translatable.
The default directionality of a document is left-to-right. The
its:dir="rtl"
in
the quote
element means that the directionality of the textual
content of this element, including child elements and attributes, is right-to-left. Note that xml:lang
indicates only the language, not the directionality."left-to-right".
<text
xmlns:its="http://www.w3.org/2005/11/its"
its:version="1.0" xml:lang="en">
<head
its:translate="no">
<author>Sven Corneliusson</author>
<date>2006-09-26T17:34:04Z</date>
<title
its:translate="yes" role="header">Bidirectional Text</title>
</head>
<body>
<par>In Arabic, the title <quote xml:lang="ar"
its:dir="rtl">نشاط التدويل، W3C</quote>
means <quote>Internationalization Activity, W3C</quote>.</par>
</body>
</text>
[Source file: EX-selection-local-1.xml]
Markup for local selection is defined as follows.
[11] | span | ::= | element its:span { span.content, span.attributes } |
[12] | span.content | ::= | ( text | ruby | span )* |
[13] | span.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
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.
The result of processing the two documents above is the same as processing the following document.
Applications processing global ITS markup MUST recognize the XLink href attribute in the rules element; they MUST load the corresponding referenced document and process its rules element before processing the content of the rules element where the original XLink href attribute is.
External rules may also have links to other external rules. The linking mechanism is recursive, the deepest rules being overridden by the top-most rules, if any.
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 6.1 Position, Defaults, Inheritance and OverridingSelections of Data Categories
In case of conflicts between global selections via multiple rule elements, the last selector has higher precedence.
Note:
The precedence order fulfills the same purpose as the built-in template rules of [XSLT 1.0].
The two elements title
rules and author
above, of thislocal
translatability document should be treated as separate content when inside afrom prolog
element, but as part of the content of their parent element otherwise. In order to make this distinction two
withinTextRule
attribute elements are used:
The first rule specifiesthe that title
and author
has in generalover
the should be treated as an element within text. This overrideson the default.
Thefirst
translateRule
second rule indicates that when title
or author
inside are found in aof prolog
elementelements,
because their content should be
translateRule
treated separately. This
conflict is normallyresolved via the default, but the
translateRule
rule is needed to override the first rule.higher
precedence).
<text xmlns:its="http://www.w3.org/2005/11/its" > <prolog> <its:rules its:version="1.0"> <its:withinTextRule withinText="yes" selector="//title|author"/> <its:withinTextRule withinText="no" selector="//prolog/title|author"/> </its:rules> <title>Designing User Interfaces</title> <author>Janice Prakash</author> <keywords>user interface, ui, software interface</keywords> </prolog> <body> <p>The book <title>Of Mice and Screens</title> by <author>Aldus Brandywine</author> is one of the best introductions to the vast topic of designing user interfaces.</p> </body> </text>
[Source file: EX-selection-precedence-1.xml]
Some markup schemes provide markup which can be used to express ITS data categories. ITS data categories can be associated with such existing markup, using the global selection mechanism described in 5.2.1 Global, Rule-based Selection. In this way, there is no need to integrate ITS markup into documents.
Associating existing markup with ITS data categories can be only done onlyif the processing expectations are the same or if the processing expectations of the host markup are the same as, or greater than, those ofas ITS.
<topic xmlns:its="http://www.w3.org/2005/11/its" id="myTopic"> <title>The ITS Topic</title> <prolog> <its:rules its:version="1.0"> <its:translateRule selector="//*[@translate='no']" translate="no"/> <its:translateRule selector="//*[@translate='yes']" translate="yes"/> <its:termRule 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 related to internationalization and localization of XML schemas and documents.</dd> </dlentry> </dl> <p>For the implementation of ITS, apply the rules in the order:</p> <ul> <li>Defaults</li> <li>Rules in external files</li> <li>Rules in the document</li> <li>Local attributes</li> </ul> <p> <ph translate="no" xml:lang="fr">Et voilà !</ph>.</p> </body> </topic>
[Source file: EX-associating-its-with-existing-markup-1.xml]
Global rules can be associated with a given XML document using different means:
By using an rules element in the document itself:
with the rules directly inside the document, as shown in Example 20
with a link to an external rules file using the XLink href attribute, as shown in Example 16
By associating the rules and the document through a tool-specific mechanism. For example, for a command-line tool: providing the paths of both the XML document to process and its corresponding external rules file.
Default values apply if both local or global selection are absent. The default value for the Translate data category for example mandates that elements are translatable, and attributes are not translatable if there is no translateRule element and no translate attribute available.
Inheritance describes whether ITS information is applicable to child elements of nodes and attributes related to these nodes or their child notes. The inheritance for the Translate data category for example mandates that all child elements of nodes are translatable whereas all attributes related to these the nodes or their child notes are not translatable.
Overriding describes whether ITS information can be overridden or not. Overriding is only applicable for data categories with inheritance. Overriding thus is not applicable for the Terminology and the Ruby data category.
Data category | Local Usage | Global, rule-based selection | Global adding of information | Global pointing to existing information | Default Values | Inheritance | Overriding |
Translate | Yes | Yes | Yes | No |
translate="yes" for elements, and translate="no" for attributes | Textual content of element, including content of child elements, but excluding attributes | Yes |
Localization Note | Yes | Yes | Yes | Yes | None | Textual content of element, including content of child elements, but excluding attributes | Yes |
Terminology | Yes | Yes | Yes | Yes |
term="no"
| None | Not applicable |
Directionality | Yes | Yes | Yes | No |
dir="ltr"
| Textual content of element, including attributes and child elements | Yes |
Ruby | Yes | Yes | Yes | Yes | None | None | Not applicable |
Language Information | No | Yes | No | Yes | None | Textual content of element, including attributes and child elements | Yes |
Elements Within Text | No | Yes | Yes | No |
withinText="no"
| None | Not applicable |
In this example, the content of all the data
XML elements is translatable because the defaultdocument for
the Translatecompatibility data category inexisting
standards elements is "yes".For The content of revision
and
locNote
attribute is not translatable becauserefers
to the default is overridden byof the local its:translate="no"
attribute in the prolog
element,element and that value is inherited by all the children of prolog
.
The localization notechild
elements. for the two first data
elementscategory
of isdirectionality the text defined globally withselects the
locNoteRule
element. And this note is overridden for the
default. last data
elementOn by the local
its:locNote
other attribute.
<Res xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <prolog its:translate="no"> <revision>Sep-07-2006</revision> <its:rules its:version="1.0"> <its:translateRule selector="//msg/notes" translate="no"/> <its:locNoteRule locNoteType="description" selector="//msg/data"> <its:locNote>The variable {0} is the name of the host.</its:locNote> </its:locNoteRule> </its:rules> </prolog> <body> <msg id="HostNotFound"> <data>Host {0} cannot be found.</data> </msg> <msg id="HostDisconnected"> <data>The connection with {0} has been lost.</data> </msg> <msg id="FileNotFound"> <data its:locNote="{0} is a filename">{0} not found.</data> </msg> </body> </Res>
[Sourcehand, file: EX-datacat-behavior-1.xml]
Note:
The data categories differ with respect to defaults. This is dueit to existing standards and practices. It is common practice for example that information about translation refers only to textual content of an element. Thus, the defaultdata selection for thetranslatability selects Translateas data category is the textual content.
The Translate 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).
The Translate data category can be expressed with global rules, or locally on an individual element.As The information applies to the textual content of the element, including child elements, but excluding attributes. The defaulttranslatability is that elements are translatable and attributes are not.
GLOBAL: Thewith a translateRule element contains the following:
The
translateRulea
selector
element specifies thatrequired.Translatability the elements code
must not be translated.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <its:translateRule translate="no" selector="//code"/> </its:rules>
[Source file: EX-translate-selector-1.xml]
LOCAL: The following localtranslatability markup is available for the Translate data category:
A a translate attribute with the value "yes" or "no".
Note:
It The selection is notthe textual possible to overrideof the Translateelement, dataincluding child category settings ofexcluding attributesattributes.Translatability using locallocallyIn markup. Thisbody limitation is consistent with and the advised practicecontent of not using translatable attributes.
The
content local its:translate="no"
the specifies that the content of panelmsg
however, must not be translated.
<messages xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <msg num="123">Click Resume Button on Status Display or <panelmsg its:translate="no">CONTINUE</panelmsg> Button on printer panel></msg> </messages>
[Source file: EX-translate-selector-2.xml]
[14] | translateRule | ::= |
element its:translateRule
{
translateRule.content,
translateRule.attributes
} |
[15] | translateRule.content | ::= | empty |
[16] | translateRule.attributes | ::= |
att.selector.attributes,
attribute translate { "yes" | "no" } |
[17] | att.translate.attributes | ::= |
att.translate.attribute.translate
|
[18] | att.translate.attribute.translate | ::= | attribute its:translate { "yes" | "no" }? |
The Localizationdata Notecategory data category is used to communicate notes to localizers about a particular item of content.
This data category can be used forhas several purposes, including, but not limited to:purposes:
Tell the translator how to translate parts of the content
Expand on the meaning or contextual usage of a specific element, such as what a variable refers to or how a string will be used on the user interface
Clarify ambiguity and show relationships between items sufficiently to allow correct translation (e.g. in many languages it is impossible to translate the word "enabled" in isolation without knowing the gender, number and case of the thing it refers to.)
Indicate why a piece of text is emphasized (important, sarcastic, etc.)
Two types of informative notes are needed:
An alert contains information that the translator must read before translating a piece of text. Example: an instruction to the translator to leave parts of the text in the source language.
A description provides useful background information that the translator will refer to only if they wish. Example: a clarification of ambiguity in the source text.
Editing tools may offer an easy way to create this type of information. Translation tools can be made to recognize the difference between these two types of localization notes, and present the information to translators in different ways.
The Localization Note datainformation category can be expressed with global rules, or locally on an individual element.Using The information applies to the textual contentinformation of the element, includingis child elements, butwith excluding attributes.
GLOBAL: Thea locNoteRule element contains the following:
Aa required selector attribute. It contains an XPath locInfoType expression which selects the nodesassociated to which this rule applies.
A required locNoteType attribute with the value "description"can or "alert".
Exactlyindicated one of the following:
Ausing locNote either element that locInfo contains the note locInfoRef itself and allows locInfoPointer for localor ITS markup.
A locInfoRefPointer locNotePointer attribute. attribute that locInfo contains a locInfoRef relative XPath locInfoPointer expression pointing to locInfoRefPointer MUST a nodeNOT that holds the localization note.
together.
A locNoteRef attribute that contains a URI referringitself.The to locInfo theelement[Source location of the localization note.EX-locInfo-element-1.xml]
A locNoteRefPointer attribute that contains a relative XPath expression pointing to a node thatan holds the URI referring to the location of the localization note.information.
The locNoteRule element associates the content of the locNote element with the message with the identifier 'DisableInfo' and flags it as important. This would also work if the rule was in an external file, allowing to provide notes without modifying the source document.
<myRes xmlns:its="http://www.w3.org/2005/11/its" > <head> <its:rules its:version="1.0" its:translate="no"> <its:locNoteRule locNoteType="alert" selector="//msg[@id='DisableInfo']"> <its:locNote>The variable {0} has three possible values: 'printer', 'stacker' and 'stapler options'.</its:locNote> </its:locNoteRule> </its:rules> </head> <body> <msg id="DisableInfo">The {0} has been disabled.</msg> </body> </myRes>
[Source file: EX-locNote-element-1.xml]
The locNotePointer locInfoPointer attribute is a relative XPath expression pointing to a node that holds the note.
<Res xmlns:its="http://www.w3.org/2005/11/its" > <prolog> <its:rules its:version="1.0"> <its:translateRule selector="//msg/notes" translate="no"/> <its:locNoteRule locNoteType="description" selector="//msg/data" locNotePointer="../notes"/> </its:rules> </prolog> <body> <msg id="FileNotFound"> <notes>Indicates that the resource file {0} could not be loaded.</notes> <data>Cannot find the file {0}.</data> </msg> <msg id="DivByZero"> <notes>A division by 0 was going to be computed.</notes> <data>Invalid parameter.</data> </msg> </body> </Res>
[Source file: EX-locNotePointer-attribute-1.xml]
The locNoteRule element specifies that the message with the identifier 'NotFound' has a corresponding explanation note in an external file. The URI for the exact location of the note is stored in the locNoteRef attribute.
<myRes xmlns:its="http://www.w3.org/2005/11/its" > <head> <its:rules its:version="1.0"> <its:locNoteRule locNoteType="description" selector="//msg[@id='NotFound']" locNoteRef="ErrorsInfo.html/#NotFound"/> </its:rules> </head> <body> <msg id="NotFound">Cannot find {0} on {1}.</msg> </body> </myRes>
[Source file: EX-locNoteRef-attribute-1.xml]
The locNoteRefPointer locInfoRefPointer attribute contains a relative XPath expression pointing to a node that holds the URI referring to the location of the note.
The locInfoRefPointer attribute<data xmlns:its="http://www.w3.org/2005/11/its" > <prolog> <its:rules its:version="1.0"> <its:locNoteRule locNoteType="description" selector="//data" locNoteRefPointer="../@noteFile"/> </its:rules> </prolog> <body> <string id="FileNotFound" noteFile="Comments.html/#FileNotFound"> <data>Cannot find the file {0}.</data> </string> <string id="DivByZero" noteFile="Comments.html/#DivByZero"> <data>Invalid parameter.</data> </string> </body> </data>
[Source file: EX-locNoteRefPointer-attribute-1.xml]
LOCAL: Thein a following local markup is expressed available forwith the Localizationattributes Note locInfo dataor locInfoRef , category:
Oneand of locInfoType . locInfo the following:
A locInfoRef MUST locNote NOT attribute that contains the note itself.
A locNoteRef locInfoType attribute that contains a URIpresent, referring to the location of the localization note.
Aninformation optional locNoteType be attribute with the value "as description" or "alert". If the locNoteType attributeselection is not present, the typetextual content of localization noteincluding will beelements, but assumedexcluding to be "description". attributes.
<msgList xmlns:its="http://www.w3.org/2005/11/its" xml:space="preserve" its:version="1.0"> <data name="LISTFILTERS_VARIANT" its:locNote="Keep the leading space!" its:locNoteType="alert"> <value> Variant {0} = {1} ({2})</value> </data> <data its:locNote="%1\$s is the original text's date in the format YYYY-MM-DD HH:MM always in GMT"> <value>Translated from English content dated <span id="version-info">%1\$s</span> GMT.</value> </data> </msgList>
[Source file: EX-locNote-selector-2.xml]
Note:
It is generally recommended to avoid using attributes to store text, however, in this specific case, the need to provide the notes without interfering with the structure of the host document is outweighing the drawbacks of using an attribute.
[19] | locNoteRule | ::= |
element its:locNoteRule { locNoteRule.content, locNoteRule.attributes } |
[20] | locNoteRule.content | ::= |
locNote? |
[21] | locNoteRule.attributes | ::= |
att.selector.attributes,
attribute locNotePointer { string }?,
attribute locNoteType { "alert" | "description" },
attribute locNoteRef { xsd:anyURI }?,
attribute locNoteRefPointer { string }? |
[22] | locNote | ::= | element its:locNote { locNote.content, locNote.attributes } |
[23] | locNote.content | ::= | ( text | ruby | span )* |
[24] | locNote.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
[25] | att.locNote.attributes | ::= |
att.locNote.attribute.locNote,
att.locNote.attribute.locNoteType,
att.locNote.attribute.locNoteRef
|
[26] | att.locNote.attribute.locNote | ::= | attribute its:locNote { string }? |
[27] | att.locNote.attribute.locNoteType | ::= |
attribute its:locNoteType { "alert" | "description" }? |
[28] | att.locNote.attribute.locNoteRef | ::= | attribute its:locNoteRef { xsd:anyURI }? |
The Terminologyterminology data category is used to mark terms and optionally associate terms. them with information, such as definitions. This helps to increase consistency across different parts of the documentation. It is also helpful for translation.
Note:
Existing terminology standards such as [ISO 12200] and its derived formats are about coding terminology data, while the ITS Terminology data category simply allows to identify terms in XML documents and optionally to point to corresponding information.
The Terminologyterminology data category can be expressed with global global rules, or locally on an individual element.As There is no inheritance.identifying terminology The default is that neither elements nor attributes are terms.
GLOBAL: Thewith a termRule element contains the following:
A required mandatory selector attribute. It contains an XPathoptional termInfoRef expression which selects the nodesused to which thisto external rule applies.
A required term attribute withabout the value "yes" orThe "no".
Exactly onedatatype of the following:
A termInfoPointer attribute thatxs:anyURI. contains a relative XPath expression pointing to a node that holds the current terminology information.
A termInfoRef document, attribute that contains a URI referring to the resource providing information about the term.
A termInfoRefPointer attribute that contains a relative termInfoRef XPathand termInfoRefPointer MUST NOT expression pointing to a node that holds the URI referring to the location of the terminology information.
together.
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules its:version="1.0"> <its:termRule selector="//term" term="yes" termInfoPointer="id(@def)"/> </its:rules> <p>We may define <term def="TDPV">discoursal point of view</term> as <gloss xml:id="TDPV">the relationship, expressed through discourse structure, between the implied author or some other addresser, and the fiction.</gloss> </p> </text>
[Source file: EX-terms-selector-1.xml]
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules its:version="1.0"> <its:termRule selector="//term[1]" term="yes" termInfoRef="#TDPV"/> </its:rules> <p>We may define <term>discoursal point of view</term> as <gloss xml:id="TDPV">the relationship, expressed through discourse structure, between the implied author or some other addresser, and the fiction.</gloss> </p> </text>
[Source file: EX-terms-selector-2.xml]
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules its:version="1.0"> <its:termRule selector="//term" term="yes" termInfoRefPointer="@target"/> </its:rules> <p>We may define <term target="#TDPV">discoursal point of view</term> as <gloss xml:id="TDPV">the relationship, expressed through discourse structure, between the implied author or some other addresser, and the fiction.</gloss> </p> </text>
[Source file: EX-terms-selector-3.xml]
LOCAL: The following local markupcategory is available for the Terminology data category:
A a term attributeattribute, which with the value "yes", or "no".
Anan optional termInfoRef attribute. attribute that contains a URI referring to the element, including resource providing information aboutelements, but theexcluding term.
attributes.
<book xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <head>...</head> <body> ... <p>And he said: you need a new <quote its:term="yes">motherboard</quote> </p> ... </body> </book>
[Source file: EX-terms-selector-4.xml]
[29] | termRule | ::= | element its:termRule { termRule.content, termRule.attributes } |
[30] | termRule.content | ::= | empty |
[31] | termRule.attributes | ::= |
att.selector.attributes,
attribute term { "yes" | "no" },
attribute termInfoRef { xsd:anyURI }?,
attribute termInfoRefPointer { string }?,
attribute termInfoPointer { string }? |
[32] | att.term.attributes | ::= |
att.term.attribute.termInfoRef, att.term.attribute.term
|
[33] | att.term.attribute.termInfoRef | ::= | attribute its:termInfoRef { xsd:anyURI }? |
[34] | att.term.attribute.term | ::= | attribute its:term { "yes" | "no" }? |
The DirectionalityThis data category allows the user to specify the base writing directiona piece of blocks, embeddings and overrides for the Unicode bidirectional algorithm. It hasare four values: "ltr", "rtl", "lro" and "rlo".
Note:
ITS definesThis definition only the values ofwith the Directionalitydir attribute data category, andexcept that their inheritance. The behaviorallow for of text labelled in this way may vary, according todata the implementation.MUST Implementors are encouraged,XHTML however, to model the behaviorconformance oncritera that described in the CSSspecification.ImplementationThe 2.1 dir specification or its successor. In such a case,for the implementation effect of the directionality data category's values would correspond to has the following CSS rules:
Data categoryvalues value: "ltr" (left-to-right text)
CSS rule: *[dir="ltr"] {, unicode-bidi: embed; direction: ltr}
Data category value: "rtl" (right-to-left text)
CSS rule: *[dir="rtl"] { unicode-bidi: embed; direction: rtl}
Data category value: , "rlo" (left-to-right override)
CSS rule: *[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
Data category value:or "rlo" (right-to-left text)
CSS rule: *[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}
More information about how to use this data category is provided by [Bidi Article].
The Directionality data category can be expressed with global rules, or locally on an individual element.As The information applies to the textual content of the element, including child elements and attributes. The defaultdirectionality is that bothin rules elements and attributes have the directionality ofa left-to-right.
GLOBAL: The dirRule element contains the following:
A required selector dir attribute. It contains an XPath expression which selects the nodes to which this rule applies.
A required dira selector attribute with the value "ltr", "rtl", "lro" oris "rlo".required.
The
dirRule
in element indicates that all elements with
a an
dir
attribute direction="rtlText"
have right-to-left content.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <its:dirRule dir="rtl" selector="//*[@direction='rtlText']"/> </its:rules>
[Source file: EX-dir-selector-2.xml]
LOCAL: attribute. The following local markupselection is available for the Directionalitytextual content data category:
A dir attributeof with the value "ltr",including "rtl",all "lro"child elements or "rlo".attributes.
Onin the first quote
element, the its:dir="rtl"
attribute indicates a right-to-left content.
<text
xmlns:its="http://www.w3.org/2005/11/its" xml:lang="en"
its:version="1.0">
<body>
<par>In Arabic, the title <quote xml:lang="ar"
its:dir="rtl">نشاط التدويل، W3C</quote>
means <quote>Internationalization Activity, W3C</quote>.</par>
</body>
</text>
[Source file: EX-dir-selector-3.xml]
[35] | dirRule | ::= | element its:dirRule { dirRule.content, dirRule.attributes } |
[36] | dirRule.content | ::= | empty |
[37] | dirRule.attributes | ::= |
att.selector.attributes,
attribute dir { "ltr" | "rtl" | "lro" | "rlo" } |
[38] | att.dir.attributes | ::= |
att.dir.attribute.dir
|
[39] | att.dir.attribute.dir | ::= | attribute its:dir { "ltr" | "rtl" | "lro" | "rlo" }? |
The Ruby 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.
The Ruby data category can be expressed withlocally in global rules, or locally.with global There is no inheritance.rules.
GLOBAL: The rubyRule a element contains the following:
Arealized required selectora ruby attribute.element.Ruby It contains an XPath expression[Source which selectsEX-ruby-implementation-1.xml]The the nodes to which this rule applies. Thisfor is the ruby base text.
Anis optional rubyPointer with attribute that containsof ruby a relative XPath expression pointing. to a node thatof corresponds to the ruby element.
Andata optional rpPointer MUST attribute that containsconformance a relative XPathruby expression pointing to a nodein that corresponds to the ruby parenthesis.specification.
An optional rbcPointer of attribute that contains a relative XPath expression pointing to awith ruby node that corresponds to the ruby base container.specification.
An optional rtcPointer attribute that contains a relativeof XPath expression pointing to a nodeexisting that corresponds to the ruby textmarkup is container.
Anrealized optional rbspanPointer various attributepointer thatattributes for containsruby. a relative XPath expression pointing tois a node that corresponds to the rbspan ruby attribute.
Anelement optional rubyText each element that contains the ruby text.content model.
AnHandling optional rtPointer ContentIn attribute that contains a relative XPath expressionthe element pointing to a node that correspondswants to the ruby text.
Antext optional rpPointer to an attribute that contains a relative XPath expressionthe following pointing to a node that corresponds to the ruby parenthesis.used.
Note:
Where legacy formats do not contain ruby markup, it is still possible to associate ruby text with a specified range of document content usingA the rubyRule element.
<text xmlns:its="http://www.w3.org/2005/11/its" > <head> ... <its:rules its:version="1.0"> <its:rubyRule selector="/text/body/img[1]/@alt"> <its:rubyText>World Wide Web Consortium</its:rubyText> </its:rubyRule> </its:rules> </head> <body> <img src="w3c_home.png" alt="W3C"/> ... </body> </text>
[Source file: EX-ruby-legacy-1.xml]
LOCAL:be In a document, the Ruby dataused category is realized with a ruby element. It contains the following:attributes:
An rb element thatattribute contains the ruby base text and allows for local ITS markup.
An rp element that containsin the ruby parenthesis. It is used in case of simple markup to specify characters that can denote the beginning and end of ruby text when user agentsno do not have other ways to present ruby text distinctively from the base text.selections)
An rt element thatattribute contains the ruby text and allows for selector. local ITS markup. It has an optional rbspan base attribute. The rbspan attribute allows an rt element corresponding to span multiplethe rb elements.
An rbc element that containsin the ruby base container.no selection.
An rtc element that contains theAdding ruby text container.
Allwith these elements share the attributes of the rubyRule span element.
<text xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <head> ... </head> <body> <p>この本は <its:ruby> <its:rb>慶応義塾大学</its:rb> <its:rp>(</its:rp> <its:rt>けいおうぎじゅくだいがく</its:rt> <its:rp>)</its:rp> </its:ruby>の歴史を説明するものです。</p> </body> </text>
[Source file: EX-ruby-implementation-1.xml]
Note:
The structure of the content model for the ruby element is identical with the structure of ruby markup as defined in [Ruby-TR]. An implementation of the Ruby data category is encouraged, but not mandated follow the conformance critera for ruby defined in that specification.
The structure of ruby defined in section 5.4 of [OpenDocument] is also compliant with ruby defined in this specification.
[40] | rubyRule | ::= | element its:rubyRule { rubyRule.content, rubyRule.attributes } |
[41] | rubyRule.content | ::= |
rubyText? empty |
[42] | rubyRule.attributes | ::= |
att.selector.attributes,
attribute rubyPointer { string }?,
attribute rtPointer { string }?,
attribute rpPointer { string }?,
attribute rbcPointer { string }?,
attribute rtcPointer { string }?,
attribute rbspanPointer { string }? |
[43] | }?,
attribute rubyText | ::= | element its:rubyText { rubyText.content, rubyText.attributes } |
[44] | rubyText.content | ::= | text |
[45] | rubyText.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes,}?,
attribute rbspan { string }? |
[46] | ruby | ::= | element its:ruby { ruby.content, ruby.attributes } |
[47] | ruby.content | ::= | ( rb, ( rt | ( rp, rt, rp ) ) ) | ( rbc, rtc, rtc? ) |
[48] | ruby.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
[49] | rb | ::= | element its:rb { rb.content, rb.attributes } |
[50] | rb.content | ::= | ( text | span )* |
[51] | rb.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
[52] | rt | ::= | element its:rt { rt.content, rt.attributes } |
[53] | rt.content | ::= | ( text | span )* |
[54] | rt.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes,
attribute rbspan { string }? |
[55] | rbc | ::= | element its:rbc { rbc.content, rbc.attributes } |
[56] | rbc.content | ::= |
rb+ |
[57] | rbc.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
[58] | rtc | ::= | element its:rtc { rtc.content, rtc.attributes } |
[59] | rtc.content | ::= |
rt+ |
[60] | rtc.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
[61] | rp | ::= | element its:rp { rp.content, rp.attributes } |
[62] | rp.content | ::= | text |
[63] | rp.attributes | ::= |
att.translate.attributes,
att.locNote.attributes,
att.term.attributes,
att.dir.attributes
|
The element
langRule
is used to express the languagethat of a given piece of
content. content (selected by The attribute
langPointer
) attribute points to the markup which expresses the
language
information of the text selecteddefined by the selector attribute. This markup MUST use
values that conform to [RFC 4646] or its successor. The recommended way to specify language identification is to use xml:lang
. The
langRule
element is intended only as a fall-back
mechanism for documents where language is identified with another construct.
The following
langRule
element expresses that
the content of all p
elements (including attribute values and
textual content of child elements) are in thea language indicated
conformant to . The value is given by the
mylangattribute
, which is attached to the p
elements,
and expresses language using values conformant to [RFC 4646] or its successor.
elements.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <its:langRule selector="//p" langPointer="@mylangattribute"/> </its:rules>
[Source file: EX-lang-definition-1.xml]
Note:
The Language Information data category only provides for rules to be
expressed at a global level. Locally users are able to use xml:lang
(which is defined by XML) or an attribute
specific to the format in question (as in Example 38).
xml:lang
is the preferable means of language identification. To ease the
usage of xml:lang
, a declaration for this attribute is part of the
non-normative XML DTD and XML Schema document for ITS markup
declarations. There is no declaration of xml:lang
in the non-normative
RELAX NG document for ITS, since in RELAX NG it is not necessary to
declare attributes from the XML namespace.
Applying the Language Information data category to xml:lang
attributes using global rules is not necessary, since xml:lang
is the standard way to specify language information in XML. xml:lang
is defined in terms of RFC 3066 or its successor ([RFC 4646] is the successor to [RFC 3066]).
The Language Information data category can be expressed only with global rules. The information applies to the textual content of the element, including child elements and attributes. There is no default.
GLOBAL: The langRule element contains the following:
A required selector attribute. It contains an XPath expression which selects the nodes to which this rule applies.
A required langPointer attribute that contains a relative XPath expression pointing to a node that contains language information.
[64] | langRule | ::= | element its:langRule { langRule.content, langRule.attributes } |
[65] | langRule.content | ::= | empty |
[66] | langRule.attributes | ::= |
att.selector.attributes, attribute langPointer { string } |
The Elementsdata Within Textelements data category reveals if and how anelements should affect the flow of the content. In element affects the wayflow of text content behavesrepresents how the from a linguistic viewpoint. This information is for example relevant to provide basic text segmentation hints for tools such as translation memory systems. The values associated with this data category are:
"yes" : The(the element and its content are part of the flow of its parent element. For example the element strong
in [XHTML 1.0]:
<strong>Appaloosa horses</strong> have spotted coats.
element)
"nested" : The(the element is part of the flow of its parent element, its content is an independent flow. For example the element fn
in [DITA 1.0]:
Palouse horses<fn>A Palouse horse is the same as an Appaloosa.</fn> have
spotted coats.
flow)
"no" : The(the element splits the text flow of its parent element and its content is an independent text flow. For example the element p
when inside the element li
in DITA or XHTML:flow)
<li>PalouseElements not horses:
<p>Theylisted have spotted coats.</p>
<p>Theyto have been bred by the Nez Perce.</p>
</li>
no.
The Elements Within TextThis data category can be expressed only within a global of rules. ThereIt cannot is no inheritance. The default is thatan individual elementselement.Element are not within text.
GLOBAL:expressed The a withinTextRule element contains the following:
A required selectora withinText attribute. It contains an XPath expression which selects theThe nodes to which this rule applies.
A required withinText attribute with the value "yes", "no" or "nested". In addition, a selector attribute is required.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" its:version="1.0"> <its:withinTextRule withinText="yes" selector="//b | //em | //i"/> </its:rules>
[Source file: EX-within-text-implementation-1.xml]
[67] | withinTextRule | ::= |
element its:withinTextRule
{
withinTextRule.content,
withinTextRule.attributes
} |
[68] | withinTextRule.content | ::= | empty |
[69] | withinTextRule.attributes | ::= |
att.selector.attributes,
attribute withinText { "yes" | "no" | "nested" } |
The following list summarizes elements relating to global rules and their attributes:
<ns> An element to describe namespace URIs and prefixes within XPath expressions in rules elements.
<langRule> Rule about the Language Information data category.
<locNote> Contains a localization note.
<locNoteRule> Rule about the Localization Note data category.
<withinTextRule> Rule about the Elements Within Text data category.
<rubyRule> Rule about the Ruby data category.
Relative XPath expression pointing to a node that corresponds to a ruby
element
Relative XPath expression pointing to a node that
corresponds to a rt
element
Relative XPath expression pointing to a node that
corresponds to a rp
element
Relative XPath expression pointing to a node that
corresponds to a rbc
element
Relative XPath expression pointing to a node that
corresponds to a rtc
element
Relative XPath expression pointing to a node that corresponds to a rbspan attribute.
The following list summarizes elements that are available for local use:
<rbc> Container for rb elements in the case of complex ruby markup.
<rtc> Container for rt elements in the case of complex ruby markup.
Several constraints of ITS markup cannot be validated with ITS schemas. The following [Schematron] document allows for validating some of these constraints.
The following log records major changes that have been made to this document since the publication in November 2005.
A section about basic concepts of ITS has been created.
Terminology has been modified: the terms for position of ITS information in situ versus dislocated have been replaced by selection in an instance document versus global, rule-based selection.
The definition of the Directionalitydirectionality data category has been changed, to be compliant to various other specifications. See the comment on bidirectionality for further information.
Terminology within the text of this document and within the markup declarations has been modified: scope of ITS information has been replaced with selection of ITS information.
The
schemaRules element has been removed. For ITS
information as schema annotation, where is now only aschemaRule
element.
All ITS attributes are now defined as qualified attributes. This leads to changes in the generated ITS schemas, for example the generation of parameter entities for prefixes in the XML DTD. This allows for easy changing of prefixes in element or attribute names.
The possibility of selector attributes in instance documents (in the previous draft this was called scope in an instance document) has been removed. Local selection in an instance document now relies only on default selections of data categories. Due to this change, the definition of precedence between selections and conformance criteria have been simplified, and the issue on namespace requirements and selector values could be resolved.
Definitions of default selections of data categories have been modified.
An ns element has been added to the rules element to allow for specifying namespace bindings.
The implementation of the Rubyruby data category has been modified, to reflect the removal of selector attributes in instance documents.
A section on mapping of ITS data categories to existing markup has been created.
Examples of integrating ITS markup into a TEI schema and into XML Spec have been created.
A span element has been created.
The examples have been modified to reflect changes mentioned above.
For clarity, various sections have been reworded and re-structured, and the visualization of ITS markup within the text of this document has been modified.
Tracking of issues is now handled via Bugzilla.
A revision log has been added.
The following log records major changes that have been made to this document since the publication in February 2006.
The schemaRule
element, and the notion of
schema annotation which was connected to it, have been
abandoned.
The section on conformance has been rewritten and placed at the beginning of the document.
In global rules, the documentRule
element has
been replaced with elements which have data category
specific names. This eases the creation and validation of
global rules.
In global rules, instead of rule specific attributes for selection, there is now just one selector attribute.
In global rules, the documentRules
element
has been renamed to
rules
.
In global rules, in addition to the existing functionality of adding ITS information to selected nodes, a new functionality of pointing to information in an XML document has been created.
An XLink href attribute has been added to the rules element to allow for links to external rules. The precedence between selections has been modified to reflect this change.
Two new data categories Language Information and Elements Within Text have been defined.
The data category Ruby has been redefined, to be conforming to [Ruby-TR].
The declarations for ITS markup have been rewritten, to adopt the changes mentioned above.
The declarations for ITS markup (formally all assembled in a single section) have been separated and placed in the sections there they are described.
A modularization of ITS and XHTML 1.0 has been created.
The informative 1 Introduction and 2 Basic Concepts have been rewritten.
Examples and the modularizations of ITS with existing markup schemes have been changed to reflect the modifications mentioned above.
The following log records major changes that have been made to this document since the publication in April 2006.
The conformance section has been rewritten.
The terminology of mapping ITS data categories with existing markup has been changed to associating ITS Data Categories with existing markup.
The global rule elements have been rewritten to have attributes in the empty namespace.
The examples have been validated, partially modified and extended.
Documentation strings have been added to elements and attributes.
The Elementsdata Within Textelements data categorytext has been redefined.
Clarifications about ITS and inclusion mechanisms and selections of pointers to external (possibly non-textual) objects have been made.
The local attributes have been reorganised into various data category specific groups.
A versioning mechanism has been introduced
A summary of ITS markup has been created.
The automatically generated ITS schemas have been augmented with element and attribute documentations.
A description of ITS markup constraints not covered by the ITS schemas has been created.
The attributes termRef and termRefPointer have been renamed to termInfoRef and termInfoRefPointer .
A list of requirements which are formulated in [ITS REQ], but not covered in this document, has been created. See 1 Introduction.
The following log records major changes that have been made to this document since the publication in May 2006.
In response to issue 3290 (Introduction too "positive" and not enough informative) 1 Introduction has been modified.
In response to issue 3293 (Conformance/Compliance) 4 Conformance has been changed.
In response to issue 3318 (Clarify "within text" data category) the definition of the Elements Within Text data category has been clarified and illustrated with examples.
In response to issue 3321 (Relation of terminology data category to existing standards for terminology) the relation has been described in 6.4.1 Definition.
In response to issue 3323 (Version of XPath: Write "XPath 1.0 or its successor") the reference to [XPath 1.0] has been replaced by a reference to "[XPath 1.0] or its successor".
In response to issue 3330 (lro and rlo explanation) explanations have been modified in 6.5.1 Definition.
In response to issue 3456 (Attribute used for locInfo) a note has been added at the end of 6.3.2 Implementation.
In response to issue 3457 (RFC 3066bis) the references to "RFC 3066bis" been replaced by a reference to "RFC4646 or its successor".
In response to issue 3458 (Default translate value) default values have been made explicit in 6.2.2 Implementation.
In response to issue 3459 (Use of elements) ITS markup is now explicitly allowed inside other ITS markup.
In response to issue 3460 (Loc Info or Loc Note) all attributes and elements starting with locInfo...
have been renamed locNote...
.
In response to issue 3461 (Role of termInfo) 6.4.1 Definition has been clarified.
In response to issue 3462 (Pointing to terms) 6.4.2 Implementation has been clarified.
In response to issue 3463 (termInfoRef should allow for id strings) the termInfoPointer attribute has been added.
In response to issue 3464 (Allowing for xpath expressions to point to term definitions) the termInfoPointer attribute has been added.
In response to issue 3465 (Default is ltr) 6.5.2 Implementation has been clarified.
In response to issue 3466 (Existing ruby markup) 3.5 Usage of Internationalized Resource Identifiers in ITS has been added, the conformance clause 2-2 has been removed, the reference to [Ruby-TR] has been clarified and moved to 6.6.2 Implementation, and the definition of the Directionality data category has been clarified in 6.5.1 Definition.
In response to issue 3467 (rubyText is an attribute) the rubyText
attribute has been changed to the
rubyText
element.
In response to issue 3468 (xml:lang missing) a note at the end of 6.7.1 Definition has been added.
In response to issue 3469 (Example 19 xml:lang) the role of xml:lang
for the language information data category has been clarified in 6.7.1 Definition.
In response to issue 3473 (Language information data category overview) the role of the langRule element has been clarified in 6.7.1 Definition.
In response to issue 3479 (Example 33) Example 38 (which was Example 33) has been modified.
In response to issue 3480 (Language information data category overview) the role of xml:lang
for the language information data category has been clarified in 6.7.1 Definition.
In response to issue 3481 (Translatability) the data category "Translatability" has been renamed to Translate.
In response to issue 3482 (Inheritance of translation information) the role of inheritance of translation information within global rules has been made more explicit in 6.2.2 Implementation.
In response to issue 3487 (Invert translate examples) Example 23 has been modified.
In response to issue 3488 (6.3 ed 1) 6.3.1 Definition has been modified.
In response to issue 3489 (Mention translation tools) a reference to translation tools has been added in 6.3.1 Definition.
In response to issue 3490 (Examples 22 and 23) Example 24 (which was Example 22) and Example 25 (which was example 23) have been modified.
In response to issue 3491 (Explanations for examples) the examples in 6.3.2 Implementation have been clarified.
In response to issue 3492 (Examples 24) Example 26 (which was Example 24) has been modified.
In response to issue 3493 (Marks terms and meanings) the purpose of the terminology data category has been clarified in 6.4.1 Definition.
In response to issue 3494 (termInfoRefPointer referant's data) the explanation of the termInfoRefPointer attribute has been clarified in 6.4.2 Implementation.
In response to issue 3495 (Hard to know what this is about) 6.8 Elements Within Text has been clarified.
In response to issue 3496 (Standardised wording) all subsections in 6 Description of Data Categories have been reworded to be consistent.
In response to issue 3497 (No implementation section) an implementation section (6.7.2 Implementation) has been added for the language information data category.
In response to issue 3498 (Repetition) 6.5.1 Definition has been modified.
In response to issue 3499 (Is dir mandatory?) it has been made explicit that the dir attribute is mandatory at the dirRule element (see 6.5.2 Implementation).
In response to issue 3500 (Avoid xml:lang='he') 5.2.2 Local Selection in an XML Document (especially Example 15) has been modified.
In response to issue 3501 (Some Hebrew quotation) 6.5.2 Implementation has been modified.
In response to issue 3502 (Example 30) Example 33 (which was Example 30) has been modified.
In response to issue 3503 (Refer to bidi article) a reference to [Bidi Article] in 6.5.1 Definition has been added.
In response to issue 3504 (Example 31 lacks rp) Example 37 (which was Example 31) has been modified.
In response to issue 3505 (Use Japanese in Example 31) Example 37 (which was Example 31) has been modified.
In response to issue 3506 (Make the application of legacy ruby clearer) 6.6.2 Implementation has been modified.
In response to issue 3507 (In the case of no selection) 6.6.2 Implementation has been modified.
In response to issue 3508 (Example 32 head) Example 36 (which was Example 32) has been modified.
In response to issue 3509 (Too many places to look) the section 5.1 Summary of ITS Markup has been changed to C Summary of ITS Markup, and 6 Description of Data Categories has been reworded.
In response to issue 3510 (Spell out the attributes) 5.2.1 Global, Rule-based Selection has been modified to list relevant attributes.
In response to issue 3511 (Example 14 translate) Example 15 (which was Example 14) has been modified.
In response to issue 3512 (Example 14 dir) Example 15 (which was Example 14) has been modified.
In response to issue 3513 (ITS markup must be integrated) the optionality of ITS markup in the targeted XML file(s) has been made explicit in 5.5 Associating ITS Data Categories with Existing Markup.
In response to issue 3514 (Attributes missing?) the attributes that are available for local use have been spelled out in C Summary of ITS Markup.
In response to issue 3515 (xml:lang = language info, please) the role of xml:lang
has been clarified in 6.7.1 Definition.
In response to issue 3516 (Editorial comments on ITS) 1 Introduction, 2 Basic Concepts, 3 Notation and Terminology, and 6 Description of Data Categories have been modified.
In response to issue 3612 (Missing term="yes|no" in termRule element) the value "no" has been reinstated for the term attribute.
In response to issue 3640 (Need to handle inheritance for terminology) the description of the inheritance / default / overriding behavior of the data categories has been clarified in 6.1 Position, Defaults, Inheritance and OverridingSelections of Data Categories.
In response to issue 3803 (Both selector and the rbPointer attributes are base text in rubyRule) the rbPointer
has been removed.