Veuillez consulter la page des errata →vf de ce document, laquelle peut contenir des corrections normatives.
Cf. d'éventuelles traductions.
Ce document est également disponible dans les formats non normatifs suivants : document ODD/XML, archive auto-contenue zip et marquage Diff XHTML pour publication du 26 février 2007.
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Copyright © 2007 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de nom de marque et d'utilisation des documents du W3C s'appliquent.
Ce document définit des catégories de données et leur mise en œuvre comme un ensemble d'éléments et attributs appelé Jeu de balises d'internationalisation (Internationalization Tag Set), ou jeu ITS. Le jeu ITS est conçu pour être utilisé de concert avec des schémas afin d'aider à l'internationalisation et la localisation de schémas et de documents. Une mise en œuvre est fournie pour trois langages de schémas : XML DTD, XML Schema et RELAX NG.
Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications actutelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.
Ce document définit des catégories de données (data categories) et leur mise en œuvre comme un ensemble d'éléments et attributs appelé Jeu de balises d'internationalisation, ou jeu ITS. Le jeu ITS est conçu pour être utilisé de concert avec des schémas afin d'aider à l'internationalisation et la localisation de schémas et de documents. Une mise en œuvre est fournie pour trois langages de schémas : XML DTD, XML Schema et RELAX NG.
C'est une recommandation du W3C. Elle a été développée par le groupe de travail Internationalization Tag Set (ITS) du W3C, sous l'égide de l'activité Internationalization.
Ce document qui a été revu par les membres du W3C, des développeurs de logiciels et par d'autres groupes du W3C et tiers intéressés est approuvé par le Directeur en tant que recommandation du W3C. C'est un document stable qui peut être utilisé comme document de référence ou cité par un autre document. Le rôle du W3C en produisant la recommandation consiste à attirer l'attention sur la spécification et à en promouvoir le large déploiement. Cela participe à la fonctionnalité et l'interopérabilité du Web.
Veuillez utiliser le système Bugzilla public du W3C pour commenter ce document. Nous recommandons l'utilisation de Bugzilla pour les commentaires (on trouvera des instructions dans la page intitulée « Comment utiliser le système de suivi des problèmes de l'ébauche du jeu ITS »). Si ce n'est pas possible, on peut aussi envoyer ses commentaires à la liste de diffusion www-i18n-comments@w3.org. Utilisez la chaîne « [Comment on ITS WD] » dans la ligne objet de votre message. Une liste des commentaires et problèmes dans Bugzilla relatifs au jeu ITS et les archives www-i18n-comments sont à la disposition du public.
Ce document inclut les changements mineurs effectués par rapport à la recommandation proposée du 21 novembre 2006 ; veuillez consulter le journal des révisions pour le détail. Le rapport de mise en œuvre et le jeu d'essais fournissent d'autres renseignements de mise en œuvre.
Ce document est le produit d'un groupe œuvrant sous couvert de la politique de brevets du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevets établie avec les produits livrables du groupe ; cette page contient également des instructions pour la divulgation d'un brevet. Quiconque a connaissance réelle d'un brevet qu'il estime contenir des revendications essentielles doit révéler cette information conformément à la section 6 de la politique de brevets du W3C.
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 :
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 :
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.
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.
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]
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]
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 :
De manière abstraite dans les descriptions des catégories de données : la section 6 La description des catégories de données
De manière concrète dans les schémas ITS : l'annexe D Les schémas 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.
Un créateur de contenus utilise un attribut sur un élément particulier pour indiquer que le texte qui y est contenu ne devrait pas être traduit.
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]
Un créateur de contenus ou un architecte de l'information utilisent le balisage au début du document pour identifier le type d'élément ou de contexte particuliers dans lesquels le contenu ne devrait pas être traduit.
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]
Un processeur peut insérer, au début du document, du balisage qui lie à des instructions ITS hors du document.
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]
L'élément rules contient plusieurs règles ITS communes à des documents différents.
L'une d'elle est un élément translateRule indiquant de ne pas traduire les
éléments path
ni cmd
.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:translateRule selector="//path | //cmd" translate="no"/> </its:rules>
[Fichier source : EX-ways-to-use-its-4.xml]
Un développeur de schémas intègre des déclarations de balisage ITS dans son schéma pour permettre à ses utilisateurs d'indiquer quelles parties spécifiques du contenu ne pas traduire.
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.
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.
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).
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.
Cette section est informative.
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.
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.
<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.
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 :
Seuls les axes "child" ou "attribute" sont permis
"//" ou "/" possibles
Fonctions id() ou key() possibles
Prédicats possibles
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//*/@*
<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:translateRuleselector="//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).
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.
<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]
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
.
Cette section est normative.
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 ».
[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.
[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 :
La description abstraite (prose description), cf. la section 6 La description des catégories de données ;
La formalisation indépendante du langage de schéma, cf. les sous-sections de « déclarations de balisage » dans la section 6 La description des catégories de données ;
Les mises en œuvre spécifiques du langage de schéma, cf. l'annexe D Les schémas ITS.
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.
[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.
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules version="1.0"> <its:translateRule translate="yes" selector="//p/img/@src"/> </its:rules> ... <p>As you can see in <img src="instructions.jpg"/>, the truth is not always out there.</p> </text>
[Fichier source : EX-notation-terminology-1.xml]
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.
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.
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 :
Un élément rules ;
Un des attributs ITS locaux ;
Un élément span ;
Un élément ruby ;
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.
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-1-1 : Le traitement d'au moins un mécanisme de sélection (global ou local) ;
2-1-2 : La sélection de la valeur par défaut de la catégorie de données ;
2-1-3 : Les définitions de priorité des sélections décrites dans la section 5.4 La priorité entre les sélections, pour les types de sélection qu'il traite.
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.
Cette section est normative.
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.
Les catégories de données ITS peuvent apparaître en deux endroits :
Dans des règles globales : La sélection est réalisée au sein d'un élément rules. Celui-ci contient les éléments de règles pour chaque catégorie de données. Chaque élément de règle a un attribut selector et éventuellement d'autres attributs. L'attribut selector contient une valeur de type AbsoluteLocationPath, comme décrit dans [XPath 1.0] ou ses successeurs.
Localement dans un document : La sélection est réalisée par des attributs ITS locaux, qui sont associés à un nœud d'élément, à l'aide de l'élément span ou de l'élément ruby. Il n'y a pas d'attribut selector supplémentaire. La sélection par défaut pour chaque catégorie de données définit si la sélection couvre les attributs et les sous-éléments. 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.
Les deux endroits sont décrits en détails ci-dessous.
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.
L'élément term
du vocabulaire TEI est dans l'espace de noms http://www.tei-c.org/ns/1.0
.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" xmlns:tei="http://www.tei-c.org/ns/1.0" version="1.0"> <its:termRule selector="//tei:term" term="yes"/> </its:rules>
[Fichier source : EX-selection-global-1.xml]
L'élément qterm
du vocabulaire DocBook n'est dans aucun espace de noms.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:termRule selector="//qterm" term="yes"/> </its:rules>
[Fichier source : EX-selection-global-2.xml]
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 :
[1] | rules |
::= |
element its:rules { rules.content, rules.attributes } |
[2] | rules.content |
::= |
( translateRule | locNoteRule | termRule | dirRule | rubyRule | langRule | withinTextRule )* |
[3] | rules.attributes |
::= |
attribute version { xsd:float }, attribute xlink:href { xsd:anyURI }?, attribute xlink:type { "simple" }? |
[4] | att.selector.attributes |
::= |
att.selector.attribute.selector |
[5] | att.selector.attribute.selector |
::= |
attribute selector { string } |
[6] | att.version.attributes |
::= |
att.version.attribute.version |
[7] | att.version.attribute.version |
::= |
attribute its:version { xsd:float } |
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.
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.
[8] | att.local.no-ns.attributes |
::= |
att.local.no-ns.attribute.translate,
att.local.no-ns.attribute.locNote,
att.local.no-ns.attribute.locNoteType,
att.local.no-ns.attribute.locNoteRef,
att.local.no-ns.attribute.termInfoRef,
att.local.no-ns.attribute.term,
att.local.no-ns.attribute.dir |
[9] | att.local.no-ns.attribute.translate |
::= |
attribute translate { "yes" | "no" }? |
[10] | att.local.no-ns.attribute.locNote |
::= |
attribute locNote { string }? |
[11] | att.local.no-ns.attribute.locNoteType |
::= |
attribute locNoteType { "alert" | "description" }? |
[12] | att.local.no-ns.attribute.locNoteRef |
::= |
attribute locNoteRef { xsd:anyURI }? |
[13] | att.local.no-ns.attribute.termInfoRef |
::= |
attribute termInfoRef { xsd:anyURI }? |
[14] | att.local.no-ns.attribute.term |
::= |
attribute term { "yes" | "no" }? |
[15] | att.local.no-ns.attribute.dir |
::= |
attribute dir { "ltr" | "rtl" | "lro" | "rlo" }? |
[16] | att.local.with-ns.attributes |
::= |
att.local.with-ns.attribute.translate,
att.local.with-ns.attribute.locNote,
att.local.with-ns.attribute.locNoteType,
att.local.with-ns.attribute.locNoteRef,
att.local.with-ns.attribute.termInfoRef,
att.local.with-ns.attribute.term,
att.local.with-ns.attribute.dir |
[17] | att.local.with-ns.attribute.translate |
::= |
attribute its:translate { "yes" | "no" }? |
[18] | att.local.with-ns.attribute.locNote |
::= |
attribute its:locNote { string }? |
[19] | att.local.with-ns.attribute.locNoteType |
::= |
attribute its:locNoteType { "alert" | "description" }? |
[20] | att.local.with-ns.attribute.locNoteRef |
::= |
attribute its:locNoteRef { xsd:anyURI }? |
[21] | att.local.with-ns.attribute.termInfoRef |
::= |
attribute its:termInfoRef { xsd:anyURI }? |
[22] | att.local.with-ns.attribute.term |
::= |
attribute its:term { "yes" | "no" }? |
[23] | att.local.with-ns.attribute.dir |
::= |
attribute its:dir { "ltr" | "rtl" | "lro" | "rlo" }? |
[24] | span |
::= |
element its:span { span.content, span.attributes } |
[25] | span.content |
::= |
( text | ruby | span )* |
[26] | span.attributes |
::= |
att.local.no-ns.attributes |
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.
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]
<myDoc xmlns:its="http://www.w3.org/2005/11/its" xmlns:xlink="http://www.w3.org/1999/xlink" > <header> <its:rules version="1.0" xlink:href="EX-link-external-rules-1.xml" xlink:type="simple"> <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-2.xml]
Le résultat du traitement des deux documents précédents est le même que celui du document suivant.
<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.
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 [XSLT 1.0].
Les deux éléments title
et author
de ce document devraient être traités comme des contenus séparés
lorsqu'ils se trouvent dans un élément prolog
, mais comme faisant partie du contenu de leur parent sinon. Pour réaliser
cette distinction, deux éléments withinTextRule sont utilisés :
La première règle indique que les éléments title
et author
en général devraient être traités comme des
éléments dans un texte. Ce qui annule le comportement par défaut.
La deuxième règle indique que si les éléments title
ou author
se trouvent dans un élément prolog
,
leurs contenus devraient être traités séparément. C'est le comportement par défaut normal mais cette règle est nécessaire pour annuler
la première.
<text xmlns:its="http://www.w3.org/2005/11/its" > <prolog> <its:rules version="1.0"> <its:withinTextRule withinText="yes" selector="//title|//author"/> <its:withinTextRule withinText="no" selector="//prolog/title|//prolog/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>
[Fichier source : EX-selection-precedence-1.xml]
Certains schémas de balisage offrent un balisage qui peut être utilisé pour exprimer des catégories de données ITS. On peut associer des catégories de données ITS à ce balisage existant en utilisant le mécanisme de sélection globale décrit dans la section 5.2.1 La sélection globale avec des règles.
L'association d'un balisage existant à des catégories de données ITS ne peut avoir lieu que si les attentes de traitement du balisage hôte sont les mêmes que (ou supérieures à) celles ITS.
<topic xmlns:its="http://www.w3.org/2005/11/its" id="myTopic"> <title>The ITS Topic</title> <prolog> <its:rules version="1.0"> <its:translateRule selector="//*[@translate='no']" translate="no"/> <its:translateRule selector="//*[@translate='yes']" translate="yes"/> <its:termRule selector="//term | //dt" term="yes"/> </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>
[Fichier source : EX-associating-its-with-existing-markup-1.xml]
On peut associer des règles globales à un document XML donné à l'aide de différentes méthodes :
En utilisant un élément rules dans le document même :
Avec les règles directement dans le document, comme illustré dans l'exemple n° 20 ;
Avec un lien vers des règles externes en utilisant l'attribut XLink href, comme illustré dans l'exemple n° 16.
En associant les règles et le document au travers d'un mécanisme spécifique de l'outil. Par exemple, pour un outil en ligne de commande (command-line tool), en fournissant les chemins du document XML à traiter et de son fichier de règles externes correspondant.
Cette section est normative.
Le tableau suivant résume pour chaque catégorie de donnée la sélection, la valeur par défaut, l'héritage et le comportement de prédominance qui s'appliquent.
La rubrique « Valeurs par défaut » s'applique en l'absence de sélections locale ou et globale.
Par exemple, la valeur par défaut de la catégorie de données Traduire fait valoir que les éléments
sont traduisibles, et que les attributs ne le sont pas si aucun élément translateRule
et aucun attribut translate ne sont présents.
La rubrique « Héritage » décrit si l'information ITS est applicable aux sous-éléments (child elements) des nœuds et attributs liés à ces nœuds ou leurs sous-éléments notes (child notes). Par exemple, l'héritage de la catégorie de données Traduire fait valoir que tous les sous-éléments des nœuds sont traduisibles tandis que tous les attributs liés à ces nœuds ou leurs sous-éléments notes ne le sont pas.
La rubrique « Prédominance » décrit si l'information ITS peut être écrasée (overridden) ou non. La prédominance (overriding) ne s'applique qu'aux catégories de données avec héritage. La prédominance ne s'applique donc pas aux catégories de données Terminologie et Ruby.
Catégorie de données | Utilisation locale | Sélection globale fondée sur des règles | Ajout global d'information | Pointage global vers de l'information existante | Valeurs par défaut | Héritage | Prédominance |
Traduire | Oui | Oui | Oui | Non | translate="yes" pour les éléments, et translate="no" pour les attributs |
Contenu textuel de l'élément, incluant le contenu des sous-éléments mais excluant les attributs | Oui |
Note de localisation | Oui | Oui | Oui | Oui | Néant | Contenu textuel de l'élément, incluant le contenu des sous-éléments mais excluant les attributs | Oui |
Terminologie | Oui | Oui | Oui | Oui | term="no" |
Néant | Sans objet |
Directionnalité | Oui | Oui | Oui | Non | dir="ltr" |
Contenu textuel de l'élément, incluant les attributs et les sous-éléments | Oui |
Ruby | Oui | Oui | Oui | Oui | Néant | Néant | Sans objet |
Information de langue | Non | Oui | Non | Oui | Néant | Contenu textuel de l'élément, incluant les attributs et les sous-éléments | Oui |
Éléments dans du texte | Non | Oui | Oui | Non | withinText="no" |
Néant | Sans objet |
Dans cet exemple, le contenu de tous les éléments data
est traduisible parce que la valeur par défaut de la catégorie de données
Traduire dans les éléments est "yes
". Les contenus de revision
et
locNote ne sont pas traduisibles parce que la valeur par défaut est écrasée
par l'attribut local its:translate="no"
dans l'élément prolog
, et cette valeur est héritée par tous les sous-éléments
de prolog
.
La note de localisation des deux premiers éléments data
est le texte défini globalement avec
l'élément locNoteRule. Et cette note est écrasée pour le dernier élément data
par l'attribut local its:locNote
.
<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 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>
[Fichier source : EX-datacat-behavior-1.xml]
Remarque :
Les catégories de données diffèrent par rapport aux valeurs par défaut. Cela est dû aux normes et pratiques existantes. Par exemple, il est de pratique courante que l'information concernant la traduction se rapporte seulement au contenu textuel d'un élément. Ainsi, la sélection par défaut de la catégorie de données Traduire est le contenu textuel.
La catégorie de données Traduire exprime l'information selon laquelle le contenu d'un élément ou d'un attribut
devrait être traduit ou non. Les valeurs de cette catégorie de données sont "yes
" (traduisible)
ou "no
" (non traduisible).
La catégorie de données Traduire peut s'exprimer avec des règles globales ou localement sur un élément individuel. L'information s'applique au contenu textuel de l'élément, incluant les sous-éléments mais excluant les attributs. Par défaut, les éléments sont traduisibles et les valeurs des attributs ne le sont pas.
GLOBAL : L'élément translateRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique ;
Un attribut translate obligatoire avec
la valeur "yes
" ou "no
".
L'élément translateRule indique de ne pas traduire les éléments code
.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:translateRule translate="no" selector="//code"/> </its:rules>
[Fichier source : EX-translate-selector-1.xml]
LOCAL : La catégorie de données Traduire peut utiliser le balisage local suivant :
Un attribut translate avec
la valeur "yes
" ou "no
".
Remarque :
Il n'est pas possible d'écraser les paramètres d'attributs de la catégorie de données Traduire avec un balisage local. Cette limitation est cohérente avec la pratique conseillée de ne pas utiliser des attributs traduisibles.
L'attribut local its:translate="no"
indique de ne pas traduire le contenu de panelmsg
.
<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>
[Fichier source : EX-translate-selector-2.xml]
[27] | translateRule |
::= |
element its:translateRule { translateRule.content, translateRule.attributes } |
[28] | translateRule.content |
::= |
empty |
[29] | translateRule.attributes |
::= |
att.selector.attributes, attribute translate { "yes" | "no" } |
[30] | att.translate.attributes |
::= |
att.translate.attribute.translate |
[31] | att.translate.attribute.translate |
::= |
attribute its:translate { "yes" | "no" }? |
La catégorie de données Note de localisation est utilisée pour communiquer des notes à propos d'un élément de contenu particulieur aux traducteurs (localizers).
Cette catégorie de données peut avoir plusieurs utilisations, y compris mais non limité à :
Dire au traducteur comment traduire des parties du contenu ;
Développer la signification ou l'utilisation contextuelle d'un élément spécifique, par exemple, à quoi se rapporte une variable ou comment une chaîne sera utilisée dans l'interface d'utilisateur ;
Lever une ambiguïté et montrer suffisamment les relations entre les éléments pour une traduction exacte (par exemple, dans beaucoup de langues, il est impossible de traduire le qualificatif anglais « enabled » isolément sans connaître le genre, le nombre et le cas de l'objet auquel il se rapporte) ;
Indiquer pourquoi un morceau de texte est mis en exergue (important, sarcastique, etc.)
Deux types de notes informatives sont nécessaires :
Une alerte contenant des informations que le traducteur doit lire avant de traduire un morceau de texte. Exemple : une instruction
au traducteur aux traducteurs de laisser des parties du texte dans le langage source.
Un description fournissant une information de base à laquelle le traducteur se référera
les traducteurs se référeront uniquement si besoin. Exemple : la levée d'une ambiguïté dans le texte source.
Les outils d'édition peuvent offrir un moyen pratique de créer ce type d'information. Les outils de traduction peuvent être conçus pour distinguer ces deux types de notes de localisation et présenter les informations aux traducteurs de différentes façons.
La catégorie de données Note de localisation peut s'exprimer avec des règles globales ou localement sur un élément individuel. L'information s'applique au contenu textuel de l'élément, incluant les sous-éléments mais excluant les attributs.
GLOBAL : L'élément locNoteRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique ;
Un attribut locNoteType obligatoire avec la valeur "description
" ou "alert
" ;
Un seul exactement des suivants :
Un élément locNote qui contient la note en question et autorise un balisage ITS local ;
Un attribut locNotePointer contenant une expression XPath relative qui pointe vers un nœud contenant la note de localisation ;
Un attribut locNoteRef qui contient une adresse URI indiquant l'emplacement de la note de localisation ;
Un attribut locNoteRefPointer contenant une expressions XPath relative qui pointe vers un nœud contenant l'adresse URI indiquant l'emplacement de la note de localisation.
L'élément locNoteRule associe le contenu de l'élément locNote au message avec l'identificateur « DisableInfo » et le marque comme important. Cela fonctionnerait également si la règle était dans un fichier externe, permettant de fournir des notes sans modifier le document source.
<myRes xmlns:its="http://www.w3.org/2005/11/its" > <head> <its:rules 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>
[Fichier source : EX-locNote-element-1.xml]
L'attribut locNotePointer est une expression XPath relative pointant vers un nœud contenant la note.
<Res xmlns:its="http://www.w3.org/2005/11/its" > <prolog> <its:rules 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>
[Fichier source : EX-locNotePointer-attribute-1.xml]
L'élément locNoteRule indique que le message avec l'identificateur « NotFound » a une note d'explication correspondante dans un fichier externe. L'adresse URI de l'emplacement exact de la note est stockée dans l'attribut locNoteRef.
<myRes xmlns:its="http://www.w3.org/2005/11/its" > <head> <its:rules 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>
[Fichier source : EX-locNoteRef-attribute-1.xml]
L'attribut locNoteRefPointer contient une expression XPath relative pointant vers un nœud contenant l'adresse URI référençant l'emplacement de la note.
<dataFile xmlns:its="http://www.w3.org/2005/11/its" > <prolog> <its:rules 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> </dataFile>
[Fichier source : EX-locNoteRefPointer-attribute-1.xml]
LOCAL : La catégorie de données Note de localisation peut utiliser le balisage local suivant :
L'un des suivants :
Un attribut locNote contenant la note en question ;
Un attribut locNoteRef qui contient une adresse URI référençant l'emplacement de la note de localisation.
Un attribut locNoteType optionnel avec la valeur "description
" ou "alert
".
Si l'attribut locNoteType est absent, la note de localisation
sera censé de type "description
".
<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>
[Fichier source : EX-locNote-selector-2.xml]
Remarque :
En général, on recommande d'éviter de stocker du texte dans des attributs, mais dans ce cas particulier le besoin de fournir les notes sans interférer avec la structure du document hôte est plus important que l'inconvénient d'utiliser un attribut.
[32] | locNoteRule |
::= |
element its:locNoteRule { locNoteRule.content, locNoteRule.attributes } |
[33] | locNoteRule.content |
::= |
locNote? |
[34] | locNoteRule.attributes |
::= |
att.selector.attributes, attribute locNotePointer { string }?, attribute locNoteType { "alert" | "description" }, attribute locNoteRef { xsd:anyURI }?, attribute locNoteRefPointer { string }? |
[35] | locNote |
::= |
element its:locNote { locNote.content, locNote.attributes } |
[36] | locNote.content |
::= |
( text | ruby | span )* |
[37] | locNote.attributes |
::= |
att.local.no-ns.attributes |
[38] | att.locNote.attributes |
::= |
att.locNote.attribute.locNote, att.locNote.attribute.locNoteType, att.locNote.attribute.locNoteRef |
[39] | att.locNote.attribute.locNote |
::= |
attribute its:locNote { string }? |
[40] | att.locNote.attribute.locNoteType |
::= |
attribute its:locNoteType { "alert" | "description" }? |
[41] | att.locNote.attribute.locNoteRef |
::= |
attribute its:locNoteRef { xsd:anyURI }? |
La catégorie de données Terminologie sert à marquer des termes et, en option, les associer à des informations, telles que des définitions. Cela permet d'améliorer la cohérence à travers les différentes parties de la documentation. Elle est aussi utile pour la traduction.
Remarque :
Les normes de terminologie existantes, telle la norme [ISO 12200]
[ISO 16642]
et ses formats dérivés, traitent du codage de données terminologiques, tandis que la catégorie de données ITS
Terminologie permet simplement d'identifier des termes dans les documents XML et, en option,
de pointer vers une information correspondante.
La catégorie de données Terminologie peut s'exprimer avec des règles globales ou localement sur un élément individuel. Il n'y a pas d'héritage. Par défaut, ni les éléments ni les attributs sont des termes.
GLOBAL : L'élément termRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique ;
Un attribut term obligatoire avec la valeur "yes
" ou "no
" ;
Un seul exactement des suivants :
Un attribut termInfoPointer contenant une expression XPath relative qui pointe vers un nœud contenant l'information de terminologie ;
Un attribut termInfoRef contenant une adresse URI qui référence la ressource fournissant l'information à propos du terme ;
Un attribut termInfoRefPointer contenant une expression XPath relative qui pointe vers un nœud contenant l'adresse URI référençant l'emplacement de l'information de terminologie.
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules 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>
[Fichier source : EX-terms-selector-1.xml]
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules 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>
[Fichier source : EX-terms-selector-2.xml]
<text xmlns:its="http://www.w3.org/2005/11/its" > <its:rules 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>
[Fichier source : EX-terms-selector-3.xml]
LOCAL : La catégorie de données Terminologie peut utiliser le balisage local suivant :
Un attribut term avec la valeur "yes
" ou "no
" ;
Un attribut termInfoRef optionnel contenant une adresse URI qui référence la ressource fournissant l'information à propos du terme.
<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>
[Fichier source : EX-terms-selector-4.xml]
[42] | termRule |
::= |
element its:termRule { termRule.content, termRule.attributes } |
[43] | termRule.content |
::= |
empty |
[44] | termRule.attributes |
::= |
att.selector.attributes, attribute term { "yes" | "no" }, attribute termInfoRef { xsd:anyURI }?, attribute termInfoRefPointer { string }?, attribute termInfoPointer { string }? |
[45] | att.term.attributes |
::= |
att.term.attribute.termInfoRef, att.term.attribute.term |
[46] | att.term.attribute.termInfoRef |
::= |
attribute its:termInfoRef { xsd:anyURI }? |
[47] | att.term.attribute.term |
::= |
attribute its:term { "yes" | "no" }? |
La catégorie de données Directionnalité permet à l'utilisateur de définir le
direction d'écriture de base (base writing direction) des blocs, incorporations (embeddings) et
dérogations (overrides) pour l'algorithme bidirectionnel Unicode. Elle a quatre valeurs :
"ltr
", "rtl
", "lro
" et "rlo
".
Remarque :
ITS définit seulement les valeurs de la catégorie de données Directionnalité et leur héritage. Le comportement du texte étiqueté de cette façon peut varier, en fonction de la mise en œuvre. Toutefois, on encourage les développeurs à calquer le comportement sur celui décrit dans la spécification CSS 2.1 ou ses successeurs. Auquel cas, l'effet des valeurs de la catégorie de données correspondrait aux règles CSS suivantes :
Valeur de catégorie de données : "ltr
" (left-to-right) texte de gauche-à-droite
Règle CSS : *[dir="ltr"] {unicode-bidi: embed; direction: ltr}
Valeur de catégorie de données : "rtl
" (right-to-left) texte de droite-à-gauche
Règle CSS : *[dir="rtl"] {unicode-bidi: embed; direction: rtl}
Valeur de catégorie de données : " "rlo
"lro
" (left-to-right override) dérogation de texte gauche-à-droite
Règle CSS : *[dir="lro"] {unicode-bidi: bidi-override; direction: ltr}
Valeur de catégorie de données : "rlo
" (right-to-left override) dérogation de texte droite-à-gauche
Règle CSS : *[dir="rlo"] {unicode-bidi: bidi-override; direction: rtl}
L'article [Bidi Article] fournit plus de renseignements pour l'utilisation de cette catégorie de données.
La catégorie de données Directionnalité peut s'exprimer avec des règles globales ou localement sur un élément individuel. L'information s'applique au contenu textuel de l'élément, incluant les sous-éléments et les attributs. Par défaut, les éléments et les attributs ont un sens d'écriture (directionality) de gauche-à-droite.
GLOBAL : L'élément dirRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique ;
Un attribut dir obligatoire avec la valeur "ltr
",
"rtl
", "lro
" ou "rlo
".
Dans ce document, le sens d'écriture de droite-à-gauche est indiquée par un attribut direction
avec une valeur de « rtlText ».
<text xml:lang="en">
<body>
<par>In Hebrew, the title <quote xml:lang="he" direction="rtlText">פעילות הבינאום, W3C</quote>
means <quote>Internationalization Activity, W3C</quote>.</par>
</body>
</text>
[Fichier source : EX-dir-selector-1.xml]
L'élément dirRule indique que tous les éléments avec un attribut direction="rtlText"
ont un contenu de droite-à-gauche.
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:dirRule dir="rtl" selector="//*[@direction='rtlText']"/> </its:rules>
[Fichier source : EX-dir-selector-2.xml]
LOCAL : La catégorie de données Directionnalité peut utiliser le balisage local suivant :
Un attribut dir avec la valeur "ltr
",
"rtl
", "lro
" ou "rlo
".
Sur le premier élément quote
, l'attribut its:dir="rtl"
indique un contenu de droite-à-gauche.
<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>
[Fichier source : EX-dir-selector-3.xml]
[48] | dirRule |
::= |
element its:dirRule { dirRule.content, dirRule.attributes } |
[49] | dirRule.content |
::= |
empty |
[50] | dirRule.attributes |
::= |
att.selector.attributes, attribute dir { "ltr" | "rtl" | "lro" | "rlo" } |
[51] | att.dir.attributes |
::= |
att.dir.attribute.dir |
[52] | att.dir.attribute.dir |
::= |
attribute its:dir { "ltr" | "rtl" | "lro" | "rlo" }? |
La catégorie de données Ruby est utilisée pour un morceau de texte (run of text) associé à un autre morceau de texte, appelé texte de base. Le texte ruby sert à fournir une annotation brève du texte de base associé. On l'utilise presque toujours comme guide pour la lecture (prononciation).
La catégorie de données Ruby peut s'exprimer avec des règles globales ou localement. Il n'y a pas d'héritage.
GLOBAL : L'élément rubyRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique. C'est le texte de base du ruby ;
Un attribut rubyPointer optionnel contenant une expression XPath relative
qui pointe vers un nœud correspondant à l'élément ruby
;
Un attribut rpPointer optionnel contenant une expression XPath relative qui pointe vers un nœud correspondant à la parenthèse ruby (ruby parenthesis) ;
Un attribut rbcPointer optionnel contenant une expression XPath relative qui pointe vers un nœud correspondant au conteneur de base ruby (ruby base container) ;
Un attribut rtcPointer optionnel contenant une expression XPath relative qui pointe vers un nœud correspondant au conteneur de texte ruby (ruby text container) ;
Un attribut rbspanPointer optionnel contenant une expression XPath relative qui pointe vers un nœud correspondant à l'attribut rbspan ;
Un élément rubyText optionnel contenant le texte ruby ;
Un attribut rtPointer optionnel contenant une expression XPath relative qui pointe vers un nœud correspondant au texte ruby (ruby text).
Remarque :
Là où les formats existants ne contiennent pas de balisage ruby, il est toujours possible d'associer un texte ruby à un intervalle défini du contenu du document en utilisant l'élément rubyRule.
<text xmlns:its="http://www.w3.org/2005/11/its" > <head> ... <its:rules 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>
[Fichier source : EX-ruby-legacy-1.xml]
LOCAL : Dans un document, la catégorie de données Ruby est réalisée avec un élément ruby. Celui-ci présente le contenu suivant :
Un élément rb qui contient le texte de base ruby et autorise un balisage ITS local ;
Un élément rp qui contient la parenthèse ruby. On l'utilise dans un balisage simple pour indiquer les caractères qui peuvent dénoter le début et la fin du texte ruby lorsque les agents utilisateurs n'ont pas d'autres moyens pour distinguer le texte ruby du texte du texte de base à la présentation ;
Un élément rt qui contient le texte ruby et autorise un balisage ITS local. Il a un attribut rbspan optionnel. L'attribut rbspan permet à un élément rt de couvrir (span) plusieurs éléments rb ;
Un élément rbc qui contient le conteneur de base ruby ;
Un élément rtc qui contient le conteneur de texte ruby.
Tous ces éléments partagent les attributs de l'élément span.
<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>
[Fichier source : EX-ruby-implementation-1.xml]
Remarque :
La structure du modèle de contenu de l'élément ruby est identique à celle du balisage ruby défini dans la spécification [Ruby-TR]. La mise en œuvre de la catégorie de données Ruby est encouragée mais pas obligatoire d'après les critères de conformité pour ruby définis dans cette spécification.
La structure du ruby définie dans la section 5.4 de [OpenDocument] est également conforme au ruby défini dans cette spécification.
[53] | rubyRule |
::= |
element its:rubyRule { rubyRule.content, rubyRule.attributes } |
[54] | rubyRule.content |
::= |
rubyText? |
[55] | rubyRule.attributes |
::= |
att.selector.attributes, attribute rubyPointer { string }?, attribute rtPointer { string }?, attribute rpPointer { string }?, attribute rbcPointer { string }?, attribute rtcPointer { string }?, attribute rbspanPointer { string }? |
[56] | rubyText |
::= |
element its:rubyText { rubyText.content, rubyText.attributes } |
[57] | rubyText.content |
::= |
text |
[58] | rubyText.attributes |
::= |
att.local.no-ns.attributes, attribute rbspan { string }? |
[59] | ruby |
::= |
element its:ruby { ruby.content, ruby.attributes } |
[60] | ruby.content |
::= |
( rb, ( rt | ( rp, rt, rp ) ) ) | ( rbc, rtc, rtc? ) |
[61] | ruby.attributes |
::= |
att.local.no-ns.attributes |
[62] | rb |
::= |
element its:rb { rb.content, rb.attributes } |
[63] | rb.content |
::= |
( text | span )* |
[64] | rb.attributes |
::= |
att.local.no-ns.attributes |
[65] | rt |
::= |
element its:rt { rt.content, rt.attributes } |
[66] | rt.content |
::= |
( text | span )* |
[67] | rt.attributes |
::= |
att.local.no-ns.attributes, attribute rbspan { string }? |
[68] | rbc |
::= |
element its:rbc { rbc.content, rbc.attributes } |
[69] | rbc.content |
::= |
rb+ |
[70] | rbc.attributes |
::= |
att.local.no-ns.attributes |
[71] | rtc |
::= |
element its:rtc { rtc.content, rtc.attributes } |
[72] | rtc.content |
::= |
rt+ |
[73] | rtc.attributes |
::= |
att.local.no-ns.attributes |
[74] | rp |
::= |
element its:rp { rp.content, rp.attributes } |
[75] | rp.content |
::= |
text |
[76] | rp.attributes |
::= |
att.local.no-ns.attributes |
L'élément langRule sert à exprimer la langue d'une partie donnée du contenu.
L'attribut langPointer pointe vers le balisage qui exprime la langue du texte sélectionné
par l'attribut selector
. Ce balisage DOIT utiliser des valeurs conformes
au standard [BCP47]. La méthode recommandée pour indiquer une
identification de langue est d'utiliser l'attribut xml:lang
. L'élément langRule
est seulement prévu comme mécanisme de repli pour les documents où la langue est identifiée à l'aide d'un autre concept (construct).
L'élément langRule suivant fait valoir que le contenu de tous les éléments p
(y compris les valeurs d'attributs et le contenu textuel des sous-éléments) est dans la langue indiquée par « mylangattribute »,
qui est associé aux éléments p
, et exprime une langue avec des valeurs conformes
à [BCP47].
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:langRule selector="//p" langPointer="@mylangattribute"/> </its:rules>
[Fichier source : EX-lang-definition-1.xml]
Remarque :
La catégorie de données Information de langue subvient seulement à des règles exprimées à un niveau global.
Localement, les utilisateurs peuvent utiliser l'attribut xml:lang
(défini par XML) ou un attribut spécifique du
format en question (comme dans l'exemple n° 38).
L'attribut xml:lang
est la méthode de prédilection pour l'identification de la langue. Pour faciliter l'utilisation de
xml:lang
, la déclaration de cette attribut fait partie de la définition DTD XML
et du document XML Schema, non normatifs, des déclarations de balisage ITS. Il n'y a pas de déclaration de
xml:lang
dans le document RELAX NG non normatif, car il n'y a pas besoin de déclarer les attributs
de l'espace de noms XML dans RELAX NG.
Il n'est pas nécessaire d'appliquer la catégorie de données Information de langue
aux attributs xml:lang
en utilisant des règles globales, puisque xml:lang
est la méthode standard
pour indiquer une information de langue dans XML. L'attribut xml:lang
est défini selon le document
RFC 3066 ou ses successeurs
(la norme [BCP47] est la « meilleure pratique courante »
pour l'identification de la langue et elle englobe [RFC 3066]
et ses successeurs).
La catégorie de données Information de langue peut seulement s'exprimer avec des règles globales. L'information s'applique au contenu textuel de l'élément, incluant les sous-éléments et les attributs. Il n'y a aucune valeur par défaut.
GLOBAL : L'élément langRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique ;
Un attribut langPointer obligatoire contenant une expression XPath relative qui pointe vers un nœud contenant l'information de langue.
[77] | langRule |
::= |
element its:langRule { langRule.content, langRule.attributes } |
[78] | langRule.content |
::= |
empty |
[79] | langRule.attributes |
::= |
att.selector.attributes, attribute langPointer { string } |
La catégorie de données Éléments dans du texte révèle si et comment un élément affecte le comportement d'un contenu textuel d'un point de vue linguistique. Cette information est pertinente, par exemple, pour fournir des indications de segmentation de texte de base à des outils tels que les systèmes de mémoire de traduction (translation memory systems). Les valeurs associées à cette catégorie de données sont les suivantes :
"yes
" : L'élément et son contenu font partie du flux de l'élément parent. Par exemple, l'élément strong
dans [XHTML 1.0]:
<strong>Appaloosa horses</strong> have spotted coats.
"nested
" : L'élément fait partie du flux de l'élément parent, son contenu est un flux indépendant. Par exemple,
l'élément fn
dans [DITA 1.0] :
Palouse horses<fn>A Palouse horse is the same as an Appaloosa.</fn> have spotted coats.
"no
" : L'élément coupe le flux de texte de l'élément parent et son contenu est un flux de texte indépendant. Par exemple,
l'élément p
lorsqu'il se trouve dans un élément li
dans DITA ou XHTML :
<li>Palouse horses: <p>They have spotted coats.</p> <p>They have been bred by the Nez Perce.</p> </li>
La catégorie de données Éléments dans du texte ne peut s'exprimer qu'avec des règles globales. Il n'y a pas d'héritage. Par défaut, les éléments ne sont pas dans du texte.
GLOBAL : L'élément withinTextRule présente le contenu suivant :
Un attribut selector obligatoire. Celui-ci contient une expression XPath sélectionnant les nœuds auxquels cette règle s'applique ;
Un attribut withinText obligatoire avec la valeur "yes
",
"no
" ou "nested
".
<its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0"> <its:withinTextRule withinText="yes" selector="//b | //em | //i"/> </its:rules>
[Fichier source : EX-within-text-implementation-1.xml]
[80] | withinTextRule |
::= |
element its:withinTextRule { withinTextRule.content, withinTextRule.attributes } |
[81] | withinTextRule.content |
::= |
empty |
[82] | withinTextRule.attributes |
::= |
att.selector.attributes, attribute withinText { "yes" | "no" | "nested" } |
Cette section est informative.
La liste suivante récapitule les éléments liés aux règles globales et leurs attributs :
<rules> Un conteneur de règles globales.
href
Le pointeur vers les fichiers de règles externes.
type
Type du pointeur vers les fichiers de règles externes.
Les valeurs légales sont :
simple
version
La version du schéma ITS.
<dirRule> Une règle concernant la catégorie de données Directionnalité.
dir
La direction du texte de la sélection.
Les valeurs légales sont :
ltr
rtl
lro
rlo
selector
Une expression XPath identifiant les nœuds à sélectionner.
<langRule> Une règle concernant la catégorie de données Information de langue.
langPointer
Une expression XPath relative pointant vers un nœud contenant une information de langue.
selector
Une expression XPath identifiant les nœuds à sélectionner.
<locNote> Contient une note de localisation.
translate
L'information de catégorie de données Traduire à associer au nœud courant.
locNote
Une note de localisation.
locNoteType
Le type de la note de localisation.
locNoteRef
Une adresse URI référençant l'emplacement de la note de localisation.
termInfoRef
Le pointeur vers la ressource contenant l'information à propos du terme.
term
Indique un terme localement.
dir
La direction du texte pour le contexte.
<locNoteRule> Une règle concernant la catégorie de données Note de localisation.
locNotePointer
Une expression XPath relative pointant vers un nœud contenant la note de localisation.
locNoteType
Le type de note de localisation.
Les valeurs légales sont :
alert
description
locNoteRef
L'adresse URI référençant l'emplacement de la note de localisation.
locNoteRefPointer
Une expression XPath relative pointant vers un nœud contenant l'adresse URI référençant l'emplacement de la note de localisation.
selector
Une expression XPath identifiant les nœuds à sélectionner.
<termRule> Une règle concernant la catégorie de données Terminologie.
term
Indique si la sélection est un terme ou non.
Les valeurs légales sont :
yes
no
termInfoRef
L'adresse URI référençant la ressource fournissant des informations à propos du terme.
termInfoRefPointer
Une expression XPath relative pointant vers un nœud contenant une adresse URI référençant la ressource fournissant des informations à propos du terme.
termInfoPointer
Une expression XPath relative pointant vers un nœud contenant des informations à propos du terme.
selector
Une expression XPath identifiant les nœuds à sélectionner.
<translateRule> Une règle concernant la catégorie de données Traduire.
translate
L'information de catégorie de données Traduire à appliquer aux nœuds sélectionnés.
Les valeurs légales sont :
yes
no
selector
Une expression XPath identifiant les nœuds à sélectionner.
<withinTextRule> Une règle concernant la catégorie de données Éléments dans du texte.
withinText
Déclare si le contexte courant est vu comme « dans du texte ».
Les valeurs légales sont :
yes
no
nested
selector
Une expression XPath identifiant les nœuds à sélectionner.
<rubyRule> Une règle concernant la catégorie de données Ruby.
rubyPointer
Une expression XPath relative pointant vers un nœud correspondant à un élément ruby
.
rtPointer
Une expression XPath relative pointant vers un nœud correspondant à un élément rt
.
rpPointer
Une expression XPath relative pointant vers un nœud correspondant à un élément rp
.
rbcPointer
Une expression XPath relative pointant vers un nœud correspondant à un élément rbc
.
rtcPointer
Une expression XPath relative pointant vers un nœud correspondant à un élément rtc
.
rbspanPointer
Une expression XPath relative pointant vers un nœud correspondant à un attribut rbspan
.
selector
Une expression XPath identifiant les nœuds à sélectionner.
La liste suivante récapitule les éléments disponibles pour une utilisation locale :
<span> Un élément de type en-ligne (inline) pour contenir une information ITS.
<rb> Un texte de base ruby.
<rbc> Un conteneur pour les éléments rb
dans le cas d'un balisage ruby complexe.
<rp> Utilisé dans le cas d'un balisage ruby simple pour indiquer les caractères qui peuvent dénoter le début et la fin du texte ruby lorsque les agents utilisanteurs n'ont pas d'autres moyens de distinguer le texte ruby du texte de base à la présentation.
<rt> Un texte ruby.
<rtc> Un conteneur pour les éléments rt
dans le cas d'un balisage ruby complexe.
<ruby> Un balisage ruby.
La liste suivante récapitule les attributs disponibles pour une utilisation locale, avec les éléments locaux précédents ou avec les autres éléments du schéma hôte :
translate
L'information de catégorie de données Traduire à associer au nœud courant.
locNote
Une note de localisation.
locNoteType
Le type de note de localisation.
locNoteRef
L'adresse URI référençant l'emplacement de la note de localisation.
termInfoRef
Un pointeur vers une ressource contenant des informations à propos du terme.
term
Indique un terme localement.
dir
La direction du texte pour le contexte.
Cette section est informative.
Les schémas suivants définissent les éléments et attributs ITS et peuvent servir de blocs de constructions pour intégrer du balisage ITS dans son propre vocabulaire XML. On peut voir des exemples de telles intégrations dans « Les pratiques recommandées pour l'internationalisation XML ». Les schémas ne sont pas conçus pour être utilisés seuls pour valider les documents avec du balisage ITS.
Voici les schémas fournis :
Cette section est informative.
Plusieurs contraintes du balisage ITS ne peuvent pas être validées avec les schémas ITS. Le document [Schematron] suivant permet de valider une partie de ces contraintes.
<sch:schema xmlns:sch="http://www.ascc.net/xml/schematron" > <!-- Schematron document to test constraints for global and local balisage ITS. For balisage ITS definitions, see http://www.w3.org/TR/its/ . --> <sch:ns prefix="its" uri="http://www.w3.org/2005/11/its"/> <sch:pattern name="Check ITS Global Rules and Local Constraints, and Version Constraints"> <sch:rule context="*"> <!-- Tests for locNoteRule --> <sch:report test="self::its:locNoteRule and child::its:locNote and @its:locNotePointer"> locNoteRule error: A locNoteRule element must not have both a locNote child element and a locNotePointer attribute.</sch:report> <sch:report test="self::its:locNoteRule and @its:locNoteRef and @its:locNoteRefPointer"> locNoteRule error: A locNoteRule element must not have both a locNoteRef attribute and a locNoteRefPointer attribute.</sch:report> <sch:report test="self::its:locNoteRule and child::its:locNote and @its:locNoteRef"> locNoteRule error: A locNoteRule element must not have both a locNote child element and a locNoteRef attribute.</sch:report> <!-- Test for termRule --> <sch:report test="self::its:termRule and @its:termInfoRef and @its:termInfoRefPointer"> termRule error: A termRule element must not have both a termInfoRef attribute and a termInfoRefPointer attribute.</sch:report> <sch:report test="self::its:termRule and @its:termInfo and @its:termInfoPointer"> termRule error: A termRule element must not have both a termInfo attribute and a termInfoPointer attribute.</sch:report> <sch:report test="self::its:termRule and @its:termInfoRef and @its:termInfoPointer"> termRule error: A termRule element must not have both a termInfoRef attribute and a termInfoPointer attribute.</sch:report> <!-- Test for rubyRule --> <sch:report test="self::its:rubyRule and child::its:rubyText and @its:rtPointer"> rubyRule error: A rubyRule element must not have both a rubyText child element and a rtPointer attribute.</sch:report> <!-- Test for locNote (local) --> <sch:report test="@its:locNote and @its:locNoteRef"> Local ITS usage error: The locNote attribute and the locNoteRef attribute must not be used together.</sch:report> <!-- Test for term (local) --> <sch:report test="@its:termInfoRef and not(its:term) and not(self::its:termRule)"> Local ITS usage error: A termInfoRef attribute must not appear locally without a term attribute.</sch:report> <!-- Version attribute test --> <sch:report test="/*/@its:version != @its:version"> The version attribute at the root element and at the rules element must not specify different versions of ITS.</sch:report> </sch:rule> </sch:pattern> </sch:schema>
[Fichier source : its-constraints-check-schematron.xml]
Cette section est informative.
Le document [NVDL] suivant permet la validation d'un balisage ITS ajouté à un vocabulaire hôte. Seuls les éléments et attributs ITS sont vérifiés. Les éléments et attributs du langage hôte sont ignorés durant la validation par rapport à ce document/schéma NVDL.
<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"> <namespace ns="http://www.w3.org/2005/11/its"> <validate schema="its-elements.rng"/> </namespace> <namespace ns="http://www.w3.org/2005/11/its" match="attributes"> <validate schema="its-attributes.rng"/> </namespace> <anyNamespace> <allow/> </anyNamespace> </rules>
[Source file: its.nvdl]
Le schéma NVDL dépend des deux schémas suivants :
Le journal suivant répertorie les changements majeurs apportés à ce document entre la publication en novembre 2005 et la publication en février 2006.
Une section à propos des concepts de base de ITS a été créée.
La terminologie a été modifiée : les termes pour la position des informations ITS in situ contre disloqué ont été remplacés par sélection dans une instance de document contre sélection globale avec des règles.
La définition de la catégorie de données Directionnalité a changé, pour être conforme avec d'autres spécifications. Cf. le commentaire à propos de la bidirectionnalité pour plus de renseignements.
La terminologie dans le texte de ce document et dans les déclarations de balisage a été modifiée : la portée des informations ITS est remplacée par la sélection des informations ITS.
L'élément schemaRules a été supprimé.
Pour les informations ITS comme une annotation de schéma, où il n'y a maintenant plus que l'élément schemaRule
.
Tous les attributs ITS sont maintenant définis comme attributs qualifiés. Cela induit des changements dans les schémas ITS générés, par exemple, la génération des entités paramètres des préfixes dans les noms d'éléments ou d'attributs.
La possibilité d'attributs selector
dans les instances de documents (dans la version précédente, cela s'appelait
portée dans un document d'instance) est supprimée.
La sélection locale dans une instance de document repose maintenant uniquement sur les
sélections par défaut des catégories de données. Avec ce changement, la définition
de la priorité entre les sélections et les critères de conformité
ont été simplifiés, et le problème sur les exigences d'espace de noms et les valeurs de selector
a pu être résolu.
Les définitions des sélections par défaut des catégories de données ont été modifiées.
Un élément ns
a été ajouté à l'élément rules afin de pouvoir définir
des liaisons d'espaces de noms.
La mise en œuvre de la catégorie de données Ruby a été modifiée pour refléter le retrait des
attributs selector
dans les instances de documents.
Une section sur le mappage des catégories de données ITS au balisage existant a été créée.
Des exemples d'intégration du balisage ITS dans un schéma TEI et dans XML Spec ont été créés.
Un élément span a été créé.
Les exemples ont été modifiés pour refléter les changements mentionnés précédemment.
Pour la clarté, plusieurs sections ont été reformulées et restructurées, et la visualisation du balisage ITS dans le texte de ce document a été modifiée.
Le suivi de ces problèmes est maintenant géré via Bugzilla.
Un journal des révisions a été ajouté.
Le journal suivant répertorie les changements majeurs apportés à ce document entre la publication en février 2006 et la publication en avril 2006.
L'élément schemaRule
et la notion d'annotation de schéma qui y était associée ont été abandonnés.
La section sur la conformité a été récrite et placée au début du document.
Dans les règles globales, l'élément documentRule
a été remplacé par des éléments qui ont des noms spécifiques
de catégories de données. Cela facilite la création et la validation des règles globales.
Dans les règles globales, au lieu d'attributs spécifiques de règles pour la sélection, il n'y a maintenant que l'attribut selector.
Dans les règles globales, l'élément documentRules
a été renommé en rules.
Dans les règles globales, en plus de la fonctionnalité existante d'ajout d'information ITS aux nœuds sélectionnés, une nouvelle fonctionnalité de pointage vers de l'information dans un document XML a été créée.
Un attribut XLink href a été ajouté à l'élément rules pour permettre des liens vers des règles externes. La priorité entre les sélections a été modifiée pour refléter ce changement.
Deux nouvelles catégories de données, Information de langue et Éléments dans du texte ont été définies.
La catégorie de données Ruby a été redéfinie, pour une conformité avec [Ruby-TR].
Les déclarations de balisage ITS ont été récrites pour adopter les changements mentionnés précédemment.
Les déclarations de balisage ITS (précédemment toutes rassemblées dans une seule section) ont été séparées et placées dans les sections où elles sont décrites.
Une modularisation de ITS et XHTML 1.0 a été créée.
Les sections informatives 1 Introduction et 2 Les concepts de base ont été récrites.
Les exemples et les modularisations de ITS avec les schémas de balisage existants ont changé pour refléter les modifications mentionnées précédemment.
Le journal suivant répertorie les changements majeurs apportés à ce document entre la publication en avril 2006 et la publication en mai 2006.
La section conformité a été récrite.
La terminologie du mappage des catégories de données ITS au balisage existant est changé pour « association des catégories de données au balisage existant ».
Les éléments de règles globales ont été récrits pour admettre des attributs dans l'espace de noms vide.
Les exemples ont été validés, partiellement modifiés et étendus.
Du texte de documentation a été ajouté aux éléments et attributs.
La catégorie de données Éléments dans du texte a été redéfinie.
Des clarifications au sujet des mécanismes ITS d'inclusion et des sélections de pointeurs vers des objets externes (éventuellement non textuels) ont été faites.
Les attributs locaux ont été réorganisés en divers groupes spécifiques de catégories de données.
Un mécanisme de versionnage a été introduit.
Un récapitulatif du balisage ITS a été créé.
Les schémas ITS générés automatiquement ont été augmentés de documentations d'éléments et d'attributs.
Une description des contraintes de balisage ITS non couverte par les schémas ITS a été créée.
Les attributs termRef et termRefPointer ont été renommés en termInfoRef et termInfoRefPointer.
Une liste d'exigences formulées dans [ITS REQ], mais non couvertes dans ce document, a été créée. Cf. la section 1 Introduction.
Le journal suivant répertorie les changements majeurs apportés à ce document entre la publication en mai 2006 et la publication en novembre 2006.
En réponse à la question 3290 (Introduction too "positive" and not enough informative), la section 1 Introduction a été modifiée.
En réponse à la question 3293 (Conformance/Compliance), la section 4 La conformité a été changée.
En réponse à la question 3318 (Clarify "within text" data category), la définition de la catégorie de données Éléments dans du texte a été clarifiée et illustrée par des exemples.
En réponse à la question 3321 (Relation of terminology data category to existing standards for terminology), la relation a été décrite dans la section 6.4.1 Définition.
En réponse à la question 3323 (Version of XPath: Write "XPath 1.0 or its successor"), la référence à [XPath 1.0] a été remplacée par « [XPath 1.0] ou ses successeurs ».
En réponse à la question 3330 (lro and rlo explanation), une explication a été modifiée dans la section 6.5.1 Définition.
En réponse à la question 3456 (Attribute used for locInfo), une note a été ajoutée à la fin de la section 6.3.2 Mise en œuvre.
En réponse à la question 3457 (RFC 3066bis), la référence à « RFC 3066bis » a été remplacée par « RFC 4646 ou ses successeurs ».
En réponse à la question 3458 (Default translate value), les valeurs par défaut ont été rendues explicites dans la section 6.2.2 Mise en œuvre.
En réponse à la question 3459 (Use of elements), le balisage ITS est maintenant explicitement permis dans un autre balisage ITS.
En réponse à la question 3460 (Loc Info or Loc Note), tous les attributs et éléments commençant par « locInfo » ont été renommés « locNote ».
En réponse à la question 3461 (Role of termInfo), la section 6.4.1 Définition a été clarifiée.
En réponse à la question 3462 (Pointing to terms) la section 6.4.2 Mise en œuvre a été clarifiée.
En réponse à la question 3463 (termInfoRef should allow for id strings), l'attribut termInfoPointer a été ajouté.
En réponse à la question 3464 (Allowing for XPath expressions to point to term definitions), l'attribut termInfoPointer a été ajouté.
En réponse à la question 3465 (Default is ltr), la 6.5.2 Mise en œuvre a été clarifiée.
En réponse à la question 3466 (Existing ruby markup), la section 3.5 L'utilisation d'identificateurs de ressources internationalisés dans ITS a été ajoutée, la clause de conformité 2-2 a été supprimée, la référence à [Ruby-TR] a été clarifiée et déplacée dans la section 6.6.2 Mise en œuvre et la définition de la catégorie de données Directionnalité a été clarifiée dans la section 6.5.1 Définition.
En réponse à la question 3467 (rubyText is an attribute),
l'attribut rubyText
a été changé pour l'élément rubyText.
En réponse à la question 3468 (xml:lang missing), une note à la fin de la section 6.7.1 Définition a été ajoutée.
En réponse à la question 3469 (Example 19 xml:lang),
le rôle de l'attribut xml:lang
de la catégorie de données Information de langue
a été clarifié dans la section 6.7.1 Définition.
En réponse à la question 3473 (Language information data category overview), le rôle de l'élément langRule a été clarifié dans la section 6.7.1 Définition.
En réponse à la question 3479 (exemple n° 33), l'exemple n° 38 (qui était l'exemple n° 33) a été modifié.
En réponse à la question 3480 (Language information data category overview),
le rôle de l'attribut xml:lang
de la catégorie de données Information de langue
a été clarifié dans la section 6.7.1 Définition.
En réponse à la question 3481 (Translatability), la catégorie de données « Translatability » a été renommée en « Traduire ».
En réponse à la question 3482 (Inheritance of translation information), le rôle de l'héritage de l'information de traduction dans les règles globales a été rendu explicite dans la section 6.2.2 Mise en œuvre.
En réponse à la question 3487 (Invert translate examples), l'exemple n° 23 a été modifié.
En réponse à la question 3488 (6.3 ed 1), la section 6.3.1 Définition a été modifiée.
En réponse à la question 3489 (Mention translation tools), une référence à des outils de traduction a été ajoutée dans la section 6.3.1 Définition.
En réponse à la question 3490 (Examples 22 and 23), l'exemple n° 24 (qui était l'exemple n° 22) et l'exemple n° 25 (qui était l'exemple n° 23) ont été modifiés.
En réponse à la question 3491 (Explanations for examples), les exemples dans la section 6.3.2 Mise en œuvre ont été clarifiés.
En réponse à la question 3492 (Examples 24), l'exemple n° 26 (qui était l'exemple n° 24) a été modifié.
En réponse à la question 3493 (Marks terms and meanings), le but de la catégorie de données Terminologie a été clarifié dans la section 6.4.1 Définition.
En réponse à la question 3494 (termInfoRefPointer referent's data),
l'explication de l'attribut termInfoRefPointer
a été clarifié dans la section
6.4.2 Mise en œuvre.
En réponse à la question 3495 (Hard to know what this is about), la section 6.8 Éléments dans du texte a été clarifiée.
En réponse à la question 3496 (Standardized wording), toutes les sous-sections dans 6 La description des catégories de données ont été reformulées pour cohérence.
En réponse à la question 3497 (No implementation section), une section mise en œuvre (6.7.2 Mise en œuvre) a été ajoutée pour la catégorie de données Information de langue.
En réponse à la question 3498 (Repetition), la section 6.5.1 Définition a été modifiée.
En réponse à la question 3499 (Is dir mandatory?), le caractère obligatoire de l'attribut dir dans l'élément dirRule a été rendu explicite (cf. la section 6.5.2 Mise en œuvre).
En réponse à la question 3500 (Avoid xml:lang='he'), la section 5.2.2 La sélection locale dans un document XML (spécialement exemple n° 15) a été modifié.
En réponse à la question 3501 (Some Hebrew quotation), la section 6.5.2 Mise en œuvre a été modifiée.
En réponse à la question 3502 (exemple n° 30), l'exemple n° 33 (qui était l'exemple n° 30) a été modifié.
En réponse à la question 3503 (Refer to bidi article), une référence à [Bidi Article] dans la section 6.5.1 Définition a été ajoutée.
En réponse à la question 3504 (Example 31 lacks rp), l'exemple n° 37 (qui était l'exemple n° 31) a été modifié.
En réponse à la question 3505 (Use Japanese in Example 31), l'exemple n° 37 (qui était l'exemple n° 31) a été modifié.
En réponse à la question 3506 (Make the application of legacy ruby clearer), la section 6.6.2 Mise en œuvre a été modifiée.
En réponse à la question 3507 (In the case of no selection), la section 6.6.2 Mise en œuvre a été modifiée.
En réponse à la question 3508 (Example 32 head), l'exemple n° 36 (qui était l'exemple n° 32) a été modifié.
En réponse à la question 3509 (Too many places to look), la section 5.1 Récapitulatif du balisage ITS a été changée pour Annexe C Récapitulatif du balisage ITS, et la section 6 La description des catégories de données a été reformulée.
En réponse à la question 3510 (Spell out the attributes), la section 5.2.1 La sélection globale avec des règles a été modifiée pour lister les attributs pertinents.
En réponse à la question 3511 (Example 14 translate), l'exemple n° 15 (qui était l'exemple n° 14) a été modifié.
En réponse à la question 3512 (Example 14 dir), l'exemple n° 15 (qui était l'exemple n° 14) a été modifié.
En réponse à la question 3513 (ITS markup must be integrated), le caractère optionnel du balisage ITS dans le(s) fichier(s) cibles a été rendu explicite dans la section 5.5 L'association des catégories de données ITS au balisage existant.
En réponse à la question 3514 (Attributes missing?), les attributs disponibles pour une utilisation locale ont été énumérés dans l'annexe C : Récapitulatif du balisage ITS.
En réponse à la question 3515 (xml:lang = language info, please),
le rôle de xml:lang
a été clarifié dans la section 6.7.1 Définition.
En réponse à la question 3516 (Editorial comments on ITS), les sections 1 Introduction, 2 Les concepts de base, 3 La notation et la terminologie et 6 La description des catégories de données ont été modifiées.
En réponse à la question 3612 (Missing term="yes|no" in termRule element), la valeur "no" a été rétablie pour l'attribut term.
En réponse à la question 3640 (Need to handle inheritance for terminology), la description de l'héritage / des valeurs par défaut / du comportement de prédominance des catégories de données a été clarifiée 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.
En réponse à la question 3803 (Both selector and the rbPointer attributes are base text in rubyRule),
l'attribut rbPointer
a été supprimé.
Le journal suivant répertorie les changements majeurs apportés à ce document entre la publication en novembre 2006 et celle de janvier 2007.
En réponse à la question 3319 (Namespace binding mechanism), supprimé l'élément ns.
En réponse à la question 4096 (Inheritance and overriding needs to be made clearer), changé la formulation.
En réponse à la question 4098 (Need to make more explicit: what is possible with XSLT patterns realizing ITS selectors?), ajouté une note à propos du sous-ensemble de XPath dans XSLT dans la section 2.1.2 L'approche globale.
En réponse à la question 4099 (Format for implementation output needs to be clear), ajouté une note sur le traitement du jeu d'essais ITS version 1.0 à la section 4.2 La conformité de type 2 : Les attentes de traitements du balisage ITS.
En réponse à la question 4152 (Need to make explicit that ITS attributes at its:span are not namespace qualified), créé deux groupes d'attributs ITS, ceux qualifié par un espace de noms et ceux non qualifiés par un espace de noms, le dernier groupe utilisé avec l'élément ITS span et le premier avec les éléments étrangers à l'espace de noms ITS.
En réponse à la question 4289 (Various mainly editorial changes), décrit les changements éditoriaux dans la question.
En réponse à la question 4290 (Create appendix about NVDL), introduit l'annexe F : La vérification du balisage ITS avec NVDL.
En réponse à la question 4291 (Have version attribute at its:rules element in no namespace), placé l'attribut ITS version sur l'élément rules dans aucun espace de noms.
En réponse à la question 4293 (Editorial fix in sec. 6.6.2), supprimé les puces des listes.
En réponse à la question 4294 (Add xlink:type to its:rules element), ajouté l'attribut XLink type à l'élément rules.
En réponse à la question 4295 (Change of XPath expressions in Schematron example), mis à jour l'annexe E : La vérification des contraintes du balisage ITS avec Schematron.
En réponse à la question 4322 (Editors to go to the draft and check that there are no "CSS style elements" or the like), supprimé le texte lié aux éléments de style CSS.
Le journal suivant répertorie les changements majeurs apportés à ce document entre la publication en février 2007 et celle de mars 2007.
En réponse aux commentaires reçus pendant la revue par l'AC (accès réservé aux membres), fait les changements suivants : remplacé les exemples n° 3 (EX-ways-to-use-its-1.xml), n° 4 (EX-ways-to-use-its-2.xml), n° 5 (EX-ways-to-use-its-3.xml), n° 6 (EX-ways-to-use-its-4.xml) et n° 7 (EX-ways-to-use-its-5.xsd) par d'autres ; mis à jour la bibliographie.
Réparé diverses erreurs (orthographe, etc.) dans les exemples.
Vérification orthographique générale.
Mis à jour la référence pour l'identification de la langue dans la section 6.7 Information de langue.
Ce document a été développé avec les contributions du groupe de travail ITS : Damien Donlon (Sun Microsystems, Inc.), Martin Dürst (expert invité par le W3C), Poonam Gupta (Centre for Development of Advanced Computing (CDAC)), Richard Ishida (W3C/ERCIM), Jirka Kosek (expert invité par le W3C), Christian Lieske (SAP AG), Sebastian Rahtz (expert invité par le W3C), Francois Richard (HP), Goutam Saha (Centre for Development of Advanced Computing (CDAC)), Felix Sasaki (W3C/Keio), Yves Savourel (ENLASO Corporation), Diane Stoick (The Boeing Company), Najib Tounsi (Ecole Mohammadia d'Ingenieurs Rabat (EMI)), Andrzej Zydron (expert invité par le W3C).
Un remerciement particulier à Sebastian Rahtz qui nous a présenté le langage ODD, utilisé pour créer ce document, et qui nous a fourni les feuilles de style pour générer les schémas et la version XHTML d'après un document ODD. La génération du XHTML à partir d'un document ODD requiert une étape intermédiaire à travers le fichier xmlspec-i18n.dtd.