1 Introduction
Cette section est informative.
La technologie ITS permet de créer facilement du XML internationalisé, réellement localisable.
D'une part, la spécification ITS identifie des concepts (telle que la « directionnalité », ou sens d'écriture) importants
pour l'internationalisation et la localisation. D'autre part, elle définit les mises en œuvre de ces concepts (désignés par « catégories de données ITS)
comme un ensemble d'éléments et d'attributs appelé le Jeu de balises d'internationalisation (Internationalization Tag Set),
ou jeu ITS. Le document fournit les mises en œuvre pour trois langages de schéma :
XML DTD [XML 1.0],
XML Schema [XML Schema]
et RELAX NG [RELAX NG].
Ce document cherche à réaliser plusieurs idées formulées dans
[Localizable DTDs].
Les exigences de ce document sont formulées dans [ITS REQ].
Les exigences qui y sont listées ne sont pas toutes traitées dans ce docuemnts. Celles qui ne sont pas traitées ici sont abordées dans
[XML i18n BP] ou le seront peut-être dans
une version future de cette spécification.
Ce document couvre les exigences suivantes :
-
R002 : Les éléments de type span,
cf. span
-
R006 : Identification de la langue/lieu,
cf. la section 6.7 Information de langue
-
R007 : Identification des termes,
cf. la section 6.4 Terminologie
-
R008 : Définition/mappage des besoins,
cf. la section 5.5 L'association des catégories de données ITS au balisage existant
-
R011 : Gestion du texte bidirectionnel,
cf. la section 6.5 Directionnalité
-
R012 : Indicateur de traductibilité,
cf. la section 6.2 Traduire
-
R014 : Impact limité,
cf. la section 5.5 L'association des catégorires de données ITS au balisage existant
-
R017 : Notes de localisation,
cf. la section 6.3 Note de localisation
-
R020 : Balisage des annotations,
cf. la section 6.6 Ruby
-
R025 : Éléments et segmentation,
cf. la section 6.8 Éléments dans du texte
Les exigences suivantes seront traitées dans [XML i18n BP]:
Le groupe de travail a décidé de ne pas couvrir les exigences suivantes pour l'instant afin de se concentrer sur les plus importantes :
1.1 La raison d'être du jeu ITS
Le contenu (ou programme) créé dans une langue dite langue source (ou dans un langage dit langage source) est souvent disponible
dans d'autres langues (ou langages) ou bien adapté en rapport à d'autres aspects culturels. Ce processus est appelé localisation,
où la matière originale est traduite et adaptée pour le public cible.
En outre, les formats de documents exprimés par des schémas peuvent être utilisés par des personnes dans différentes parties du monde,
et ces personnes auront peut-être besoin d'un balisage spécial tenant compte de la langue ou de l'écriture locales. Par exemple,
les textes créés en arabe, hébreu, perse ou ourdou nécessitent un balisage spécial pour indiquer le sens d'écriture dans un
texte à directions mélangées (mixed direction text).
Il est important, des points de vue de la faisabilité, du coût et de l'efficacité, que le matériel original soit prêt pour la localisation.
On y parvient avec une conception et un développement appropriés, et on désigne le processus correspondant par le terme d'« internationalisation ».
Pour une explication détaillées des termes « localisation » et « internationalisation », cf. [l10n i18n].
L'utilisation croissante de XML comme médium pour les contenus de type documentation (par exemple, DocBook et DITA comme
formats d'écriture pour des documentations structurées, convenant bien aux manuels des équipements et logiciels informatiques)
et pour les contenus de type programme (par exemple, le langage XUL (Extensible User Interface Language)
[XUL]) crée des défis et des opportunités dans le domaine de
l'internationalisation et de la localisation de XML.
1.1.1 Les problèmes typiques
Les exemples suivants illustrent l'un des blocages actuels pour la localisation efficace d'un contenu de type XML :
l'absence d'un mécanisme déclaratif normalisé identifiant les parties d'un document XML à traduire. Les outils sont souvent
incapables de cette identification automatique.
Document avec un contenu partiellement traduisible
Dans ce document, il est difficile de distinguer les éléments string traduisibles et les éléments qui ne le sont pas.
Seul l'ajout de drapeaux pourrait résoudre le problème.
<resources>
<section id="Homepage">
<arguments>
<string>page</string>
<string>childlist</string>
</arguments>
<variables>
<string>POLICY</string>
<string>Corporate Policy</string>
</variables>
<keyvalue_pairs>
<string>Page</string>
<string>ABC Corporation - Policy Repository</string>
<string>Footer_Last</string>
<string>Pages</string>
<string>bgColor</string>
<string>NavajoWhite</string>
<string>title</string>
<string>List of Available Policies</string>
</keyvalue_pairs>
</section>
</resources>
[Fichier source : EX-motivation-its-1.xml]
Exemple n° 2 : Document avec un contenu partiellement traduisible
Même lorsqu'il y a des métadonnées pour identifier du texte non traduisible, les conditions peuvent en être assez complexes et
non indiquées directement avec un simple drapeau. Ici, par exemple, seul le texte dans les nœuds correspondants à l'expression
//component[@type!='image']/data[@type='text'] est traduisible.
<dialogue xml:lang="en-gb">
<rsrc id="123">
<component id="456" type="image">
<data type="text">images/cancel.gif</data>
<data type="coordinates">12,20,50,14</data>
</component>
<component id="789" type="caption">
<data type="text">Cancel</data>
<data type="coordinates">12,34,50,14</data>
</component>
<component id="792" type="string">
<data type="text">Number of files: </data>
</component>
</rsrc>
</dialogue>
[Fichier source : EX-motivation-its-2.xml]
1.2 Les utilisateurs et les utilisations du jeu ITS
1.2.1 Les utilisateurs potentiels du jeu ITS
La spécification ITS vise à fournir aux différents types d'utilisateurs des informations sur le balisage nécessaire
pour une utilisation mondiale et pour une réelle internationalisation et localisation du contenu. Les paragraphes suivants esquissent ces
différents types d'utilisateurs et leurs utilisations du jeu ITS.
Le développeur de schémas élaborant un schéma depuis le commencement :
Ce type d'utilisateur trouvera des propositions pour les noms d'attributs et d'éléments à inclure dans un nouveau schéma
(un ensemble appelé aussi « vocabulaire hôte »). Il peut être avantageux d'utiliser des noms d'éléments et attributs proposés dans la
spécification ITS car les utilisateurs et processeurs de schémas reconnaîtront peut-être plus facilement les concepts représentés.
Toutefois, un développeur de schémas peut parfaitement créer son propre jeu de noms d'éléments et d'attributs.
L'objet de la spécification est avant tout d'assurer la disponibilité du balisage nécessaire, et que le comportement de ce balisage
corresponde à des besoins établis.
Le développeur de schémas travaillant avec un schéma existant :
Ce type d'utilisateur travaillera avec des schémas tels que DocBook, DITA ou peu-être un schéma propriétaire. Le groupe de travail ITS
a sollicité l'avis d'experts dans le développement de formats largement utilisés comme ceux mentionnés ici.
Remarque :
La question « Comment utiliser le jeu ITS avec les schémas de balisage courants existants ? » est couverte plus en détails
(y compris des exemples) dans un document séparé : [XML i18n BP].
Le développeur travaillant sur un schéma existant devraient vérifier si celui-ci gère le balisage proposé ici dans cette spécification
et l'ajouter au sien là où c'est approprié.
Parfois, le schéma existant contient déjà un balisage équivalent de celui recommandé dans le jeu ITS. Auquel cas,
il ne sera pas nécessaire d'ajouter un balisage en double car ITS offre des mécanismes pour associer le balisage ITS
au balisage dans un vocabulaire hôte ayant une vocation similaire (cf. la section
5.5 L'association de catégories de données ITS au balisage existant).
Néanmoins, le développeur devrait vérifier que le comportement associé au balisage dans son propre schéma est entièrement compatible
aux attentes décrites dans cette spécification.
Le vendeur d'outils en rapport avec le contenu :
Ce type d'utilisateur comprend les sociétés fournissant des outils de création, de traduction, ou d'autres solutions logicielles liées
aux contenus. Il importe de s'assurer que ces outils rendent possible une utilisation mondiale et une localisation réelle du contenu.
Par exemple, les outils de traduction devraient empêcher que le contenu balisé comme étant hors traduction ne soit changé ou traduit.
On espère de la spécification ITS qu'elle rendra la tâche plus facile aux vendeurs en normalisant le format et les
attentes de traitement (processing expectations) de certains éléments pertinents du balisage,
et en leur permettant de déterminer plus efficacement comment traiter le contenu.
-
Les producteurs de contenu :
Ce type d'utilisateur comprend les auteurs, les traducteurs et autres créateurs de contenus.
Le balisage proposé dans cette spécification peut leur servir à marquer des morceaux spécifiques de contenu. En aparté :
on peut soulager le producteur de contenu de la charge d'insérer le balisage en reliant les informations ITS
aux morceaux pertinents de contenu de manière globale (cf. l'approche globale fondée sur des règles).
Toutefois, ce travail global incombera plutôt aux architectes de l'information
qu'aux créateurs de contenus mêmes.
Pour tenir compte de tous ces utilisateurs, les renseignements à propos du balisage à utiliser pour permettre une utilisation mondiale et
une localisation réelle du contenu sont fournis dans cette spécification de deux façons :
1.2.2 Les façons d'utiliser le jeu ITS
La spécification ITS propose plusieurs mécanismes pour soutenir une utilisation mondiale et une réelle internationalisation
et localisation du contenu. Nous les esquisserons ci-dessous en les observant des points de vues de certains types d'utilisateurs.
Pour les besoins de l'illustration, nous démontrerons comment le jeu ITS peut indiquer que certaines parties du contenu
sont à traduire ou non.
Exemple n° 3 : Utilisation du jeu ITS par un créateur de contenus
Les attributs its:translate="no" indiquent de ne pas traduire les éléments path et cmd.
<help
xmlns:its="http://www.w3.org/2005/11/its"
its:version="1.0">
<head>
<title>Building the Zebulon Toolkit</title>
</head>
<body>
<p>To re-compile all the modules of the Zebulon toolkit you need to go in the
<path
its:translate="no">\Zebulon\Current Source\binary</path> directory.
Then from there, run batch file <cmd
its:translate="no">Build.bat</cmd>.</p>
</body>
</help>
[Fichier source : EX-ways-to-use-its-1.xml]
Exemple n° 4 : Utilisation du jeu ITS par un architecte de l'information
L'élément translateRule dans l'en-tête du document sert à indiquer
de ne pas traduire les éléments path ou cmd.
<help
xmlns:its="http://www.w3.org/2005/11/its"
its:version="1.0">
<head>
<title>Building the Zebulon Toolkit</title>
<its:rules version="1.0">
<its:translateRule selector="//path | //cmd" translate="no"/>
</its:rules>
</head>
<body>
<p>To re-compile all the modules of the Zebulon toolkit you need to go in the
<path>\Zebulon\Current Source\binary</path> directory.
Then from there, run batch file <cmd>Build.bat</cmd>.</p>
</body>
</help>
[Fichier source : EX-ways-to-use-its-2.xml]
Exemple n° 5 : Utilisation du jeu ITS par un processeur
Un élément rules est inséré dans l'en-tête du document. Il a un
attribut XLink href servant à lier un document
de règles ITS externe.
<help
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xlink="http://www.w3.org/1999/xlink"
its:version="1.0">
<head>
<title>Building the Zebulon Toolkit</title>
<its:rules version="1.0" xlink:href="EX-ways-to-use-its-4.xml" xlink:type="simple"/>
</head>
<body>
<p>To re-compile all the modules of the Zebulon toolkit you need to go in the
<path>\Zebulon\Current Source\binary</path> directory.
Then from there, run batch file <cmd>Build.bat</cmd>.</p>
</body>
</help>
[Fichier source : EX-ways-to-use-its-3.xml]
Exemple n° 7 : Un schéma XSD avec une déclaration ITS
La déclaration de l'attribut translate est ajoutée
Les déclarations de l'attribut translate sont ajoutées
à un groupe d'attributs communs commonAtts. Cela permet d'utiliser l'attribut translate
dans les documents comme dans l'exemple n° 3.
<xs:schema
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/2005/11/its" schemaLocation="its.xsd"/>
<xs:attributeGroup name="commonAtts">
<xs:attributeGroup ref="its:att.local.with-ns.attribute.translate"/>
<xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:attributeGroup>
<xs:element name="help">
<xs:complexType>
<xs:sequence>
<xs:element name="head">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
</xs:sequence>
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
<xs:element name="body">
<xs:complexType>
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="p">
<xs:complexType mixed="true">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="path"/>
<xs:element ref="cmd"/>
</xs:choice>
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attributeGroup ref="its:att.version.attribute.version"/>
</xs:complexType>
</xs:element>
<xs:element name="path">
<xs:complexType mixed="true">
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
<xs:element name="cmd">
<xs:complexType mixed="true">
<xs:attributeGroup ref="commonAtts"/>
</xs:complexType>
</xs:element>
</xs:schema>
[Fichier source : EX-ways-to-use-its-5.xsd]
Les deux premières approches précédentes peuvent être comparées à l'utilisation de CSS dans
[XHTML 1.0].
Avec un attribut style, un créateur de contenu XHTML peut assigner une couleur à un paragraphe particulier.
L'auteur aurait pu utiliser l'élément style au début de la page pour déclarer que tous les paragraphes d'une classe particulière
ou dans un contexte particulier aient une couleur rouge.
1.3 Hors cadre
Ce standard ne couvre pas tous les mécanismes et formats de données (parfois appelées propriétés de localisation),
qui seraient nécessaires à la configuration des flux de production (workflows) ou des outils de localisation
pour traiter un format spécifique. En revanche, ces mécanismes et formats de données peuvent être mis en œuvre en utilisant le
cadre d'applications (framework) décrit dans ce standard.
Remarque :
Les « propriétés de localisation XML » sont un terme générique pour désigner les mécanismes et formats de données permettant
la configuration d'outils de localisation pour traiter un format XML. Des exemples de « propriétés de localisation XML »
sont les fichiers « DTD Settings » Trados et « Analysis » SDLX.
1.4 Les principes de conception importants
Abstraction via des catégories de données : ITS définit les catégories de données comme une notion abstraite
d'informations pour l'internationalisation et la localisation de schémas XML et de documents. Cette abstraction aide à réaliser
une indépendance par rapport à une mise en œuvre particulière en utilisant, par exemple, un élément ou un attribut.
Cf. la section 3.3 La catégorie de données pour une définition du terme « catégorie de données »,
la section 6 La description des catégories de données pour la définition des
diverses catégories de données ITS et les sous-sections dans
6 La description des catégories de données pour leurs mises en œuvre.
Un mécanisme de sélection puissant : Pour le balisage ITS qui apparaît dans une instance XML,
il faut que les nœuds XML auxquels se rapportent les informations ITS soient clairement identifiés. ITS
définit donc des mécanismes de sélection pour indiquer à quelles parties d'un document XML
appliquer une catégorie de données et ses valeurs. La sélection repose sur les données contenues dans
l'ensemble d'information XML [XML Infoset].
Les applications ITS peuvent mettre en œuvre des mécanismes d'inclusion tels que XInclude ou l'attribut conref
du langage DITA [DITA 1.0].
Par exemple, les créateurs de contenus ont besoin d'une méthode simple pour travailler avec la catégorie de données
Traduire, afin d'exprimer s'il faut traduire ou non le contenu d'un élément ou d'un attribut.
À l'inverse, les coordinateurs de localisation ont besoin d'une méthode efficace de gestion des traductions de grands ensembles documentaires
fondés sur le même schéma. On pourrait concilier ces points de vue en définissant des valeurs par défaut (defaults)
pour la catégorie de données Traduire et des exceptions d'après les valeurs par défaut (par exemple,
il faudrait traduire tous les éléments p mais pas ceux dans un élément index).
Pour satisfaire à ces exigences, cette spécification introduit des mécanismes qui ajoutent de l'information ITS aux
documents XML, cf. la section 5 Le traitement de l'information ITS.
Ces mécanismes permettent aussi de définir des informations ITS pour les attributs (une tâche pour laquelle il n'y a encore
aucun moyen normalisé).
Les mécanismes de sélection ITS permettent de fournir des informations à propos d'un contenu,
localement (définition sur le nœud XML auquel le contenu appartient)
ou globalement (définition ailleurs dans le document). Les mécanismes de sélection globale peuvent se trouver
dans le même document ou dans un fichier séparé.
Pas d'extensibilité réservée : Il peut être utile ou nécessaire d'étendre l'ensemble d'informations disponible pour
les besoins de l'internationalisation ou de la localisation, au-delà de celui fourni par le jeu ITS. Cette spécification
ne définit pas de mécanisme d'extension réservé (dedicated extension mechanism) puisque les mécanismes XML
ordinaires (par exemple, les espaces de noms XML [XML Names])
sont utilisables.
Facilité d'intégration :
-
ITS suit l'exemple de la section 4
de la spécification [XLink 1.0], en fournissant principalement des
attributs globaux pour la mise en œuvre des catégories de données ITS. Éviter autant que possible les éléments pour les
besoins ITS assure une facilité d'intégration aux schémas de balisage existants, cf. la
section 3.14 dans
[ITS REQ]. On utilise des
sous-éléments supplémentaires seulement pour quelques exigences, cf. par exemple la section
6.6 Ruby.
-
ITS ne dépend pas de technologies dont le développement est toujours en cours.
-
ITS cadre avec les travaux actuels dans l'architecture du W3C
(par exemple, l'utilisation de [XPath 1.0] pour le
mécanisme de sélection).
1.5 Le développement de cette spécification
Cette spécification a été développée dans le format ODD (N.d.T. One Document Does it all))
de l'initiative TEI (Text Encoding Initiative)
[TEI]. Il s'agit d'un
langage de programmation lettré (literate programming language) pour l'écriture de schémas XML,
qui a trois caractéristiques :
-
L'ensemble d'éléments et attributs est défini avec un vocabulaire XML qui inclut une gestion de macrocommandes
(comme les entités des définitions DTD ou les motifs de schémas (schema patterns)),
un système de classes hiérarchiques pour les éléments et attributs, et une création de modules.
-
Les modèles de contenus des éléments et attributs sont écrits en utilisant une notation incorporée XML RELAX NG.
-
La documentation des éléments, attributs, listes de valeurs, etc. est écrite dans la ligne (inline),
en même temps que des exemples et d'autres documents de soutien.
L'initiative TEI fournit des transformations XSLT pour créer une documentation dans les formes HTML,
XSL FO ou LaTeX, et pour générer des documents RELAX NG et une définition DTD. À partir de
documents RELAX NG, on peut utiliser le convertisseur trang
de James Clark pour créer des documents XML Schema.
2 Les concepts de base
Cette section est informative.
2.1 La sélection
L'information (par exemple, « traduire ceci ») saisie par le balisage ITS (par exemple, its:translate='yes')
se rapporte toujours à un ou plusieurs nœuds XML (principalement des nœuds d'éléments et d'attributs). Dans un sens,
le balisage ITS « sélectionne » le(s) nœud(s) XML. La sélection peut être explicite ou implicite.
ITS distingue deux approches de sélection : l'une locale et l'autre globale fondée sur des règles.
Les mécanismes définis pour la sélection ITS ressemblent à ceux définis dans
[CSS 2.1].
L'approche locale est comparable à celle de l'attribut style dans HTML/XHTML, et l'approche avec des
règles globales à celle de l'élément style dans HTML/XHTML. Par contraste avec CSS,
ITS utilise XPath pour identifier les nœuds, par conséquent :
-
L'approche locale place le balisage ITS dans l'élément pertinent du vocabulaire hôte
(par exemple, l'élément author dans DocBook)
-
L'approche globale fondée sur des règles place le balisage ITS dans des éléments définis par
ITS même (à savoir, l'élément rules)
Le balisage ITS peut être utilisé avec des documents XML (par exemple, un article DocBook) ou des schémas
(par exemple, le document XML Schema d'un format de document propriétaire). Puisque chaque utilisation définit des
exigences spécifiques, le balisage ITS peut prendre des formes différentes.
Les deux exemples suivants illustrent la distinction entre les approches locales et globales.
2.1.1 L'approche locale
Le document dans l'exemple n° 8 montre comment un créateur de contenus peut utiliser
l'attribut ITS translate pour indiquer que tout le contenu
de l'élément author devrait être écarté de la traduction. Les outils de traduction comprenant la signification de cet attribut
peuvent alors passer le contenu pertinent au crible exclure le contenu pertinent du processus de traduction.
Exemple n° 8 : Balisage ITS sur des éléments dans un document XML (approche locale)
<dbk:article
xmlns:its="http://www.w3.org/2005/11/its"
xmlns:dbk="http://docbook.org/ns/docbook"
its:version="1.0" version="5.0" xml:lang="en">
<dbk:info>
<dbk:title>An example article</dbk:title>
<dbk:author
its:translate="no">
<dbk:personname>
<dbk:firstname>John</dbk:firstname>
<dbk:surname>Doe</dbk:surname>
</dbk:personname>
<dbk:affiliation>
<dbk:address>
<dbk:email>foo@example.com</dbk:email>
</dbk:address>
</dbk:affiliation>
</dbk:author>
</dbk:info>
<dbk:para>This is a short article.</dbk:para>
</dbk:article>
[Fichier source : EX-basic-concepts-1.xml]
Pour un bon fonctionnement, le développeur du schéma aura besoin d'ajouter
l'attribut translate au schéma comme attribut commun sur toutes les
définitions d'éléments pertinentes. Notez, dans ce cas, l'attente quant à la part de l'héritage dans l'identification du contenu à traduire
ou non. Les outils traitant ce contenu pour traduction devront mettre en œuvre le comportement d'héritage attendu.
2.1.2 L'approche globale
Le document dans l'exemple n° 9 montre une approche différente pour identifier un contenu non traduisible,
similaire à celle utilisée avec l'élément style dans [XHTML 1.0],
mais en utilisant un élément défini par ITS appelé rules. Il agit comme suit :
un document peut contenir un élément rules (placé là où il n'affecte pas la structure du document,
comme dans la section « head »). Il contient un ou plusieurs éléments de règles (par exemple
translateRule). Chacun de ces éléments spécifiques contient un
attribut selector. Comme suggéré par son nom, cet attribut sélectionne le
nœud (ou les nœuds) XML dont dépend une information ITS correspondante. Les valeurs des attributs ITS
selector sont des chemins d'emplacements absolus XPath. L'information de traitement des espaces de noms
dans ces expressions de chemins est prélevée dans les déclarations d'espaces de noms
[XML Names] de l'élément rules courant.
Remarque :
Mise en garde relative au traitement de type XSLT des attributs ITS selector
Les valeurs des attributs ITS selector sont
des chemins d'emplacements absolus XPath. Par conséquent, la valeur suivante est légitime :
myElement/descendant-or-self::*/@*
Malheureusement, les valeurs comme celle-ci posent problèmes lorsqu'elles sont utilisées dans un traitement de type XSLT
d'un code ITS où les valeurs des attributs ITS selector
sont utilisées comme valeurs des attributs match des gabarits XSLT (XSLT templates).
La raison en est la suivante : les attributs match peuvent seulement contenir une restriction/un sous-ensemble
des expressions XPath, dit motifs (patterns).
Pour l'essentiel, voici les restrictions associées aux motifs :
L'utilisation de motifs XSLT uniquement dans les attributs ITS selector
permet d'éviter ce problème. Dans beaucoup de cas, cela est possible en utilisant des motifs avec des prédicats. Par exemple, on peut récrire
la valeur précédente ainsi :
*[self::myElement]/@* | myElement//*/@*
Exemple n° 9 : Balisage ITS global dans un document XML (approche fondée sur des règles)
<myTopic
xmlns:its="http://www.w3.org/2005/11/its"
xmlns="myNamescapeURI" id="topic01" xml:lang="en-us">
<prolog>
<title>Using ITS</title>
<its:rules version="1.0">
<its:translateRule selector="//n:term" selector="//term" translate="no"/>
</its:rules>
</prolog>
<body>
<p>ITS defines <term>data category</term> as an abstract
concept for a particular type of information for
internationalization and localization of XML schemas and
documents.</p>
</body>
</myTopic>
[Fichier source : EX-basic-concepts-2.xml]
Pour le bon fonctionnement de cette approche, le développeur du schéma doit ajouter
l'élément rules et le balisage associé au schéma.
Dans certains cas, cela permet au développeur du schéma d'éviter l'ajout d'un autre balisage ITS
(tel qu'un attribut translate) aux éléments du schéma. Toujours est-il,
les auteurs utiliseront vraisemblablement des attributs sur le balisage, à l'occasion, pour déroger (override) à la règle générale.
Pour la spécification de l'information de la catégorie de données Traduire, le contenu de
l'élément rules sera normalement conçu par un architecte de l'information familier du format de document
et familier (ou collaborant avec une personne familière) des besoins du groupe de localisation.
L'approche globale fondée sur des règles présente les avantages suivants :
-
Les créateurs de contenus n'ont pas à se préoccuper de créer du balisage supplémentaire ou de vérifier la bonne application du balisage.
Les catégories de données ITS sont associées à des ensembles de nœuds XML (par exemple, tous les
éléments p d'une instance XML).
-
Les changements peuvent être effectués dans un seul endroit (si l'élément rules est stocké comme entité externe),
au lieu de rechercher et modifier le balisage à travers un (ou plusieurs) document.
-
Les catégories de données ITS peuvent désigner des valeurs d'attributs aussi bien que des éléments.
-
Il est possible d'associer le balisage ITS à un balisage existant (par exemple, l'élément term dans DITA).
Le point commun aux deux exemples précédents est le balisage translate='no'. Ce bout de balisage ITS peut
s'interpréter comme suit :
L'attribut ITS selector permet :
-
Aux attributs des catégories de données ITS d'apparaître dans des règles globales (même en dehors d'un document ou schéma XML) ;
-
Aux attributs des catégories de données ITS de se rapporter à des ensembles de nœuds XML (par exemple,
tous les éléments p dans un document XML) ;
-
Au balisage ITS de se rapporter à des attributs ;
-
Au balisage ITS de s'associer à un balisage existant (par exemple,
l'élément term dans DITA).
2.2 La prédominance et l'héritage
La puissance des mécanismes de sélection ITS a un prix : il faut établir des règles de
prédominance/priorité (overriding/precedence) et
d'héritage (inheritance).
Le document dans l'exemple n° 10 montre le fonctionnement de l'héritage et de la prédominance
pour la catégorie de données Traduire. Par défaut, les éléments sont traduisibles.
L'élément translateRule déclaré ici dans l'en-tête écrase le comportement par défaut de
l'élément head dans l'élément text et de tous ses sous-éléments (children). Puisque
l'élément title est en fait traduisible, la règle générale doit être écrasée par une déclaration locale its:translate="yes".
Notez que la règle globale est traitée d'abord, indépendemment de sa position dans le document. Dans le corps principal du document,
c'est le comportement par défaut qui s'applique, et on utilise ici its:translate="no" pour établir
que « faux pas » n'est pas traduisible.
Exemple n° 10 : Prédominance et héritage
<text
xmlns:its="http://www.w3.org/2005/11/its" >
<head>
<revision>Sep-10-2006 v5</revision>
<author>Ealasaidh McIan</author>
<contact>ealasaidh@hogw.ac.uk</contact>
<title
its:translate="yes">The Origins of Modern Novel</title>
<its:rules version="1.0">
<its:translateRule translate="no" selector="/text/head"/>
</its:rules>
</head>
<body>
<div xml:id="intro">
<head>Introduction</head>
<p>It would certainly be quite a <span
its:translate="no">faux pas</span>
to start a dissertation on the origin of modern novel without
mentioning the <tl>Epic of Gilgamesh</tl>...</p>
</div>
</body>
</text>
[Fichier source : EX-basic-concepts-3.xml]
2.3 Ajouter de l'information ou pointer vers de l'information existante
Pour certaines catégories de données, des attributs spéciaux ajoutent ou pointent vers de l'information pour les nœuds sélectionnés.
Par exemple, la catégorie de données Note de localisation peut ajouter de l'information aux nœuds sélectionnés
(en utilisant un élément locNote) ou pointer vers de l'information existante ailleurs dans le document
(en utilisant un attribut locNotePointer).
La fonctionnalité d'ajout d'information aux nœuds sélectionnés est disponible pour toutes les catégories de données,
sauf Information de langue. Le pointage vers de l'information existante n'est pas possible pour les
catégories de données exprimant un ensemble fermé de valeurs, c'est-à-dire les catégories de données Traduire,
Directionnalité et Éléments dans du texte.
Les fonctionnalités d'ajout d'information et de pointage vers de l'information existante sont mutuellement exclusives.
C'est-à-dire que des attributs de pointage et d'ajout ne doivent pas apparaître dans le même élément rules.
3 La notation et la terminologie
Cette section est normative.
3.1 Notation
Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS »,
« RECOMMANDÉ », « PEUT » et « OPTIONNEL » dans ce document doivent s'interpréter comme décrit dans [RFC 2119].
L'adresse URI d'espace de noms qui DOIT être utilisée par les mises en œuvre de cette spécification
est la suivante :
http://www.w3.org/2005/11/its
Le préfixe d'espace de noms utilisé dans cette spécification pour cette adresse URI est « its ». Il est recommandé aux
mises en œuvre de cette spécification d'utiliser ce préfixe.
En outre, ce document utilise les espaces de noms suivants :
-
http://www.w3.org/2001/XMLSchema : pour l'espace de noms XML Schema, utilisé ici avec le préfixe « xs » ;
-
http://relaxng.org/ns/structure/1.0 : pour l'espace de noms RELAX NG, utilisé ici avec le préfixe « rng » ;
-
http://www.w3.org/1999/xlink : pour l'espace de noms XLink, utilisé ici avec le préfixe « xlink ».
3.2 Le langage de schéma
[Définition : Dans cette spécification, le terme langage de schéma
(schema language) désigne un langage de modélisation ou de validation de type XML tels que XML DTD, XML Schema
ou RELAX NG.]
Remarque :
Cette spécification fournit des schémas dans les formats XML DTD, XML Schema ou RELAX NG.
Toutefois, ces schémas ne sont pas normatifs : la conformité des déclarations de balisage ITS
définit uniquement les positions obligatoires des déclarations ITS dans les schémas. Cela permet d'utiliser ITS
avec tout langage de schéma autorisant l'utilisation de ces positions.
3.3 La catégorie de données
[Définition : ITS définit une catégorie de données
(data category) comme un concept abstrait de type particulier d'information pour l'internationalisation et la localisation des
schémas et documents XML]. Le concept de catégorie de données est indépendant de sa mise en œuvre dans un environnement XML
(par exemple, en utilisant un élément ou un attribut).
Pour chaque catégorie de données, ITS distingue les aspects suivants :
Exemple n° 11 : Une catégorie de données et sa mise en œuvre
La catégorie de données Traduire exprime une information quant à un morceau de contenu
qu'il faudrait traduire ou non.
La formalisation la plus simple de cette description à un niveau indépendant du langage de schéma est un
attribut translate avec deux valeurs possibles : "yes"
ou "no". Une mise en œuvre à un niveau spécifique du langage de schéma serait celle de la déclaration de
l'attribut translate, par exemple, dans une définition DTD XML,
un document XML Schema ou un document RELAX NG. Une autre mise en œuvre serait celle d'un
élément translateRule permettant de définir des règles globales
à propos de la catégorie de données Traduire.
3.4 La sélection
[Définition : La sélection
comprend les mécanismes pour indiquer à quelles parties d'un document XML appliquer une catégorie de données ITS
et ses valeurs]. La sélection est abordée en détails dans la section 5 Le traitement de l'information ITS.
La sélection peut s'appliquer globalement, cf. la section 5.2.1 La sélection globale avec des règles,
et localement, cf. la section 5.2.2 La sélection locale dans un document XML.
Comme pour la sélection globale, on peut ajouter de l'information ITS aux nœuds sélectionnés,
ou pointer vers de l'information existante reliée aux nœuds sélectionnés.
La sélection repose sur les données fournies par l'ensemble d'information XML
[XML Infoset]. Les applications ITS
PEUVENT mettre en œuvre des mécanismes d'inclusion tels que XInclude ou
l'attribut conref de DITA [DITA 1.0].
Remarque :
La sélection des catégories de données ITS s'applique aux valeurs textuelles contenues dans les
nœuds d'éléments ou d'attributs. Dans certains cas, ces nœuds forment des pointeurs vers d'autres ressources ; un exemple bien connu est
l'attribut src sur l'élément img dans HTML. La catégorie de données ITS
Traduire s'applique au texte du pointeur même, pas à l'objet sur lequel il pointe. Ainsi, dans l'exemple suivant,
l'information de traduction définie via l'élément translateRule s'applique au nom de fichier
« instructions.jpg », ce n'est pas une instruction pour ouvrir le graphique et y changer les mots trouvés.
3.5 L'utilisation d'identificateurs de ressources internationalisés dans ITS
Les attributs href, locNoteRef
et termInfoRef qui contiennent des identificateurs de ressources DOIVENT permettre
l'utilisation d'identificateurs de ressources internationalisés (IRI)
[RFC 3987] ou ses successeurs, pour faciliter
l'adoption du jeu ITS dans les scénarios d'application internationaux.
Remarque :
Les schémas ITS dans l'annexe D Les schémas ITS
ne sont pas normatifs. Cette spécification ne définit donc aucune exigence de validation pour les valeurs IRI dans le
balisage ITS. Pour le traitement de ces valeurs, miser sur des adresses IRI n'impose aucune condition spécifique.
La raison en est que le traitement intervient au niveau de l'ensemble d'information (info set level)
[XML Infoset], où il n'existe aucune différence entre les
adresses IRI et URI.
4 La conformité
Cette section est normative.
Le terme clause de conformité dans cette section est employé conformément à la spécification
[QAFRAMEWORK].
Cette spécification définit deux types de conformité : la conformité des
déclarations de balisage ITS et la conformité des
attentes de traitement du balisage ITS. Ces types de conformité
se complètent l'un et l'autre. Une mise en œuvre de cette spécification PEUT les utiliser séparément ou ensemble.
4.1 La conformité de type 1 : Les déclarations de balisage ITS
Description : Les déclarations de balisage ITS englobent toutes les déclarations qui font partie du
jeu ITS. Elles ne concernent pas l'utilisation du balisage dans les documents XML. Ce balisage est soumis
aux clauses de conformité dans la section 4.2 La conformité de type 2 : Les attentes de traitement du balisage ITS.
Définitions liées à ce type de conformité : Les déclarations de balisage ITS sont définies dans diverses
sous-sections des sections 5 Le traitement de l'information ITS
et 6 La description des catégories de données
(par exemple, la section 6.3.3 Les déclarations de balisage pour la catégorie Note de localisation)
d'une façon indépendante du langage de schéma, en s'appuyant sur le langage ODD. Dans les autres sections de ce document,
elles apparaissent en caractères gras colorés.
Utilisateurs de ce type de conformité : Les concepteurs de schémas intégrant des déclarations de balisage ITS
dans un schéma. Toutes les clauses de conformité pour ce type de conformité concernent la position des déclarations de balisage ITS
dans ce schéma et leur statut, obligatoire ou optionnel.
Clauses de conformité :
1-1 : Au moins un des éléments suivants DOIT se trouver dans le schéma :
-
1-2 : Si l'élément rules est utilisé,
il DOIT faire partie du modèle de contenu d'au moins un élément dans le schéma.
Il DEVRAIT se trouver dans un modèle de contenu de métainformation, si disponible dans ce schéma (par exemple,
l'élément head dans [XHTML 1.0]).
1-3 : Si l'élément ruby est utilisé,
il DEVRAIT être déclaré comme élément de type en-ligne (inline element).
1-4 : Si l'élément span est utilisé,
il DEVRAIT être déclaré comme élément de type en-ligne.
Les mises en œuvre complètes de ce type de conformité utiliseront toutes les déclarations de balisage ITS.
Les déclarations liées à ce type de conformité DOIVENT lister toutes les déclarations de balisage qu'elles
mettent en œuvre.
Exemples : On donne des exemples d'utilisation de déclarations de balisage ITS dans divers schémas existants
dans un document séparé [XML i18n BP].
Remarque :
Puisque les déclarations de balisage ITS sont indépendantes du langage de schéma, chaque langage de schéma peut utiliser
son propre voire ses multiples mécanismes pour mettre en œuvre les clauses de conformité pour les déclarations de balisage ITS.
Par exemple, une définition DTD XML peut utiliser des entités paramètres pour encapsuler les
attributs locaux ITS, ou les déclarer directement pour chaque élément. Les étapes appropriées
pour intégrer ITS dans un schéma dépendent de la conception du schéma en question (par exemple, s'il a déjà une
couche de personnalisation (customization layer) utilisant des entités paramètres). Les schémas ITS
dans les formats XML DTD, XML Schema et RELAX NG dans
l'annexe D Les schémas ITS ne sont que des exemples informatifs.
4.2 La conformité de type 2 : Les attentes de traitement du balisage ITS
Description : Les processeurs ont besoin de traiter l'information ITS qui se rapporte à un document XML.
Les attentes de traitement ITS définissent comment effectuer le calcul. Le calcul correct implique une gestion du
mécanisme de sélection, des caractéristiques par défaut/d'héritage/de prédominance (overriding)
et de la priorité (precedence). Le balisage PEUT
être valide vis-à-vis d'un schéma conforme aux clauses dans la section 4.1 La conformité de type 1 : Les déclarations de balisage ITS.
Définitions liées à ce type de conformité : Les attentes de traitement du balisage ITS utilisent les mécanismes de sélection
définis dans la section 5 Le traitement de l'information ITS.
Les catégories de données individuelles définies dans la section 6 La description des catégories de données
ont des caractéristiques par défaut/d'héritage/de prédominance, et elles autorisent l'utilisation
du balisage ITS à des positions différentes (globales et locales).
Utilisateurs de ce type de conformité : Les applications qui ont besoin de traiter les nœuds saisis par une catégorie de données
pour internationalisation ou localisation. Comme exemples de ce type d'application : les éditeurs reconnaissant le balisage ITS
ou les outils de traduction utilisant le balisage ITS pour filtrer le texte traduisible en entrée du processus de localisation.
Remarque :
Le traitement spécifique d'une application (c'est-à-dire un processus au-delà du calcul de l'information ITS d'un nœud)
tels que le filtrage automatique du contenu traduisible fondé sur la catégorie de données Traduire
n'est pas couvert par les clauses de conformité ci-dessous.
Remarque :
Le groupe de travail ITS fournit un jeu d'essais
pour aider les développeurs à écrire des applications utilisant les spécifications ITS. Le jeu d'essais comporte
des couples de fichiers d'entrée et sortie.
Clauses de conformité :
-
2-1 : Un processeur DOIT mettre en œuvre au moins une
catégorie de données. Pour chaque catégorie de données mise en œuvre,
les aspects suivants DOIVENT être pris en compte :
-
2-2 : Si une application prétend traiter le balisage ITS d'un mécanisme de sélection globale,
elle DOIT traiter l'attribut XLink href
trouvé sur les éléments l'élément rules ;
Les déclarations liées à ce type de conformité DOIVENT lister
toutes les catégories de données qu'elles mettent en œuvre et, pour chaque catégorie de données,
quels types de sélection elles gèrent.
5 Le traitement de l'information ITS
Cette section est normative.
5.1 L'indication de version ITS
La version du schéma ITS défini dans cette spécification est "1.0". La version est indiquée par l'attribut ITS
version. Cet attribut est obligatoire pour l'élément
rules, où il DOIT être dans aucun espace de noms.
S'il n'y a pas d'élément rules dans un document XML, un attribut ITS
version préfixé (par exemple, its:version)
DOIT être fourni à l'élément racine du document. Si dans un document il y a à la fois un
attribut version à l'élément racine et un
élément rules, ils NE DOIVENT PAS indiquer des versions différentes.
Chaque document XML peut avoir une version différente. C'est-à-dire que si des règles externes sont reliées via un
attribut XLink href sur l'élément rules,
elles peuvent indiquer une version différente de celle de l'élément rules.
5.2 Les emplacements des catégories de données
Les catégories de données ITS peuvent apparaître en deux endroits :
Les deux endroits sont décrits en détails ci-dessous.
5.2.1 La sélection globale avec des règles
La sélection globale avec des règles est mise en œuvre en utilisant l'élément rules.
Celui-ci contient zéro à plusieurs éléments de règles. Chaque élément de règle
a un attribut selector obligatoire. Cet attribut et tous les autres
attributs possibles des éléments de règles sont dans l'espace de noms vide (empty namespace)
et sont utilisés sans préfixe.
S'il y a plusieurs éléments rules dans un document XML, les règles de chaque section
doivent être traitées au même niveau de priorité. Les sections rules se lisent
dans l'ordre du document, et leurs règles ITS se traitent successivement. Les versions de ces
éléments rules NE DOIVENT PAS être différentes.
Selon la catégorie de données et son utilisation, d'autres attributs permettent d'ajouter de l'information
aux nœuds sélectionnés ou de pointer vers de l'information existante dans le document. Par exemple, on peut utiliser la catégorie de données
Note de localisation pour ajouter des notes aux nœuds sélectionnés ou pour pointer vers des notes existantes dans
le document. Dans le premier cas, on pourra utiliser un élément locNote, dans le dernier cas,
un attribut locNotePointer.
Chaque catégorie de données permet d'ajouter de l'information aux nœuds sélectionnés, sauf la catégorie de données
Information de langue. Il n'est pas possible pour les catégories de données exprimant un
ensemble fermé de valeurs de pointer vers de l'information existante, à savoir Traduire,
Directionnalité et Éléments dans du texte.
Les fonctionnalités d'ajout d'information et de pointage vers de l'information existante sont mutuellement exclusives.
C'est-à-dire qu'il NE DOIT PAS apparaître de balisage pour pointer et ajouter dans le même élément de règle.
Une autre différence entre l'ajout et le pointage est dans l'utilisation de XPath :
-
La valeur de l'attribut selector DOIT être
une expression XPath commençant par un caractère « / ». C'est-à-dire qu'elle doit être de type
AbsoluteLocationPath comme décrit dans [XPath 1.0]
ou ses successeurs. Cela garantit que la sélection n'est pas relative à un emplacement spécifique. Les nœuds résultants
DOIVENT être des nœuds d'éléments ou d'attributs.
-
Les attributs pointant vers des informations existantes dans le document, c'est-à-dire les attributs dont le nom se termine par
« Pointer », DOIVENT utiliser une valeur de type RelativeLocationPath comme décrit dans
[XPath 1.0] ou ses successeurs. L'expression XPath est évaluée relativement aux nœuds sélectionnés par
l'attribut selector. Les attributs suivants pointent vers des informations existantes :
locNotePointer,
locNoteRefPointer,
termInfoPointer,
termInfoRefPointer,
rubyPointer,
rtPointer,
rpPointer,
rbcPointer,
rtcPointer,
rbspanPointer,
langPointer.
Si des espaces de noms [XML Names] sont utilisés dans les
expressions XPath, dans l'attribut selector ou les
attributs de pointage, les règles suivantes DOIVENT être appliquée pendant le traitement XPath :
-
Pour chaque préfixe, il DOIT y avoir un attribut xmlns
au même élément de règle permettant de résoudre l'adresse URI d'espace de noms du préfixe ;
-
Les noms d'éléments et d'attributs sans préfixe sont interprétés comme n'ayant pas d'espace de noms ;
-
Afin d'éviter les conflits avec la règle n° 2, les espaces de noms par défaut NE DOIVENT PAS
être utilisés dans les expressions XPath.
Les règles globales peuvent apparaître dans le document XML auquel elle s'appliqueront ou dans un document XML
séparé. La priorité de leur traitement dépend de ces variations. Cf. également la section
5.4 La priorité entre les sélections.
Le balisage pour une sélection globale avec des règles est défini comme suit :
- rules
-
- att.selector
-
- att.version
-
5.2.2 La sélection locale dans un document XML
La sélection locale dans les documents XML est réalisée avec des attributs ITS locaux,
l'élément ruby ou l'élément span.
L'élément span sert juste de porteur pour les attributs ITS locaux et
de conteneur pour l'élément ruby.
Le modèle de contenu de span autorise une imbrication arbitraire du balisage ruby,
puisque les éléments rb et rt eux-mêmes peuvent contenir
des éléments span. Une application ruby NE DOIT PAS
utiliser une telle imbrication arbitraire.
La catégorie de données détermine ce qui est sélectionné. Les valeurs par défaut nécessaires spécifiques des catégories de données
sont décrites dans la section 6.1 La position, les valeurs par défaut, l'héritage et la prédominance des catégories de données.
Exemple n° 15 : Les valeurs par défaut de diverses catégories de données
Par défaut, le contenu de tous les éléments d'un document est traduisible. L'attribut its:translate="no" dans
l'élément head signifie que le contenu de cet élément, y compris les sous-éléments, ne devrait pas être traduit.
L'attribut its:translate="yes" dans l'élément title signifie que le contenu de cet élément devrait être traduit
(écrasant le its:translate="no" dans head). Les valeurs d'attributs des éléments sélectionnés ne sont pas affectées
par les attributs translate locaux. Par défaut, elles ne sont pas traduisibles.
Le sens d'écriture (directionality) par défaut d'un document est de gauche-à-droite. L'attribut its:dir="rtl" dans l'élément quote
signifie que le sens d'écriture du contenu de cet élément, y compris les sous-éléments et attributs, est de droite-à-gauche. Notez que
l'attribut xml:lang indique uniquement la langue, non le sens d'écriture.
<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>
[Fichier source : EX-selection-local-1.xml]
Le balisage pour la sélection locale est défini comme suit. Le groupe d'attributs att.local.no-ns.attributes
contient les attributs ITS sans espace de noms (N.d.T. in no namespace) et s'utilise avec les
éléments span, locNote,
ruby, rb, rt,
rbc, rtc et rp.
Le groupe d'attributs att.local.with-ns.attributes contient les attributs ITS
qualifiés d'un espace de noms (namespace qualified ITS attributes) et s'utilise avec les éléments provenant
d'espaces de noms différents.
- att.local.no-ns
-
- att.local.with-ns
-
- span
-
5.3 Le lien aux règles externes
Une façon d'associer un document à un ensemble de règles ITS externes est d'utiliser l'attribut XLink
href optionnel [XLink 1.0]
dans l'élément rules, accompagné de l'attribut XLink
type avec la valeur "simple". Le document appelé
doit être un document XML valide contenant un élément rules au plus.
Cet élément rules peut être l'élément racine ou il peut se trouver n'importe où dans l'arbre du document
(par exemple, le document peut être de type XML Schema).
Les règles contenues dans le document appelé DOIVENT être traitées comme si elles étaient
au début (top) de l'élément rules avec l'attribut XLink
href.
Exemple n° 16 : Le fichier EX-link-external-rules-1.xml avec des règles globales :
L'exemple montre comment ajouter des métadonnées aux règles ITS.
<myFormatInfo
xmlns:its="http://www.w3.org/2005/11/its" >
<desc>ITS rules used by the Open University</desc>
<hostVoc>http://www.tei-c.org/ns/1.0</hostVoc>
<rulesId>98ECED99DF63D511B1250008C784EFB1</rulesId>
<rulesVersion>v 1.81 2006/03/28 07:43:21</rulesVersion> ...
<its:rules version="1.0">
<its:translateRule selector="//header" translate="no"/>
<its:translateRule selector="//term" translate="no"/>
<its:termRule selector="//term" term="yes"/>
<its:withinTextRule withinText="yes" selector="//term | //b"/>
</its:rules>
</myFormatInfo>
[Fichier source : EX-link-external-rules-1.xml]
Le résultat du traitement des deux documents précédents est le même que celui du document suivant.
Exemple n° 18 : Un document avec des règles identiques à celles incluses
<myDoc
xmlns:its="http://www.w3.org/2005/11/its" >
<header>
<its:rules version="1.0">
<its:translateRule selector="//header" translate="no"/>
<its:translateRule selector="//term" translate="no"/>
<its:termRule selector="//term" term="yes"/>
<its:withinTextRule withinText="yes" selector="//term | //b"/>
<its:translateRule selector="//term" translate="yes"/>
</its:rules>
<author>Theo Brumble</author>
<lastUpdate>Apr-01-2006</lastUpdate>
</header>
<body>
<p>A <term>Palouse horse</term> has a spotted coat.</p>
</body>
</myDoc>
[Fichier source : EX-link-external-rules-3.xml]
Les applications traitant un balisage ITS global DOIVENT reconnaître
l'attribut XLink href dans l'élément rules ;
elles DOIVENT charger le document référencé correspondant et traiter son élément rules
avant le contenu de l'élément rules où se trouve
l'attribut XLink href original.
Les règles externes peuvent également avoir des liens vers d'autres règles externes. Le mécanisme de liaison est récursif, les règles
les plus profondes étant écrasées par celles au niveau supérieur, le cas échéant.
5.4 La priorité entre les sélections
On définit l'ordre de priorité suivant pour les sélections d'informations ITS à des positions variées (le premier élément
de la liste ayant la priorité la plus élevée) :
-
La sélection locale implicite dans les documents (attributs ITS locaux sur un élément spécifique) ;
-
Les sélections globales dans les documents (avec un élément rules) ;
Dans chaque élément rules, l'ordre de priorité est le suivant :
-
Les règles au sein de l'élément rules ;
-
Les règles reliées via l'attribut XLink href.
Remarque :
Si des sélections identiques sont définies dans des éléments rules différents au sein d'un document,
celle définie dans le dernier prédomine.
Remarque :
ITS ne définit pas de priorité relative aux règles définies ou reliées par des mécanismes non-ITS (telles
que des instructions de traitement pour relier les règles).
-
Les sélections via les valeurs par défaut des catégories de données, cf. la section
6.1 La position, les valeurs par défaut, l'héritage et la prédominance des catégories de données.
En cas de conflits entre des sélections globales via de multiples éléments de règles,
le dernier sélecteur prédomine.
Remarque :
L'ordre de priorité satisfait le même besoin que les règles de gabarits intégrées (built-in template rules)
de
