Drafted first part on train from Paris to La Souterraine;l then lost half of it by shutting lid in a hurry without saving first : doh.
@@ -26,10 +28,10 @@
À quoi ça sert ?
Ce court guide est destiné à expliquer le mécanisme du ODD chaining. Un fichier ODD spécifie une utilisation de la TEI en sélectionnant des éléments ou des attributs particuliers, etc. dans l’ensemble de la TEI. Mais il est également possible de rafiner encore plus cette spécification en faisant dériver votre ODD les uns des autres. En principe, vous pouvez chaîner des ODDs ensemble de cette manière autant que vous le souhaitez. Vous pouvez employer cette fonctionnalité de différentes manières :
- - vous pouvez ajouter des restrictions additionnelles à un ODD existant, par exemple pour modifier la liste des valeurs possibles d’un attribut
- - vous pouvez réduire le sous-ensemble d’éléments produits par un ODD existant
- - vous pouvez ajouter de nouveaux éléments ou des modules à un ODD existant
-
+
- vous pouvez ajouter des restrictions additionnelles à un ODD existant, par exemple pour modifier la liste des valeurs possibles d’un attribut
+
- vous pouvez réduire le sous-ensemble d’éléments produits par un ODD existant
+
- vous pouvez ajouter de nouveaux éléments ou des modules à un ODD existant
+
Comment ça marche ?
@@ -38,21 +40,26 @@
Traitement d’un ODD
-
Regardons d’un peu plus près la manière dont la TEI définit un schéma très léger appelé TEI Bare. Son élément de spécification de schéma commence comme suit :
-
-
+
Regardons d’un peu plus près la manière dont la TEI définit un schéma très léger appelé TEI Bare.
+ Son élément de spécification de schéma commence comme suit :
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Aucune attribut source n’est spécifié, ainsi la les déclarations des éléments demandés seront prises dans le fichier courant p5subset.xml.
-
Notez que cet ODD contient à la fois des références et des spécifications : il continet des références à des modèles (qui peuvent être conçues comme des raccourcis pour des références à des éléments ou des classes, dès lors qu’un module n’est rien d’autre qu’une collection de spécifications d’éléments et de classes) et des spécifications pour deux classes (classSpec), plutôt que des références (classRef). La référence au module tei contenue dans cette spécification icnlue la plupart des classes de la TEI, y compris ces deux classes-là. Un processeur ODD devra alors résoudre les spécifications de classe dupliquées pour les classes att.global et att.fragmentable. La solution requise est indiquée par la valeur de l’attribut mode : si celle-ci est delete alors les deux déclarations seront ignorées, et la classe est supprimée ; si sa valeur est change alors les deux déclarations seront mélangées de sorte que les parties spécification présentes dans la seconde spécification écrasent les premières. Dans ce cas, l’effet sera de supprimer les trois attributs mentionnés.
-
Vous pouvez vérifier que cet ODD fait bien ce que vous attendez, si vous avez une d’oXygen installée avec une version récente du TEI Frameworks, téléchargez simplement le fichier tei_bare.odd, et demandez à oXygen de lui appliquer la transformation prédéfinie TEI ODD to HTML. Cela va produire un mini-manuel pour la personnalisation TEI Bare au format HTML au début de laquelle vous pourrez consulter la liste des éléments que le schéma contient.
Vous pouvez alors vérifier que les modifications de la classe d’attribut att.global indiquées ci-dessus ont bien été exécutées en consultant cette documentation.
Supposez maintenant que nous avons une version compilée de TEI_bare dans un fichier nommé TEI_bare.compiled.xml. Le traitement de la spécification de schéma suivante produirait alors exactement le même résultat que nous aurions obtenu d’une version non compilée.
-
-
-
-
-
-
+
+
+
+
+
+
Cela fonctionne car chaqu’une des éléments moduleRef ici réfèrent au module (i.e. ensemble d’éléments, etc.) disponible dans l’ODD compilé plutôt qu’aux modules définis dans l’ensemble de la TEI. Notez aussi que seulement fournir l’ODD compilé comme source d’un schema n’est pas suffisant : nous devons aussi spécifier laquelle des déclarations elle contient nous voulons utiliser : nihil ex nihilo fit...!
Cependant, la raison pour laquelle nous nous sommes engagés sur cette voie n’était pas de pouvoir faire d’une autre manière ce que nous pouvions déjà faire autrement. Produisons maintenant une version réduite de TEI Bare dans laquelle l’élément head serait manquant.
-
-
-
-
-
-
+
+
+
+
+
+
Et juste pour la complétude, voici une autre manière d’arriver au même effet :
-
-
-
-
-
-
-
- Notez qu’on ne peut supprimer ou modifier que les choses qui sont déjà présentes dans l’ODD compilé spécifié par l’attribut source. Cette approche du chaînage est bien adaptée dans une situation où nous définissons d’æbrod un DODD qui combine tous les éléments (etc.) que nous envisageons d’utiliser et que nous dérivons ensuite un sous-ensemble particulier à partir d’eux. Par exemple, un pour les manuscrits, un pour les imprimés de la Renaissance, un pour les imprimés contemporains, etc. (Cette approche a, par exemple, été adoptée par la Deutsches Text Archive.)
Chaînage : super-ensemble
-
Mais le chaînage ODD n’est pas restreint à la définition de sous-ensembles. Supposez que nous voulions prendre le schéma existant TEI Bare et ajouter des déclarations d’autres modules. Nous pourrions bien sûr laborieusement copier toutes les déclarations dont nous avons besoin dans notre schemaSpec, mais cela serait bien plus élégant d’avoir de ne pas avoir à faire ça. Supposez, par exemple, que nous voulions ajouter tout ce qui est founi par le module gaiji. Ce module n’était pas inclus lorsque nous avons défini notre version compilée de TEI Bare, toutefois il est évidemment disponible dans l’ensemble de la TEI. Voici une manière de faire :
+
Mais le chaînage ODD n’est pas restreint à la définition de sous-ensembles. Supposez que nous voulions prendre le schéma existant TEI Bare et ajouter des déclarations d’autres modules. Nous pourrions bien sûr laborieusement copier toutes les déclarations dont nous avons besoin dans notre schemaSpec, mais cela serait bien plus élégant d’avoir de ne pas avoir à faire ça. Supposez, par exemple, que nous voulions ajouter tout ce qui est fourni par le module gaiji. Ce module n’était pas inclus lorsque nous avons défini notre version compilée de TEI Bare, bien qu'il est évidemment disponible dans l’ensemble de la TEI. Voici une manière de faire :
-
-
-
-
-
-
-
Le moduleRef qui va cherche le module gaiji utilise son propre attribut source pour spécifier où aller cherche les déclarations de ce module. Cele ne ferait pas sens d’aller les chercher dans tei_bare.compiled.odd : ils n’y sont pas. Au lieu de cela, ici celles-ci sont collectées depuis une copie en ligne d’un ODD compilé qui fournit l’ensemble des Guidelines TEI. Bien sûr, nous aurions aussi pu également réaliser la définition d’un sous-ensemble. Par exemple :
+
+
+
+
+
+
+
Le moduleRef qui va rechercher le module gaiji utilise son propre attribut source pour spécifier où trouver les déclarations de ce module. Cela ne ferait pas sens d’aller les chercher dans tei_bare.compiled.odd : elle n’y sont pas. Au lieu de cela, on va les retrouvées depuis une copie en ligne d’un ODD compilé qui fournit l’ensemble des Guidelines TEI. Bien sûr, nous aurions aussi pu en meme temps réaliser la définition d’un sous-ensemble. Par exemple :
-
-
-
-
-
-
+
+
+
+
+
+
Cet ODD nous donnera tout ce qui est disponible dans tei_bare avec les g, char, et glyph tirés par défaut du module gaiji. Nous pourrions parvenir au même effet en nommant explicitement les élements dont nous avions besoin, de nouveau en spécifiant où ceux-ci devraient être trouvés :
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
On peut employer cette technique pour ramener un élément qui a été effacé du schéma compilé. Par exemple, l’élément q n’est pas disponible avec TEI Bare, mais il peut facilement être rétabli. Nous pouvons même spécifier quelle version de l’élément q est souhaitée : dans ce cas, nous irons chercher la version définie dans la distribution 3.0.0 de la TEI P5 :
-
-
-
-
-
-
+
+
+
+
+
+
+
Il existe un tableau utile répertoriant les dates et les numéros de version de toutes les versions de TEI P5 au [TEI website](https://tei-c.org/guidelines/P5/).
+
Un cas d'usage
+
Supposons que vous mettiez en place une application de crowdsourcing pour la transcription de documents d'archives de quelque nature que ce soit. Une fois les documents capturés et légèrement étiquetés, vous envisagez d'enrichir les archives avec des métadonnées détaillées décrivant les personnes et les lieux qui y sont mentionnés. Vous prévoyez donc d'avoir besoin de deux schémas : un (très simple et contraint) pour valider les fichiers de transcription, et un autre (également très contraint, mais différemment) pour valider les métadonnées. Mais bien sûr, vous devrez également valider les documents complétés, combinant les deux types de données. Et il y a certaines fonctionnalités (paragraphes, titres, etc.) communes aux deux, ce qui suggère que vous aurez également besoin d'un troisième schéma... Le chaînage ODD est la réponse !
+ (Avant de poursuivre votre lecture, je vous suggère de télécharger [notre petit ensemble de fichiers d'exemple](chainingTuto.zip) et de lancer votre processeur XML préféré. Veuillez noter que ces fichiers d'exemple sont simplement destinés à démontrer l'effet du chaînage : dans une application réelle, on personnalise son schéma beaucoup plus précisément, par exemple en supprimant les attributs inutiles, en simplifiant les modèles de contenu, en ajoutant différents exemples, etc.)
+ Il nous faudra définir le troisième schéma, qui contient tout ce qui est susceptible d'être utile à l'un ou l'autre des deux autres, plus tout ce qui est commun aux deux. Appelons celui-ci notre mère ODD. Ouvrez le fichier motherODD.xml et vous verrez un ODD typique, avec l'élément racine TEI, défini en référence aux directives TEI complètes. En plus du module d'infrastructure tei, il contient des éléments tels que pb, p, hi, div, et name du module core, ainsi que l'ensemble de métadonnées que nous prévoyons d'utiliser pour chaque document TEI valide, qui prend ses composants des modules header, namesdates, et corpus.
+ Nous définirons nos deux schémas plus spécialisés en référence à celui-ci. Nous devons donc compiler le motherODD, le transformant effectivement en une collection ou une bibliothèque de spécifications TEI complètes. Nous faisons cela en exécutant la transformation odd2odd mentionnée ci-dessus : les résultats de notre fichier exemple se trouvent dans le fichier motherODD.compiled.
+ Jetez maintenant un œil aux deux sous-ensembles ODD différents dans notre exemple : un (justTranscripts.xml) pour les transcriptions et un (justMetadata.xml) pour les métadonnées. Notez que chacun de ces fichiers ODD fait référence à motherODD.compiled au moyen de son attribut source. Notez également que chacun d'eux spécifie un élément racine différent : ceci afin que l'on puisse utiliser les schémas résultants pour valider une transcription sans en-tête, ou un en-tête sans transcription.
+ Essayez de traiter chacun de ces fichiers ODD pour générer de la documentation et un schéma, de la manière habituelle. Comparez ensuite les résultats. Nous avons inclus quelques exemples de fichiers de données pour vous permettre de vérifier que la validation fonctionne comme elle le devrait : le fichier transcription.xml doit être valide par rapport au schéma généré à partir de l'ODD justTranscription.xml et le fichier metadata.xml doit être valide par rapport au schéma généré à partir de l'ODD justMetadata.xml. Notre exemple suppose un flux de travail particulier dans lequel, par exemple, l'attribut ref est utilisé pour associer des éléments name a un élément person ou place dans l'en-tête ; votre kilométrage peut bien sûr varier.
+
Enfin, jetez un œil au fichier driver.tei : il utilise xInclude pour combiner les deux fichiers en un document TEI complet, qui devrait être valide par rapport au schéma généré à partir du motherODD. Encore une fois, n'hésitez pas à modifier si nécessaire en fonction de vos propres pratiques de travail !
+
+
+
+
+
+
+
+
+
+ TEI P5 version 4.7.0 and Stylesheets version 7.56.0 release notes
+
+
+
+ Thursday, 16 November 2023
+
+
+
+ The Text Encoding Initiative
+
+
+ Created retrospectively from ChangeLog and GitHub trackers
+
+
+
+
+
+ Release 4.7.0 is codenamed in nova fert animus
.
+ This release introduces new features and resolves a number of issues raised by the TEI
+ community. As always, the majority of these changes and corrections are a consequence of
+ feature requests or bugs reported by the TEI community using the GitHub tracking system. A
+ full list of the issues resolved in the course of this release cycle may be found under the
+ [4.7.0 milestone](https://github.com/TEIC/TEI/milestone/17?closed=1).
+ The following changes are particularly worth highlighting in this release:
+
+
+ New encoding features
+ - New with this release is the eventName element, which may be used to encode
+ names of events in general transcribed text, or in the event element. The new
+ eventName element also has membership in several attribute classes associated
+ with named entities, including att.datable to supply a date
+ range for the use of an event’s name, and att.typed, allowing
+ it type and subtype attributes. It is also a member of att.editLike, giving it the evidence attribute (
[#2382](https://github.com/TEIC/TEI/issues/2382)).
+ - The content model of event has been modified to contain eventName
+ elements, but still allows older ways of labeling events. See
[PR #2483](https://github.com/TEIC/TEI/pull/2483).
+ - The taxonomy and category elements are now added to att.datcat (
[#2419](https://github.com/TEIC/TEI/issues/2419)).
+
+
+
+ Changes to content models
+ - The content model of content has been changed to permit only one child
+ element from model.contentPart (
[#2381](https://github.com/TEIC/TEI/issues/2381)).
+ - At the request of the Manuscript SIG, the content model of additional is
+ now more flexible, permitting any alternation of model.pLike
+ (p or ab) instead of zero or one each of adminInfo,
+ surrogates, or listBibl (
[#2195](https://github.com/TEIC/TEI/issues/2195)).
+ - The content model of revisionDesc now permits multiple listChange
+ elements (
[#2420](https://github.com/TEIC/TEI/issues/2420)).
+ - A Schematron constraint has been added to the specification for dataSpec in
+ order to prevent the possibility of elements being included in the specification for an
+ attribute’s datatype (
[PR #2443](https://github.com/TEIC/TEI/pull/2443)
+ and [#2426](https://github.com/TEIC/TEI/issues/2426)).
+ - A scheme attribute is now optional on a constraintSpec
+ with a mode of either change or
+ delete (it is still required when mode
+ is add, replace, or unspecified — see
[PR
+ #2453](https://github.com/TEIC/TEI/pull/2453) and [#2261](https://github.com/TEIC/TEI/issues/2261)).
+ - The datatype of the class attribute on attRef has been changed
+ from teidata.word to teidata.name (
[#2276](https://github.com/TEIC/TEI/issues/2276)).
+
+
+
+ With these release notes we are beginning a practice of documenting changes that could
+ invalidate ODD customizations in TEI projects if they are working with the
+ current release of these TEI Guidelines. Those maintaining ODD customizations of the TEI may
+ want to be aware of the following changes and adapt your ODD files accordingly.
+ ODD-breaking changes and deprecation
+ - The calendar attribute has been removed from att.datable because it is supposed to designate information about a date
+ represented in an element’s contents, and thus should not be applied to elements that do not contain
+ dates. To clarify its intended usage, calendar has been moved to a new class,
+ att.calendarSystem, and its use is now deprecated on many
+ elements. The calendar attribute is now properly available only on
+ date, time, origDate, and docDate. See
[#2045](https://github.com/TEIC/TEI/issues/2045).
+
+
+
+
+ Improvements of prose and examples
+ - The title of the Guidelines section 2.2.8 has been changed to more accurately
+ reflect its content (
[#2415](https://github.com/TEIC/TEI/issues/2415)).
+ - Several revisions were applied to the explanation of TEI XPointer Schemas in the
+ Guidelines section 16.2.4 (
[#2083](https://github.com/TEIC/TEI/issues/2083)).
+ - A new example was added for langKnown (
[#2139](https://github.com/TEIC/TEI/issues/2139)).
+ - The examples for use of the key attribute are updated and a source
+ attribution corrected (
[#2144](https://github.com/TEIC/TEI/issues/2144)).
+ - Several Japanese translations have been added to element, attribute, and class
+ specifications (PRs
[#2448](https://github.com/TEIC/TEI/pull/2448),
+ [#2449](https://github.com/TEIC/TEI/pull/2449), and [#2461](https://github.com/TEIC/TEI/pull/2461)).
+ - Inconsistencies have been corrected in initial capitalization and initial spacing of
+ the French descriptions in element specifications (
[#2486](https://github.com/TEIC/TEI/issues/2486))
+ - Descriptions of the ident and usage attributes on the
+ language element have been improved (
[#2447](https://github.com/TEIC/TEI/issues/2447)).
+
+
+
+
+ Housekeeping
+ - Bugs have been corrected in the processing of Guidelines release notes to HTML
+ (
[#2070](https://github.com/TEIC/TEI/issues/2070)).
+ - The version
P5
is now properly represented in footers and headings of the
+ published TEI Guidelines on the web ([#2413](https://github.com/TEIC/TEI/issues/2413)).
+ - Bookmark links on examples in the Guidelines now feature mouseover text (
[#2137](https://github.com/TEIC/TEI/issues/2137)).
+
+
+
+ In addition, many improvements have been made to the XSLT stylesheets (which provide
+ processing of TEI ODD files for [Roma](https://romabeta.tei-c.org/) and
+ [TEIGarage](https://teigarage.tei-c.org/) as well as other TEI
+ conversions). The Stylesheets are maintained separately from the Guidelines at [https://github.com/TEIC/Stylesheets](https://github.com/TEIC/Stylesheets). A
+ full list of the issues resolved in the course of this release cycle may be found under the
+ [7.56.0
+ milestone](https://github.com/TEIC/Stylesheets/milestone/16?closed=1).
+
+ Highlights of this release include:
+
+ - Attributes shown on element and class specification pages are now formatted as
+ a vertical nested list to improve legibility
+ (
[PR
+ #619](https://github.com/TEIC/Stylesheets/pull/619) and
+ [#2489](https://github.com/TEIC/TEI/issues/2489)).
+ - A bug in Stylesheets ODD processing that had produced output files with multiple
+ superfluous filename extensions has now been corrected (
[Stylehsheets 543](https://github.com/TEIC/Stylesheets/issues/543)).
+ - A serious problem in the processing of ns attributes in ODD
+ customizations has been fixed (
[Stylesheets #424](https://github.com/TEIC/Stylesheets/issues/424)).
+ - The Guidelines now output the sch: prefix consistently when representing elements in
+ the Schematron namespace (
[Stylesheets #529](https://github.com/TEIC/Stylesheets/issues/529))
+ - A bug has been fixed in the ODD processing of more than one anyElement in a
+ content model so that it no longer generates an invalid Relax NG output (
[Stylesheets
+ #631](https://github.com/TEIC/Stylesheets/issues/631)).
+ - The xml:id on list elements is now properly being translated to
+ an HTML id attribute in HTML list container elements (Stylesheets
[#616](https://github.com/TEIC/Stylesheets/issues/616) and [PR #617](https://github.com/TEIC/Stylesheets/pull/617)).
+ - The teitohtml stylesheet now properly highlights val and tag
+ elements in HTML output (
[#567](https://github.com/TEIC/Stylesheets/issues/567)).
+ - Improvements and bug corrections have been applied to the docx to tei conversion
+ (Stylesheets
[#524](https://github.com/TEIC/Stylesheets/pull/524), [#610](https://github.com/TEIC/Stylesheets/issues/610), and PR [#634](https://github.com/TEIC/Stylesheets/pull/634)).
+
+
+
+
+
diff --git a/P5/Source/Guidelines/en/FM1-IntroductoryNote.xml b/P5/Source/Guidelines/en/FM1-IntroductoryNote.xml
index f07b2a8fb9..07464a05bb 100644
--- a/P5/Source/Guidelines/en/FM1-IntroductoryNote.xml
+++ b/P5/Source/Guidelines/en/FM1-IntroductoryNote.xml
@@ -42,7 +42,7 @@ $Id$
- 2012–2015: Elena Pierazzo (King's College London / Université Stendhal-Grenoble 3)
- 2016–2017: Michelle Dalmau (Indiana University)
- 2018–2021: Kathryn Tomasek (Wheaton College)
-
- 2022: Diane K. Jakacki (Bucknell University)
+
- 2022-2023: Diane K. Jakacki (Bucknell University)
@@ -53,6 +53,7 @@ $Id$
- 2012–2014: James Cummings (University of Oxford)
- 2015–2017: Hugh Cayless (Duke University)
- 2018–2022: Martina Scholger (University of Graz)
+ - 2023: Elisa Beshero-Bondar (Penn State Erie, The Behrend College)
@@ -72,7 +73,7 @@ $Id$
- 2011–2012: Piotr Bański (University of Warsaw)
- 2010–2013: Brett Barney (University of Nebraska)
- 2013–2023: Syd Bauman (Brown University / Northeastern University)
- - 2021–2022: Helena Bermúdez Sabel (Université de Neuchâtel)
+ - 2021–2025: Helena Bermúdez Sabel (Université de Neuchâtel / JinnTec)
- 2016–2024: Elisa Beshero-Bondar (University of Pittsburgh at Greensburg / Penn State Erie, The Behrend College)
- 2022: Elli Bleeker (Huygens Institute for the History of the Netherlands)
- 2019–2020: Vanessa Bigot Juloux (Ecole Pratique des Hautes Etudes / Paris Sciences et Lettres / Andrews University, Michigan)
@@ -102,6 +103,7 @@ $Id$
- 2002: Martin Mueller (Northwestern University)
- 2013–2014, 2016–2019: Elli Mylonas (Brown University)
- 2010–2011: Julianne Nyhan (University of Trier / University College London)
+ - 2023-2025: Patricia O Connor (Independent Researcher)
- 2008–2011: Elena Pierazzo (King's College London)
- 2006–2007, 2009–2010: Dot Porter (University of Kentucky / Digital Humanities Observatory / Indiana University)
- 2002–2003: Merillee Proffitt (Research Libraries Group)
@@ -117,6 +119,7 @@ $Id$
- 2004–2005: Natasha Smith (University of North Carolina at Chapel Hill)
- 2014–2022: Peter Stadler (Carl-Maria-von-Weber-Gesamtausgabe / University of Paderborn)
- 2017–2019: Sarah Stanley (Florida State University)
+ - 2023: Joey Takeda (Digital Humanities Innovation Lab, Simon Fraser University)
- 2008–2009: Manfred Thaller (University of Cologne)
- 2006–2007: Conal Tuohy (Victoria University of Wellington)
- 2016–2024: Magdalena Turska (eXist Solutions / University of Oxford)
@@ -167,6 +170,9 @@ these meetings were generously hosted by the following institutions:
- Short virtual meeting (May 2021)
- Short virtual meeting (October 2021)
- Short virtual (April 2022)
+ - Newcastle University (September 2022)
+ - University of Guelph (May 2023)
+ - Paderborn University (September 2023)
During the production of TEI P5, the Council chartered a number
diff --git a/P5/Source/Guidelines/en/TS-TranscriptionsofSpeech.xml b/P5/Source/Guidelines/en/TS-TranscriptionsofSpeech.xml
index 4126156226..c6385f2a2e 100644
--- a/P5/Source/Guidelines/en/TS-TranscriptionsofSpeech.xml
+++ b/P5/Source/Guidelines/en/TS-TranscriptionsofSpeech.xml
@@ -500,7 +500,7 @@ section .
An utterance may contain either running text, or text within which
other basic structural elements are nested. Where such nesting occurs,
the who attribute is considered to be inherited for the
-elements pause, vocal, shift and
+elements pause, vocal, shift, and
kinesic; that is, a pause or shift (etc.) within an utterance
is regarded as being produced by that speaker only, while a pause
between utterances applies to all speakers.
@@ -1472,4 +1472,4 @@ to divide a transcribed text up into meaningful analytic sections.
The scheme attribute is required when the value
- of mode is add or
- replace. The scheme attribute is
- permitted when the value of mode is
- delete, but these Guidelines make no reccomendation
- for what a processor should do if its value does not match
- that of the constraintSpec being deleted.
+ The scheme attribute is required when the value
+ of mode is add or
+ replace. The scheme attribute is
+ permitted when the value of mode is
+ delete, but these Guidelines make no reccomendation
+ for what a processor should do if its value does not match
+ that of the constraintSpec being deleted.
diff --git a/P5/Source/Specs/surface.xml b/P5/Source/Specs/surface.xml
index d07cce59b3..70ee7aa2f3 100644
--- a/P5/Source/Specs/surface.xml
+++ b/P5/Source/Specs/surface.xml
@@ -10,8 +10,7 @@ $Id$
defines a written surface as a two-dimensional
coordinate space, optionally grouping one or more graphic representations of
-that space, zones of interest within that space, and transcriptions of the
- writing within them.
+that space, zones of interest within that space, and, when using an embedded transcription approach, transcriptions of the writing within them.
직사각형의 좌표 공간과 그 내부에서 기록 표면부를 정의한다. 수의적으로 그 공간의 하나 이상의 그림 표상과 관심 있는 직사각형 공간을 모아놓는다.
define una superficie escrita en coordinadas rectangulares, agrupando opcionalmente una o más representaciones gráficas de ese espacio, y las zonas rectangulares de interés dentro de él.
矩形の座標により、書記の表面を定義する。選択的に、空間や矩形範囲中のひ
diff --git a/P5/VERSION b/P5/VERSION
index 81107396d2..90a8eb5ce3 100644
--- a/P5/VERSION
+++ b/P5/VERSION
@@ -1 +1 @@
-4.7.0a
+4.8.0a