- A pesar de su nombre, la configuración para trabajar con ODD suele requerir al menos dos archivos lógicos (aunque pueden repartirse entre muchos más archivos del sistema de ficheros, como se muestra en el siguiente paso de este tutorial). El primero de estos archivos es el llamado fuente: contiene la especificación completa del formato, en este caso MEI. En nuestro repositorio, se encuentra en el archivo mei-source.xml. Además de ese archivo, se requiere una personalización separada para especificar qué partes de la especificación deben utilizarse en un contexto determinado. El objetivo de ODD es permitir la personalización flexible del esquema. MEI proporciona un conjunto de perfiles predefinidos, que no son más que personalizaciones del esquema MEI.
+ A pesar de su nombre, la configuración para trabajar con ODD suele requerir al menos dos archivos lógicos (aunque pueden repartirse entre muchos más archivos del sistema de ficheros, como se muestra en el siguiente paso de este tutorial). El primero de estos archivos es el llamado fuente: contiene la especificación completa del formato, en este caso MEI. En nuestro repositorio, se encuentra en el archivo mei-source.xml. Además de ese archivo, se requiere una personalización separada para especificar qué partes de la especificación deben utilizarse en un contexto determinado. El objetivo de ODD es permitir la personalización flexible del esquema. MEI proporciona un conjunto de perfiles predefinidos, que no son más que personalizaciones del esquema MEI.
Para utilizar MEI (o cualquier otro formato basado en ODD), el archivo customization se utiliza para controlar cómo se compilará el archivo source. Existen varios formatos de destino para esa compilación, que se explican en otra parte. El objetivo más común es un archivo RelaxNG, que contiene tanto las jerarquías de RelaxNG como las reglas adicionales de Schematron definidas en el ODD, y puede utilizarse para la validación contra ambos tipos de esquema. Todos los demás formatos de salida posibles no se utilizan habitualmente para MEI. (Nota: volveremos a dar una breve explicación de Schematron más adelante en este tutorial).
diff --git a/_tutorials-ES/180_understanding_odd/180_understanding_odd-05.html b/_tutorials-ES/180_understanding_odd/180_understanding_odd-05.html
index ce3c5185..2b840211 100644
--- a/_tutorials-ES/180_understanding_odd/180_understanding_odd-05.html
+++ b/_tutorials-ES/180_understanding_odd/180_understanding_odd-05.html
@@ -1,6 +1,6 @@
- Los bloques fundamentales más claros de la especificación de MEI son las definiciones de los elementos. Se crean utilizando el elemento de TEI <elementSpec>. Vamos a echarle un vistazo al elemento <castItem>:
+ Los bloques fundamentales más claros de la especificación de MEI son las definiciones de los elementos. Se crean utilizando el elemento de TEI <elementSpec>. Vamos a echarle un vistazo al elemento <castItem>:
<elementSpec ident="castItem" module="MEI.shared">
<desc>Contiene una única entrada dentro de una lista de plantilla, que describe un único papel o una lista de papeles no orales.</desc>
@@ -37,7 +37,7 @@
El siguiente dato lo proporciona el elemento <classes>, que especifica a qué elemento classes pertenece. Entraremos en detalle más adelante, pero para que os hagáis a la idea, se utiliza para definir qué atributos están disponibles en el elemento y dónde puede que se utilicen dentro de un archivo de MEI.
- Ahora observamos al elemento <content>, que define lo que puede ir dentro de nuestro elemento. En este caso, la versión de ODD que utiliza MEI pasa a RelaxNG namespace (http://relaxng.org/ns/structure/1.0), como indica rng: el prefijo de los nombres de los elementos. Los siguientes niveles de marcado se pueden entender de una manera bastante intuitiva a partir de los nombres de los elementos. El contenido puede tener una o más opciones de cualquier contenido textual, o de los elementos <role>, <roleDesc>, <actor> o <perfRes>. Al anidar <rng:oneOrMore> and <rng:choice>, se deja claro que no hay un orden específico para esos elementos hijo y que se pueden mezclar entre ellos con el contenido textual.
+ Ahora observamos al elemento <content>, que define lo que puede ir dentro de nuestro elemento. En este caso, la versión de ODD que utiliza MEI pasa a RelaxNG namespace (http://relaxng.org/ns/structure/1.0), como indica rng: el prefijo de los nombres de los elementos. Los siguientes niveles de marcado se pueden entender de una manera bastante intuitiva a partir de los nombres de los elementos. El contenido puede tener una o más opciones de cualquier contenido textual, o de los elementos <role>, <roleDesc>, <actor> o <perfRes>. Al anidar <rng:oneOrMore> and <rng:choice>, se deja claro que no hay un orden específico para esos elementos hijo y que se pueden mezclar entre ellos con el contenido textual.
Aquí vemos referencias directas (<rng:ref>) a elementos especificos, identificados por sus respectivos atributos @ident. En el siguiente paso de este tutorial veremos un enfoque más flexible utilizando las llamados clases de modelo. Ambos enfoques se pueden mezclar cuando sea necesario.
@@ -46,10 +46,10 @@
La otra información que proporciona <elementSpec> son los <remarks>. Mientras que el elemento <desc> únicamente proporciona una muy breve explicación de un elemento (normalmente una frase), el elemento <remarks> suele porporcionar una explicación adicional sobre el uso de un elemento, o, al igual que en este caso, que deriva de un elemento existente en un formato diferente.
- Además de lo visto aquí en <castItem>, ODD ofrece dos cosas más que se pueden especificar en los elementos. A veces es más fácil o más adecuado especificar attributes directamente sobre un elemento, en vez de usar attribute classes. Un buen ejemplo de esto sería el elemento<title>, que tiene tanto @level como @type definidos localmente al usar el elemento <attList> dentro de <elementSpec>.
+ Además de lo visto aquí en <castItem>, ODD ofrece dos cosas más que se pueden especificar en los elementos. A veces es más fácil o más adecuado especificar attributes directamente sobre un elemento, en vez de usar attribute classes. Un buen ejemplo de esto sería el elemento<title>, que tiene tanto @level como @type definidos localmente al usar el elemento <attList> dentro de <elementSpec>.
- El otro tipo de información que falta en <castItem> son las reglas Schematron, que se proporcionan al utilizar los elementos <constraintSpec>. Si bien Schematron es una parte integral de MEI y ayuda a hacer cumplir ciertas afirmaciones dependientes del contexto en las instancias de MEI, documentarlo completamente iría mucho más allá del alcance de este tutorial. Hay otros tutoriales disponibles en línea (véase aquí o aquí), y por supuesto, se pueden utilizar las reglas de Schematron existentes en MEI para entender mejor cómo se aplica. Desde luego que el elemento <staffDef> es un buen punto de partida, se controla bajo un número considerable de reglas de Schematron.
+ El otro tipo de información que falta en <castItem> son las reglas Schematron, que se proporcionan al utilizar los elementos <constraintSpec>. Si bien Schematron es una parte integral de MEI y ayuda a hacer cumplir ciertas afirmaciones dependientes del contexto en las instancias de MEI, documentarlo completamente iría mucho más allá del alcance de este tutorial. Hay otros tutoriales disponibles en línea (véase aquí o aquí), y por supuesto, se pueden utilizar las reglas de Schematron existentes en MEI para entender mejor cómo se aplica. Desde luego que el elemento <staffDef> es un buen punto de partida, se controla bajo un número considerable de reglas de Schematron.
Pasemos al concepto de clase de ODD, algo crucial para la flexibilidad y personalización de MEI
diff --git a/_tutorials-ES/180_understanding_odd/180_understanding_odd-06.html b/_tutorials-ES/180_understanding_odd/180_understanding_odd-06.html
index 58d42e22..1518f8ec 100644
--- a/_tutorials-ES/180_understanding_odd/180_understanding_odd-06.html
+++ b/_tutorials-ES/180_understanding_odd/180_understanding_odd-06.html
@@ -3,7 +3,7 @@
Como hemos visto, ODD permite especificar qué elementos hijos exactos están permitidos dentro de un elemento. Esto permite un control muy preciso de la jerarquía MEI, pero a costa de listados muy detallados de lo que puede contener cada elemento. Esto no es especialmente fácil de mantener ni de seguir: algunos elementos de MEI pueden contener docenas de otros elementos, y comparar dos de estos elementos es bastante engorroso.
- Entre otros, el elemento <castItem> del último paso de este tutorial tenía un elemento hijo <role>. La documentación de <role> enumera un total de 54 elementos hijos, además del contenido textual:
+ Entre otros, el elemento <castItem> del último paso de este tutorial tenía un elemento hijo <role>. La documentación de <role> enumera un total de 54 elementos hijos, además del contenido textual:
@@ -45,7 +45,7 @@
Una clase de modelo se codifica con un elemento
<classSpec>, que tiene el atributo
@type="model". Al igual que los elementos, se identifica de forma única mediante el atributo
@ident. Se asigna a uno de los módulos de MEI con el atributo
@module. MEI sigue la convención de que todos los nombres de las clases de modelos llevan como prefijo la cadena "
model.". También tienen siempre un
<desc> con una breve explicación del propósito del grupo. Vamos a omitir los elementos
<memberOf> en
<classSpec> del ejemplo anterior por un momento, y vamos a ver cómo esos 54 elementos que hemos visto anteriormente están vinculados a
model.textPhraseLike.limited.
- Si vamos a las Directrices MEI para model.textPhraseLike.limited, vemos que seis elementos son "miembros" directos de esta clase de modelo: <dedicatee>, <dimensions>, <extent>, <seg>, <symbol>, y <term>. Echemos un vistazo a <dedicatee>:
+ Si vamos a las Directrices MEI para model.textPhraseLike.limited, vemos que seis elementos son "miembros" directos de esta clase de modelo: <dedicatee>, <dimensions>, <extent>, <seg>, <symbol>, y <term>. Echemos un vistazo a <dedicatee>:
<elementSpec ident="dedicatee" module="MEI.shared">
<desc>Entidad a la que se ofrece formalmente un trabajo creativo.</desc>
@@ -73,7 +73,7 @@
- Vemos los seis hijos directos listados, pero también que <fig> aparece bajo la etiqueta model.figureLike, y <catchwords> y <fingerprint> provienen de model.msInline. Este listado continúa y explica el origen de los 54 elementos. Si echamos un vistazo a model.figureLike, vemos que esta clase tiene un <memberOf>, que apunta a model.textPhraseLike.limited:
+ Vemos los seis hijos directos listados, pero también que <fig> aparece bajo la etiqueta model.figureLike, y <catchwords> y <fingerprint> provienen de model.msInline. Este listado continúa y explica el origen de los 54 elementos. Si echamos un vistazo a model.figureLike, vemos que esta clase tiene un <memberOf>, que apunta a model.textPhraseLike.limited:
<classSpec ident="model.figureLike" module="MEI.figtable" type="model">
<desc>Agrupa elementos que representan o contienen información gráfica, como una ilustración o una figura.</desc>
diff --git a/_tutorials-ES/180_understanding_odd/180_understanding_odd-07.html b/_tutorials-ES/180_understanding_odd/180_understanding_odd-07.html
index 6081c3ee..b297ab18 100644
--- a/_tutorials-ES/180_understanding_odd/180_understanding_odd-07.html
+++ b/_tutorials-ES/180_understanding_odd/180_understanding_odd-07.html
@@ -12,7 +12,7 @@
Los atributos se especifican mediante el elemento <attDef>, y siguen algunas convenciones que ya hemos visto en los elementos y clases de modelos: su nombre se proporciona en el atributo @ident, y tienen un elemento <desc> con una breve descripción. La novedad es el atributo @usage, que especifica cuándo utilizar el atributo especificado. El valor aquí, "opt", se utiliza para los atributos opcionales - @xml:id se puede utilizar en todos los elementos MEI, pero no es obligatorio. Otros valores permitidos para @usage son "req" (obligatorio) y "rec" (recomendado cuando sea aplicable).
- Ahora vamos a echar un vistazo a estos elementos <attDef>. Aunque esa no sea realmente la solución preferida, a veces los atributos se definen en el elemento donde deben utilizarse, como ocurre con el atributo @type en <meiHead>:
+ Ahora vamos a echar un vistazo a estos elementos <attDef>. Aunque esa no sea realmente la solución preferida, a veces los atributos se definen en el elemento donde deben utilizarse, como ocurre con el atributo @type en <meiHead>:
<elementSpec ident="meiHead" module="MEI.header">
<desc>(cabecera MEI) - Suministra los metadatos descriptivos y declarativos prefijados a cada
@@ -59,7 +59,7 @@
Ya hemos visto <attDef>, y no hay diferencia entre los atributos definidos dentro de un elemento o dentro de una clase de atributos. Pero también hemos visto ya el elemento <classSpec> en clases de modelos. La única diferencia es que las clases de atributos utilizan el atributo @type="atts", y mientras que los nombres de las clases de modelos ya empiezan por "model.", las clases de atributos en MEI siempre tendrán un nombre que empieza por "att.".
- Anteriormente en este tutorial, vimos la definición del elemento <role>. Echemos un vistazo de nuevo, saltándonos algunas partes:
+ Anteriormente en este tutorial, vimos la definición del elemento <role>. Echemos un vistazo de nuevo, saltándonos algunas partes:
<elementSpec ident="role" module="MEI.shared">
<desc>Nombre de un papel dramático, tal como figura en una lista de reparto.</desc>
@@ -88,7 +88,7 @@
De nuevo, es a través del uso de un elemento <memberOf con la adecuada tonalidad @key como se consigue la pertenencia a diferentes clases en MEI, por lo que este mecanismo ya debería ser familiar. Y al igual que con las clases de modelos, las clases de atributos se utilizan desde clases bastante genéricas hasta conjuntos muy específicos de atributos bien alineados. Al suscribirse a la(s) clase(s) de atributo(s) correcta(s), un elemento puede obtener el conjunto de atributos adecuado, y se hace posible añadir o eliminar selectivamente atributos a elementos nuevos o existentes modificando estas membresías.
- En las especificaciones de att.common anteriores se revela otra clase de atributo att.typed que proporciona un atributo @type. Obviamente, esto no se ha utilizado en <meiHead>, como se ha visto anteriormente. La razón es que la clase de atributos proporciona un atributo @type que solo tiene una descripción muy genérica: designación que caracteriza al elemento en algún sentido, utilizando cualquier esquema de clasificación o tipología conveniente que emplee etiquetas de un solo token. En comparación con eso, el @type de <meiHead> tenía una definición muy estricta. En general, MEI trata de evitar el uso del mismo nombre de atributo con múltiples definiciones, pero eso no siempre es posible, y al menos no causa confusión técnica. Con la perspectiva "por clase" en los atributos (ver las especificaciones <meiHead>), es posible rastrear fácilmente de dónde viene cualquier atributo permitido.
+ En las especificaciones de att.common anteriores se revela otra clase de atributo att.typed que proporciona un atributo @type. Obviamente, esto no se ha utilizado en <meiHead>, como se ha visto anteriormente. La razón es que la clase de atributos proporciona un atributo @type que solo tiene una descripción muy genérica: designación que caracteriza al elemento en algún sentido, utilizando cualquier esquema de clasificación o tipología conveniente que emplee etiquetas de un solo token. En comparación con eso, el @type de <meiHead> tenía una definición muy estricta. En general, MEI trata de evitar el uso del mismo nombre de atributo con múltiples definiciones, pero eso no siempre es posible, y al menos no causa confusión técnica. Con la perspectiva "por clase" en los atributos (ver las especificaciones <meiHead>), es posible rastrear fácilmente de dónde viene cualquier atributo permitido.
La única parte importante que queda para entender ODD como se utiliza para definir MEI son los tipos de datos, que se introducirán en el siguiente paso de este tutorial.
diff --git a/_tutorials-ES/180_understanding_odd/180_understanding_odd-08.html b/_tutorials-ES/180_understanding_odd/180_understanding_odd-08.html
index 9bff6880..c1f31fd4 100644
--- a/_tutorials-ES/180_understanding_odd/180_understanding_odd-08.html
+++ b/_tutorials-ES/180_understanding_odd/180_understanding_odd-08.html
@@ -1,6 +1,6 @@
- La mayor parte de tipos de datos en formato ODD siguen unos conceptos comunes y consolidados: hay números enteros, valores booleanos, cadenas de caracteres y demás. Echemos un vistazo más detallado a alguno de ellos. El atributo @nse define dentro de la clase de atributo att.nInteger:
+ La mayor parte de tipos de datos en formato ODD siguen unos conceptos comunes y consolidados: hay números enteros, valores booleanos, cadenas de caracteres y demás. Echemos un vistazo más detallado a alguno de ellos. El atributo @nse define dentro de la clase de atributo att.nInteger:
<attDef ident="n" usage="opt">
<desc>Proporciona un identificador númerico que indica la posición de un elemento en una secuencia de elementos similares. Su valor deberá ser un número entero no negativo.</desc>
@@ -9,13 +9,13 @@
</datatype>
</attDef>
- Esto ocurre al usar el elemento <data> para el rng: espacio de nombres, donde @type utiliza un valor definido en RelaxNG. Los atributos @maxOccurs y @minOccurs definen la frecuencia con la que se da un valor de este tipo. En el atributo @staff definido en att.staffIdentse puede encontrar un ejemplo para otros valores. Este atributo se utiliza para asociar ControlEvents con uno o más pentagramas y podrá tener uno o más números enteros. Utiliza el siguiente marcado para conseguir esto:
+ Esto ocurre al usar el elemento <data> para el rng: espacio de nombres, donde @type utiliza un valor definido en RelaxNG. Los atributos @maxOccurs y @minOccurs definen la frecuencia con la que se da un valor de este tipo. En el atributo @staff definido en att.staffIdentse puede encontrar un ejemplo para otros valores. Este atributo se utiliza para asociar ControlEvents con uno o más pentagramas y podrá tener uno o más números enteros. Utiliza el siguiente marcado para conseguir esto:
<datatype maxOccurs="unbounded" minOccurs="1">
<rng:data type="positiveInteger"/>
</datatype>
- En otros casos, MEI define sus propios tipos de datos. Esto se consigue con el elemento <macroSpec>. Echemos un vistazo al tipo de dato data.BARRENDITION, que se utiliza para definir la apariencia de la línea divisoria:
+ En otros casos, MEI define sus propios tipos de datos. Esto se consigue con el elemento <macroSpec>. Echemos un vistazo al tipo de dato data.BARRENDITION, que se utiliza para definir la apariencia de la línea divisoria:
<macroSpec ident="data.BARRENDITION" module="MEI" type="dt">
<desc>Renderizaciones de las líneas divisorias. Algunos valores corresponden a la parte de símbolos musicales occidentales del estándar Unicode.</desc>
@@ -61,7 +61,7 @@
De nuevo, los atributos @ident and @module se utilizan de la misma forma que ya hemos visto, como el elemento hijo <desc>. Lo importante es el atributo @type con un valor de "dt" (tipo de dato). Convencionalmente, todos los nombre de tipos de datos van prefijados por "data.", y el nombre que le sigue figura todo en mayúsculas. Después tenemos una lista de valores, que en este caso está cerrada. Esto significa que todos los valores posibles aparecen enumerados aquí. Otras veces, @type de "semi" indica una lista semiabierta. Este tipo de lista proporciona recomendaciones, pero permite al usuario la opción de inventarse valores personalizados cuando ninguna de las sugerencias encaja con la situación en curso. Esto normalmente proporciona un buen equilibrio entre asegurar la consistencia y permitir ampliar el esquema bajo demanda.
- Al igual que con las clases de modelos y atributos, los tipos de datos pueden anidarse. Un ejemplo de esto sería el tipo de datodata.NOTEHEADMODIFIER:
+ Al igual que con las clases de modelos y atributos, los tipos de datos pueden anidarse. Un ejemplo de esto sería el tipo de datodata.NOTEHEADMODIFIER:
<macroSpec ident="data.NOTEHEADMODIFIER" module="MEI" type="dt">
<desc>Captura todos los "modificadores" de la cabeza de la nota; es decir, los símbolos añadidos a la cabeza de la nota, como las barras inclinadas, líneas, texto, recuadros, etc.</desc>
@@ -76,7 +76,7 @@
Esto significa que un atributo que utiliza el tipo de dato data.NOTEHEADMODIFIER aceptará valores que sigan las normas de los tipos de datos data.NOTEHEADMODIFIER.list o data.NOTEHEADMODIFIER.pat.
- El último tipo de dato que nos gustaría presentar es data.COLORVALUES, usado por data.COLOR, que a su vez se utiliza para controlar los valores de los atributos como @color (through att.color) or @beam.color (a través de att.beaming.vis). Utiliza un conjunto de expresiones regulares para controlar diferentes mecanismos de codificación de color:
+ El último tipo de dato que nos gustaría presentar es data.COLORVALUES, usado por data.COLOR, que a su vez se utiliza para controlar los valores de los atributos como @color (through att.color) or @beam.color (a través de att.beaming.vis). Utiliza un conjunto de expresiones regulares para controlar diferentes mecanismos de codificación de color:
<macroSpec ident="data.COLORVALUES" module="MEI" type="dt">
<desc>Valores de color parametrizados</desc>
diff --git a/_tutorials/100_structure/100_structure_end.html b/_tutorials/100_structure/100_structure_end.html
index ef54e011..07cfb114 100644
--- a/_tutorials/100_structure/100_structure_end.html
+++ b/_tutorials/100_structure/100_structure_end.html
@@ -10,7 +10,7 @@ Congratulations!
(<meiHead>) or information about the musical content (<music>).
- Since the topics addressed in this tutorial referred to the chapter Structural Elements of the MEI Guidelines,
+ Since the topics addressed in this tutorial referred to the chapter Structural Elements of the MEI Guidelines,
we recommend to consult this chapter whenever you need more detailed information.
diff --git a/_tutorials/100_structure/step-00/100_structure_step-00-desc.html b/_tutorials/100_structure/step-00/100_structure_step-00-desc.html
index 6936d114..99a79295 100644
--- a/_tutorials/100_structure/step-00/100_structure_step-00-desc.html
+++ b/_tutorials/100_structure/step-00/100_structure_step-00-desc.html
@@ -5,7 +5,7 @@
information you can expect in which part.
- The topics addressed in this tutorial are referring to the chapter Structural Elements of the MEI Guidelines. We recommend to consult this
+ The topics addressed in this tutorial are referring to the chapter Structural Elements of the MEI Guidelines. We recommend to consult this
chapter whenever you need more detailed information.
diff --git a/_tutorials/103_chords/step-01/103_chords_step-01-desc.html b/_tutorials/103_chords/step-01/103_chords_step-01-desc.html
index 57abc5ba..4f4421a9 100644
--- a/_tutorials/103_chords/step-01/103_chords_step-01-desc.html
+++ b/_tutorials/103_chords/step-01/103_chords_step-01-desc.html
@@ -4,7 +4,7 @@
In MEI, the notion of a chord means the "simultaneous sounding of two or more notes in the same layer with the
- same duration" (see Element specification).
+ same duration" (see Element specification).
Thus, a chord is made up of two or more note elements that belong to the same voice (layer) and have an identical
rhythmical structure (duration). (There are cases where you don't want to have the same duration on every note
of a chord, but these are not part of this basic tutorial.)
diff --git a/_tutorials/104_rests/104_rests_end.html b/_tutorials/104_rests/104_rests_end.html
index 4b2d415f..ef0822aa 100644
--- a/_tutorials/104_rests/104_rests_end.html
+++ b/_tutorials/104_rests/104_rests_end.html
@@ -4,23 +4,23 @@
Congratulations!
In this tutorial, you learned how to encode rests with MEI. The elements you've learned are:
These elements are almost always empty and have no child elements. With the space element, you
already learned about a fairly advanced mechanism of aligning multiple voices sharing a staff
in MEI. If you're interested in that, you may also want to investigate into the
@next and
@prev attributes from MEI's
-
att.linking
+
att.linking
attribute class (available on
<note> and other events). That attribute class allows to
lay "breadcrumbs" through an MEI file that make it possible to follow voices across multiple layers
(and staves, if necessary). This would facilitate analytical use of your MEI file, and is not required in
diff --git a/_tutorials/104_rests/step-00/104_rests_step-00-desc.html b/_tutorials/104_rests/step-00/104_rests_step-00-desc.html
index 386571e7..bbd1f9a5 100644
--- a/_tutorials/104_rests/step-00/104_rests_step-00-desc.html
+++ b/_tutorials/104_rests/step-00/104_rests_step-00-desc.html
@@ -6,7 +6,7 @@
Please consult
XML basics and minimal MEI structure and/or the
Quickstart tutorial if you need more information to complete the task below.
- According to the MEI Specification,
+ According to the MEI Specification,
a rest is "a non-sounding event found in the source being transcribed". Encoding that is simple:
Just use a <rest> element, with a @dur attribute.
diff --git a/_tutorials/104_rests/step-04/104_rests_step-04-desc.html b/_tutorials/104_rests/step-04/104_rests_step-04-desc.html
index 0e4f168c..df6ee99b 100644
--- a/_tutorials/104_rests/step-04/104_rests_step-04-desc.html
+++ b/_tutorials/104_rests/step-04/104_rests_step-04-desc.html
@@ -4,7 +4,7 @@
necessary to "push" events like notes to a later position in the measure, without saying they
are resting. This is usually the case when the document that's supposed to be encoded
switches between chord-based notation and separated stems within a measure (cf. figure below). As MEI uses the
-
<layer> element to lay out
+
<layer> element to lay out
multiple instruments, and in these situations an instrument switches between those layers
mid-measure, the "gaps" in those measures need to be filled. This is what the
<space> element is for.
diff --git a/_tutorials/180_understanding_odd/180_understanding_odd-01.html b/_tutorials/180_understanding_odd/180_understanding_odd-01.html
index 85008690..08b0af52 100644
--- a/_tutorials/180_understanding_odd/180_understanding_odd-01.html
+++ b/_tutorials/180_understanding_odd/180_understanding_odd-01.html
@@ -18,7 +18,7 @@
Understanding ODD
However, the wide MEI Community is more than happy to
answer questions,
and the same is certainly true for the MEI
Technical
Team. Just take your time with this tutorial, and also have a closer look at the
-
corresponding MEI Guidelines chapter.
+
corresponding MEI Guidelines chapter.
Eventually, you will become proficient in the discipline of using DH standards like MEI – just
continue from here on :-)
diff --git a/_tutorials/180_understanding_odd/180_understanding_odd-03.html b/_tutorials/180_understanding_odd/180_understanding_odd-03.html
index 19d5fe5b..666bb614 100644
--- a/_tutorials/180_understanding_odd/180_understanding_odd-03.html
+++ b/_tutorials/180_understanding_odd/180_understanding_odd-03.html
@@ -6,7 +6,7 @@
mei-source.xml file.
In addition to that file, a separate customization is required to specify which parts of the specification are to be used
in a given context. The whole purpose of ODD is to allow flexible customizations of the schema. MEI provides a set of
- pre-defined profiles,
+ pre-defined profiles,
which are nothing but customizations of the MEI schema.
diff --git a/_tutorials/180_understanding_odd/180_understanding_odd-05.html b/_tutorials/180_understanding_odd/180_understanding_odd-05.html
index c4e013a8..3849307d 100644
--- a/_tutorials/180_understanding_odd/180_understanding_odd-05.html
+++ b/_tutorials/180_understanding_odd/180_understanding_odd-05.html
@@ -2,7 +2,7 @@
The most obvious building blocks for the MEI specification are the definitions of elements. They are done using the TEI's
<elementSpec> element.
- Let's have a look at MEI's <castItem>
+ Let's have a look at MEI's <castItem>
element:
<elementSpec ident="castItem" module="MEI.shared">
@@ -54,10 +54,10 @@
as indicated by the rng: prefix to the element names. The next levels of markup can be understood quite
intuitively from the elements' names: The content can be one or more of a choice of either
textual content, or the elements
- <role>,
- <roleDesc>,
- <actor>, or
- <perfRes>.
+ <role>,
+ <roleDesc>,
+ <actor>, or
+ <perfRes>.
The nesting of <rng:oneOrMore> and <rng:choice> makes it clear that there is no
particular order for those child elements, and that they may be freely intermixed with textual content.
@@ -76,7 +76,7 @@
In addition to the things seen here on <castItem>, ODD offers two more things than can be specified
on elements. Sometimes, it is easier or more appropriate to specify attributes directly on an element, instead of
using attribute classes. An example for that can be found at the
- <title> element, which
+ <title> element, which
has both @level and @type defined locally using the
<attList> element inside
<elementSpec>.
@@ -90,7 +90,7 @@
here or
here), and of course
one may use existing Schematron rules in MEI to better understand how it is applied. A good starting point for that is surely the
- <staffDef> element,
+ <staffDef> element,
which is controlled by a considerable number of Schematron rules.
diff --git a/_tutorials/180_understanding_odd/180_understanding_odd-06.html b/_tutorials/180_understanding_odd/180_understanding_odd-06.html
index 0000ca35..6aa66c36 100644
--- a/_tutorials/180_understanding_odd/180_understanding_odd-06.html
+++ b/_tutorials/180_understanding_odd/180_understanding_odd-06.html
@@ -8,9 +8,9 @@
Among others, the
- <castItem>
+ <castItem>
element from the last step of this tutorial had a child element
- <role>. The documentation
+ <role>. The documentation
for <role> lists a total of 54 child elements, plus textual content:
@@ -63,7 +63,7 @@
If we go to the MEI Guidelines for
- model.textPhraseLike.limited,
+ model.textPhraseLike.limited,
we see that six elements are direct "members" of this model class: <dedicatee>, <dimensions>,
<extent>, <seg>, <symbol>, and <term>. Let's have a look into <dedicatee>:
@@ -103,7 +103,7 @@
We see the six direct children listed, but also that <fig> is listed under the model.figureLike label, and <catchwords>
and <fingerprint> are coming from model.msInline.
- This listing continues and explains the origin of all
+ This listing continues and explains the origin of all
54 elements. If we have a look at model.figureLike, we see that this class has a <memberOf>, pointing to model.textPhraseLike.limited:
<classSpec ident="model.figureLike" module="MEI.figtable" type="model">
diff --git a/_tutorials/180_understanding_odd/180_understanding_odd-07.html b/_tutorials/180_understanding_odd/180_understanding_odd-07.html
index bc01957a..f5eaf199 100644
--- a/_tutorials/180_understanding_odd/180_understanding_odd-07.html
+++ b/_tutorials/180_understanding_odd/180_understanding_odd-07.html
@@ -22,7 +22,7 @@
Now let's have a look for these <attDef> elements are located. Even though that's not really the preferred solution, sometimes
attributes are defined at the element where they need to be used, as with the @type attribute on
- <meiHead>:
+ <meiHead>:
<elementSpec ident="meiHead" module="MEI.header">
<desc>(MEI header) – Supplies the descriptive and declarative metadata prefixed to every
@@ -76,7 +76,7 @@
model classes already start with "model.", attribute classes in MEI will always have a name starting with "att.".
- Earlier in this tutorial, we saw the definition of the <role>
+ Earlier in this tutorial, we saw the definition of the <role>
element. Let's have a look on it again, skipping some parts of it:
<elementSpec ident="role" module="MEI.shared">
@@ -121,7 +121,7 @@
Compared to that, the @type on <meiHead> had a very strict definition. In general, MEI seeks to avoid
using the same attribute name with multiple definitions, but that's not always possible, and at least doesn't cause
technical confusion. With the "by class" perspective on attributes (see the
- <meiHead> specs),
+ <meiHead> specs),
its possible to easily trace where any allowed attribute comes from.
diff --git a/_tutorials/180_understanding_odd/180_understanding_odd-08.html b/_tutorials/180_understanding_odd/180_understanding_odd-08.html
index 882a604b..0d082627 100644
--- a/_tutorials/180_understanding_odd/180_understanding_odd-08.html
+++ b/_tutorials/180_understanding_odd/180_understanding_odd-08.html
@@ -2,7 +2,7 @@
Most data types in ODD are following common, well-established concepts: There are integers, boolean values, strings, and
so on. Let's have a closer look at some of them. The @n attribute is defined within the
- att.nInteger attribute
+ att.nInteger attribute
class:
<attDef ident="n" usage="opt">
@@ -16,9 +16,9 @@
RelaxNG. The @maxOccurs and @minOccurs attributes define how often a value of this type may be given. An
example for other values can be found for the @staff attribute defined in att.staffIdent. This attribute
is used to associate
- controlevents
+ controlevents
with one or more staves, and may hold one or more integers. It uses
- the following markup to achieve this:
+ the following markup to achieve this:
<datatype maxOccurs="unbounded" minOccurs="1">
<rng:data type="positiveInteger"/>
@@ -27,7 +27,7 @@
In other cases, MEI defines its own datatypes. This is done with a
<macroSpec> element.
Let's have a look at the
- data.BARRENDITION
+ data.BARRENDITION
data type, which is used to define the appearance of barlines:
<macroSpec ident="data.BARRENDITION" module="MEI" type="dt">
@@ -81,7 +81,7 @@
Like with model and attribute classes, data types may be nested. One example for this is the
- data.NOTEHEADMODIFIER
+ data.NOTEHEADMODIFIER
data type:
<macroSpec ident="data.NOTEHEADMODIFIER" module="MEI" type="dt">
@@ -100,9 +100,9 @@
One last data type that we'd like to introduce is data.COLORVALUES, which is used by data.COLOR, which
in turn is used to control the values of attributes like @color (through
- att.color)
+ att.color)
or @beam.color (through
- att.beaming.vis).
+ att.beaming.vis).
It uses a set of regular expressions to control different color encoding mechanisms:
<macroSpec ident="data.COLORVALUES" module="MEI" type="dt">
diff --git a/about/index.md b/about/index.md
index 1a7a0572..3276c8ef 100644
--- a/about/index.md
+++ b/about/index.md
@@ -4,7 +4,7 @@ title: "What is MEI?"
---
# An introduction to MEI
-The Music Encoding Initiative (MEI) is a community-driven, [open-source](https://github.com/music-encoding/music-encoding) effort to define a system for encoding musical documents in a machine-readable structure. MEI brings together specialists from various music research communities, including technologists, librarians, historians, and theorists in a common effort to define best practices for representing a broad range of musical documents and structures. The results of these discussions are formalized in the [MEI schema](/resources/schemas.html), a core set of rules for recording physical and intellectual characteristics of music notation documents expressed as an eXtensible Markup Language ([XML](https://web.archive.org/web/20191028132600/https://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html)) schema. It is complemented by the [MEI Guidelines](https://music-encoding.org/guidelines/v4/content/), which provide detailed explanations of the components of the MEI model and best practices suggestions. The schema is developed and maintained by the [MEI Technical Team](/community/technical-team.html).
+The Music Encoding Initiative (MEI) is a community-driven, [open-source](https://github.com/music-encoding/music-encoding) effort to define a system for encoding musical documents in a machine-readable structure. MEI brings together specialists from various music research communities, including technologists, librarians, historians, and theorists in a common effort to define best practices for representing a broad range of musical documents and structures. The results of these discussions are formalized in the [MEI schema](/resources/schemas.html), a core set of rules for recording physical and intellectual characteristics of music notation documents expressed as an eXtensible Markup Language ([XML](https://web.archive.org/web/20191028132600/https://www.tei-c.org/release/doc/tei-p5-doc/en/html/SG.html)) schema. It is complemented by the [MEI Guidelines](https://music-encoding.org/guidelines/), which provide detailed explanations of the components of the MEI model and best practices suggestions. The schema is developed and maintained by the [MEI Technical Team](/community/technical-team.html).
MEI, like the [Text Encoding Initiative](http://www.tei-c.org/) (TEI), is an umbrella term to simultaneously describe an organization, a research community, and a markup language. It closely mirrors work done by text scholars in the TEI and, while the two encoding initiatives are not formally related, they share many common characteristics and development practices.
diff --git a/community/mei-by-laws.md b/community/mei-by-laws.md
index 3bdc2a24..6358d184 100644
--- a/community/mei-by-laws.md
+++ b/community/mei-by-laws.md
@@ -59,7 +59,7 @@ Financial revenue of MEI (generated through membership fees, donations, grants
## 5 Board
-The property and business of MEI are managed by the [Board](https://music-encoding.org/community/mei-board.html). The broad role of the Board is to promote the development of MEI; oversee the activities of the [MEI Technical Team](https://music-encoding.org/community/technical-team.html); guide the development of the MEI conceptual model, [Guidelines](https://music-encoding.org/guidelines/v4/content/), and schemata; and act as a contact point for MEI-related activities.
+The property and business of MEI are managed by the [Board](https://music-encoding.org/community/mei-board.html). The broad role of the Board is to promote the development of MEI; oversee the activities of the [MEI Technical Team](https://music-encoding.org/community/technical-team.html); guide the development of the MEI conceptual model, [Guidelines](https://music-encoding.org/guidelines/), and schemata; and act as a contact point for MEI-related activities.
Board members serve as such without remuneration.
