JSesh Documentation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Annexe B : Informations techniques sur le fichier de description des signes ======

Attention : contenu techniquement explicite. Âmes pures, détournez les yeux. Un système plus convivial a été créé.

Alternativement, vous pouvez éditer directement votre fichier de description de fichier. Vous avez besoin d'une sorte d'éditeur simple pour faire cela : le bloc-notes peut faire l'affaire sur Windows, et des logiciels comme TextWrangler peuvent être utilisés sur Mac OS X. Les fichiers XML sont constitués de texte brut.

JSesh n'acceptera pas les fichiers mal formés, vous risquez donc de ne pas pouvoir lancer JSesh. Si c'est le cas, corrigez le fichier sign_definition.xml ou renommez-le en quelque chose d'autre, afin qu'il soit ignoré. À l'avenir, j'ajouterai un éditeur convivial, mais je ne le ferai pas tant que le format ne sera pas complètement défini.
Le fichier doit avoir la forme suivante :
<code>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE signe PUBLIC "-//ORG/QENHERKHOPESHEF//DTD SIGNDESCRIPTION 1.0" "sign_description.dtd">
<signes>

<!-- voici vos définitions de signes -->

</signes>
</code>

Il est important d'avoir exactement ce contenu, en particulier la ligne DOCTYPE.

Voici un petit exemple (en fait, une partie du fichier de description de signe standard JSesh). Ce dossier décrit les signes C1 et C1A. Vous voyez qu'ils sont classés dans un certain nombre de catégories. Ce sont à la fois des divinités à tête humaine et des personnages assis. La translittération de C1 est donnée. Nous en avons également fourni un pour C1A. Le code ''"relevance='1'"'' signifie que cette translittération est ici uniquement à titre informatif. En fait, le format XML a été préparé pour accueillir beaucoup de données différentes, ce qui n'est pas encore vraiment utilisé par JSesh, et je suis très intéressé par des suggestions à ce sujet. La définition du format (son "dtd") est donnée juste après cette annexe.
<code>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE signe PUBLIC "-//ORG/QENHERKHOPESHEF//DTD SIGNDESCRIPTION 1.0" "sign_description.dtd">
<signes>

<!-- Comme C est actuellement la partie la plus complète des polices JSesh, nous essayons de la couvrir entièrement. -->

<tagCategory tag="divinité à tête humaine" label="divinité à tête humaine"/>
<tagCategory tag="divinité à tête de faucon" label="divinité à tête de faucon"/>
<tagCategory tag="divinité à tête d'ibis" label="divinité à tête d'ibis"/>
<tagCategory tag="divinité à tête de bélier" label="divinité à tête de bélier"/>

<signe signe="C1">
 <hasTranslitteration sign="C1" translitteration="ra"/>
 <hasTag tag="divinité à tête humaine"/>
 <hasTag tag="assis"/>
 <contient partCode="N6"/>
</sign>

<signe signe="C1A">
 <similarTo baseSign="C1"/>
 <hasTranslitteration translitteration="ra" pertinence="1"/>
 <hasTag tag="divinité à tête humaine"/>
 <hasTag tag="assis"/>
 <contient partCode="N6"/>
 <contient partCode="S40"/>
</sign>
</signes>
</code>
Notez que les balises doivent être définies avant d'être utilisées (comme tagCategory). Une balise a un nom et une étiquette ; il est en effet possible de définir des étiquettes dans plusieurs langues, bien que cela ne soit pas vraiment utilisé par JSesh maintenant.

===== Signer la description DTD =====

Pour les plus techniques, voici la DTD actuelle utilisée pour les descriptions des enseignes. Il est encore expérimental, et a déjà changé depuis la version 2.4.13.

<code>
<!-- DTD utilisé pour décrire les caractéristiques des signes. -->
<!-- NOM DU CATALOGUE : "-//ORG/QENHERKHOPESHEF//DTD SIGNDESCRIPTION 1.0" -->

<!ENTITY % signInfo "variantOf|hasTransliteration|partOf|contains|signDescription|isDeterminative|hasTag|phantom"
>

<!ELEMENT signes (sign|determinativeCategory|tagCategory|tagLabel|%signInfo;)*>

<!-- L'élément sign est facultatif, mais permet d'avoir un fichier mieux structuré. -->

<!ELEMENT sign (%signInfo;)* >

Signe <!ATTLIST
    signer CDATA #REQUIS
 toujoursAfficher (y|n) 'n'
>

<!--
 La notion de variante utilisée ici est en quelque sorte ad-hoc.
 Le problème des variantes est qu'il y a deux notions différentes derrière, toutes deux utiles dans notre logiciel.
 La première notion est la variante LINGUISTIQUE. Un signe est une variante linguistique d'un autre s'il a les mêmes usages.
 Par exemple, Y2 est une variante linguistique de Y1. Maintenant, Y2 "ressemble" également à Y1. Nous l'appellerons une "variation graphique".
 Les deux notions sont indépendantes, bien que statistiquement liées. Par exemple, Z7 est une variante linguistique de G43, mais pas un
 variation graphique de celui-ci.

 la notion de "ressembler" à un autre signe est couverte par l'attribut "isSimilar".

 Dans de nombreux cas, notamment pour les déterminatifs, les signes ne sont pas toujours entièrement substituables les uns aux autres.
 Pour permettre l'utilisation d'informations « variantes » dans les recherches, nous introduisons l'attribut « linguistique ».

 soit B une variante de A.
 "complet" signifie que toutes les utilisations de B sont également des utilisations possibles de A, et toutes les utilisations de A sont des utilisations de B.
 "autre" signifie que B est plus spécifique que A, ou que le degré est inconnu
 « partiel » signifie que les utilisations de A et B se recoupent, mais elles ont également toutes deux des utilisations très différentes.
  Par exemple, le signe D36 (ayin) est une variante partielle de D37 (di), car D36 peut écrire "di". Pourtant,
  dans ce cas, je ne considérerais pas le D37 comme une variante du D36, car cela ferait plus de mal que de bien.
 « non » est utilisé lorsque le signe n'est pas du tout une variante linguistique. Dansdans ce cas, isSimilar est normalement "y".

-->

<!ELEMENT variantOf EMPTY>
<!ATTLIST variantOf
 signer CDATA #IMPLICITE
 baseSign CDATA #REQUIS
 estSimilaire (y|n) 'y'
 linguistique (complet|partiel|autre|non|non spécifié) 'non spécifié'
>



<!ELEMENT hasTransliteration EMPTY>
<!-- le but principal de la translittération est d'aider quelqu'un à trouver un signe. -->
<!-- quelques informations supplémentaires aident ici -->
<!--
    l'attribut "use" explique où la translittération sera visible dans JSesh.
 « clavier » signifie que le signe est typique de cette translittération, c'est-à-dire qu'il doit être utilisé
 dans le logiciel principal lorsque vous utilisez « espace » pour faire le tour des signes possibles.
 « palette » signifie que le signe est une valeur pas trop inhabituelle pour une translittération donnée.
 il doit être accessible via la palette.
 « informatif » signifie que la valeur est ici à des fins d'information uniquement.

 type permet de spécifier d'où vient la valeur. Il se peut qu'un signe soit un vrai
 phonogramme (par exemple G1 pour aleph), ou un idéogramme, ou une abréviation, ou simplement être typique de certains mots (par exemple "bin" n'est pas
 vraiment une valeur pour G37 ; mais c'est typique. G37 est cependant une abréviation connue pour Sri.
-->

<!ATTLIST hasTransliteration
 signer CDATA #IMPLICITE
 translittération CDATA #REQUIS
 utiliser (clavier|palette|informatif) 'clavier'
 type (phonogramme|idéogramme|abréviation|typique) 'phonogramme'
>

<!ELEMENT hasShape EMPTY>
<!ATTLIST hasShape
 signer CDATA #IMPLICITE
 forme (tallNarrow|lowBroad|lowNarrow) #REQUIS
 commander CDATA #IMPLICITE
>

<!ELEMENT partOf EMPTY>
<!ATTLIST partOf
 signer CDATA #IMPLICITE
 baseSign CDATA #REQUIS
>

<!-- Plus facile à utiliser (et à déclarer) que isPartOf -->

<!ELEMENT contient EMPTY>
<!ATTLIST contient
 signer CDATA #IMPLICITE
 partCode CDATA #REQUIS
>


<!ELEMENT determinativeCategory EMPTY>
<!ATTLIST determinativeCategory
 catégorie CDATA #REQUIS
 lang NMTOKEN 'fr'
 label CDATA #REQUIS
>

<!ELEMENT isDeterminative EMPTY>
<!ATTLIST isDeterminative
 signer CDATA #IMPLICITE
 catégorie CDATA #REQUIS
>

<!ELEMENT hasTag VIDE>
<!ATTLIST hasTag
 signer CDATA #IMPLICITE
 tag CDATA #REQUIS
>

<!-- Déclare une balise (sans aucune étiquette) -->
<!ELEMENT tagCategory (tagLabel)*>
<!ATTLIST tagCatégorie
 tag CDATA #REQUIS
>

<!-- Déclare une étiquette pour une balise. -->
<!ELEMENT tagLabel VIDE>
<!ATTLIST tagLabel
 tag CDATA #IMPLICITE
 lang NMTOKEN 'fr'
 label CDATA #REQUIS
>

<!-- description du signe, au format manuel de codage.
  - lang peut être utilisé pour décrire la langue. Utilisateur "fr" pour le français, "de" pour l'allemand...
-->
<!ELEMENT signDescription (#PCDATA)>
<!ATTLIST signeDescription
 signer CDATA #IMPLICITE
 lang CDATA 'fr'
>

<!-- Un fantôme est un code redondant. Il précise qu'un code donné est l'équivalent exact d'un autre.
     Cela peut être utilisé à des fins de normalisation. Par exemple, il y a quelques signes qui ont des encodages différents
     dans winglyph, JSesh et Inscribe. L'utilisation du fantôme a) évite d'avoir plusieurs signes
     et b) permet de créer un texte normalisé.
-->

<!ELEMENT fantôme VIDE>
<!ATTLIST fantôme
 baseSign CDATA #REQUIS
 existe dans CDATA 'jsesh'
>
</code>
JSesh Documentation

User Tools

Site Tools

Page Tools
