Versión 1.2 - Actualizado: 18 de mayo 2001
URL de esta página: http://xem.sourceforge.net/es/spec.html
Autor: I.R.Maturana - irm@nexo.es
El nombre XEM significa eXtensible Electronic Mail.
La idea nació en Internet, en foros de traductores, que son personas que se caracterizan por estar intercambiando permanentemente información, y no ser capaces de recuperarla después. :))
XEM permite introducir de forma sencilla e intuitiva, dentro del cuerpo de un mensaje, etiquetas sobre la información importante. La diferencia con XML, es que XEM es menos exigente que XML en cuanto a sintaxis.
XEM está pensado como un sistema de notación manual, utilizado por personas que, aunque mínimamente metódicas, no tienen por qué entender de DTD, esquemas y transformaciones.
La ventaja inmediata es que un usuario puede redactar al vuelo documentos XML sin necesidad de preocuparse por contruir un documento "bien formado".
Otra ventaja, y ésta se explica por el contexto en que XEM fue diseñado, es la posibilidad de introducir rápidamente dentro de un correo electrónico, un documento de texto, o incluso en la "vista esquema" de cualquier procesador de textos avanzado, una serie de etiquetas al gusto del usuario, con el fin de convertirlo rápidamente a XML.
Estas mismas páginas se estructuraron mediante etiquetas
HTML sencillas de acuerdo con la sintaxis XEM, y se convirtieron directamente a HTML.
Éste es un mensaje típico que circula por la lista Tecnotrad (TRADUCCION@LISTSERV.REDIRIS.ES), especializada en tecnologías aplicadas a traducción.
De : Traducción en España [mailto:TRADUCCION@LISTSERV.REDIRIS.ES]
De la part de AB Cortesía de MJH
Os paso esta referencia de otra lista sobre un
<tctrad>
<tit> Metaglossario informática
<url> http://www.edu-cyberpg.com/Internet/metaglossary.html
<cmt> larga lista de direcciones de glosario (Sin descripción)
<kwd> glossary glosario listado
</tctrad>
Saludos cordiales.
Alberto.
Finisrede http://shibumi.org/eoti.htm
Suponiendo que dicho mensaje (y con él, muchos otros juntos) se extrae a un archivo de texto y se procesa, la salida del programa de conversión produce un archivo XML bien formado que se puede examinar con un navegador como IExplorer, un editor XML, o insertar directamente en una base de datos. (Los ejemplos de esta especificación muestran espacios que no aparecen en la salida del programa).
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xem version="0.1" licence="www.in3activa.org/doc/es/LPT-ES.html"?>
<tctrad>
<tit>
Metaglossario informática
</tit>
<url> http://www.edu-cyberpg.com/Internet/metaglossary.html
</url>
<cmt> larga lista de direcciones de glosario
<p/> (Sin descripción)
</cmt>
<kwd> glossary glosario listado
</kwd>
</tctrad>
Un último aspecto a destacar, es que el formato XEM es un formato diseñado para hacer circular información.
Naturalmente, las perspectivas abiertas por XEM para que programas rastreadores puedan extraer y recuperar automáticamente información intercambiada en los foros plantea la cuestión de la propiedad intelectual de los datos.
Caben considerarse aquí dos aspectos: la licencia de los propios programas de conversión y el copyright de la información que se pone en circulación al utilizar este formato.
Por su parte, el código del programa de conversión se distribuye bajo licencia GNU. Por otro lado, la documentación relacionada está protegida por la licencia pública de traducción (ver www.in3activa.org/doc/es/LPT-ES.html ).
En lo que toca a la información difundida en formato XEM, toda información es libre por sí misma pero el formato exclusivo que se asocia a su publicación está asociado a un copyright. Aunque tiene poco sentido aplicar un copyright sobre una información que se desea hacer circular, sí es necesario reconocer el derecho moral de la persona que decide hacer pública la información.
Por esta razón, el formato XEM utiliza una cabecera similar a la que utiliza XML, donde además de especificar la versión utilizada, se indican las condiciones de licencia de la información.
Esta es la cabecera (para la versión 0,1)
<?xem version="0.1" licence="www.in3activa.org/doc/es/LPT-ES.html"?>
Se trata de un encabezado predeterminado, es decir que de cara al procesado de información en formato XEM, se asumirá lo siguiente:
- En ausencia de cabecera, o de especificación del atributo "licence", cualquier información en formato XEM que circule por Internet se entenderá protegida por la LPT. Toda esa información podrá ser procesada, traducida y difundida sin limitación por Internet y sólo por Internet, de acuerdo con la licencia.
- Cuando se desee estipular condiciones de licencia distintas a las anteriores, el autor deberá obligatoriamente especificar la URI de la licencia aplicable, o en su defecto, eliminar la sintaxis XEM. En tal caso, la información no será procesada.
Intuitivamente, la sintaxis XEM se presenta como una versión aligerada de XML, a partir de la cual un programa como xemcl agrega etiquetas de cierre para obtener un documento XML bien formado.
En realidad, a nivel de programa, esto introduce una serie de reglas implícitas relativamente sutiles en las que las ambigüedades se resuelven optando por la solución más intuitiva para el usuario.
Ejemplo de estructura XEM:
<A>
<B> datos en varias líneas
<C> datos en varias líneas con posible <D/> insertada dentro del texto
</A>
Las etiquetas no requieren aparecer al principio de línea ni incluir sangría, aunque es por supuesto más claro.
Se considera etiqueta raíz aquella que aparece la primera dentro de un flujo de texto sin formato. La etiqueta raíz no puede anidarse. Si el usuario no especifica una etiqueta obligatoria, XEM admite la presencia de bloques con etiquetas raíz distintas.
La no anidación de etiquetas raíz permite al interprete rectificar de forma aceptable errores como la ausencia de una etiqueta de cierre dentro de un flujo de varios bloques.
Tras identificar una etiqueta raíz, y XEM interpreta a continuación datos con formato hasta encontrar:
- la etiqueta de cierre de la misma etiqueta raíz (ver ej.1)
- otra etiqueta de apertura con el mismo nombre de raíz que el bloque anterior (ej.2).
Todo el texto inicial se pasa por altoEjemplo 2
<bloque>
<a> primer bloque
<b> datos
<a> datos
</bloque>
Fuera de un bloque, el texto se pasa por alto.
<bloque>
<a> datos
<b> datos
<a> datos
</bloque>
Falta la etiqueta de cierre del primer bloque. La aparición del segundo bloque hace que XEM incluya la etiqueta </bloque> inmediatamente después de <a>
Dada una situación como:
<bloque>
<a> primer bloque
<b> datos
<a> ** todo lo que sigue hasta el 2o bloque se perderá
<bloque>
..etc..
</bloque>
XEM inserta un </bloque> inmediatamente después de <a> de modo que el resultado equivale (en este caso) a:
<bloque>
<a> primer bloque
<b> datos
<a/>
</bloque>
<bloque>
..etc..
</bloque>
En los ejemplos anteriores, XEM identifica por sí mismo una etiqueta raíz.
La opción -b de la línea de comandos permite reforzar la regla, al especificar qué etiquetas se consideran obligatoriamente raíces.
Este tratamiento de bloques raíz La rectificación El último caso permite
- Las etiquetas no distinguen mayúsculas y minúsculas
Sin embargo la salida XML se realiza siempre en minúsculas, de acuerdo con la recomendación para XHTML.
- Se reconocen los atributos con la sintaxis XML habitual
<A attb="atributo" attb2='otro "x" atributo' >
- Se reconocen asimismo etiquetas aisladas <etq/>
Estas etiquetas tienen internamente un tratamiento equivalente al de un nodo de texto. Por tanto:
<A>
Esta etiqueta _NO_ es de cierre: <A/>
</A>
- Se admiten varias raices dentro de un mismo documento. Esto se debe a la necesidad de poder agrupar varios mensajes con datos XEM en un mismo archivo.
La sintaxis siguiente es legal:
<A>
<D1> texto
<D2> texto
<D3> texto
</A>
<B>
<D1> texto
<D2> texto
<D3> texto
</B>
Cuando detecta una estructura multiraíz, el convertidor XEM-XML incluye una etiqueta raíz <XEM> para obtener un documento bien formado.
- Etiquetas cuyo contenido no se conforma a la sintaxis XML se interpretan a la salida literalemente con < y >. La sintaxis XML asume que una etiqueta responde al patrón [a-z][_0-9a-z]+
Esto es importante, en particular, para poder procesar archivos de texto bruto donde es usual la cadena
Pepe García <pepegarcia@dominio.es>
Que se interpreta por tanto como:
Pepe García <<pepegarcia@dominio.es>
- Se requiere al menos la etiqueta de cierre del final del bloque raíz.
Datos no terminados por una etiqueta de cierre se descartan.
Este comportamiento es deseado, ya que evita incluir en la salida el resultado de una colecta masiva de datos no previstos en un archivo donde el usuario olvidó cerrar un bloque raíz.
Nótese que el analizador lee realmente los datos, aunque no los incluya en la salida: en casos donde el archivo es de dimensiones gigantescas, puede producirse un fallo por memoria insuficiente.
El ejemplo:
<A>
<B> datos
<C> más datos posibles <D/> con una etiqueta independiente
Produce:
<xem>
<a/>
<b> datos</b>
<c> más datos posibles <d/></c></xem>
Es decir, el analizador asume un documento multiraíz A,B y C, donde <A> es un nodo vacío. El analizador incluye la raiz <xem> en caso de un documento multiraíz.
- Un etiqueta de cierre se ignora cuando no introduce profundidad de bloque.
En la sintaxis siguiente el cierre con </label> es redundante y produce el mismo resultado en todos los casos
<!-- Ejemplo con cierre implícito -->
<form>
<label> Tu nombre <input name="idname" value="name" />
<label> Tu contraseña <input name="idpwd" value="password" />
</form>
<!-- Ejemplo con cierre explícito, mismo resultado -->
<form>
<label> Tu nombre <input name="idname" value="name" /> </label>
<label> Tu contraseña <input name="idpwd" value="password" /> </label>
</form>
Sin embargo, un cierre explícito puede ser necesario para evitar ambigüedades cuando se utiliza la mismo etiqueta en la raíz:
<!-- Cierre explícito para evitar ambigüedades -->
<b>
<b> data <c/> </b>
<b> data <c/> </b>
</b>
<!-- Resultado distinto con cierre implicito : -->
<b>
<b> data <c/>
<b> data <c/>
</b>
Donde </b> corresponde a la última aparición de <b> y no a la raiz.
(Este último ejemplo ilustra también el tratamiento de los espacios.)
- Un etiqueta de cierre que no corresponde a una etiqueta de apertura se ignora simplemente.
Un ejemplo como el siguiente se interpretará como multiraíz:
<a>
<b> data <c/> </b>
<b> data <c/> </b>
y produce el resultado siguiente:
<xem>
<a/>
<b> data <c/> </b>
<b> data <c/> </b></xem>
- Los comentarios XML se conservan en cualquier parte del documento y no sólo dentro de un bloque construido:
<!-- se conserva tal cual -->
- Se reconocen correctamente los nodos CDATA:
<A>
<![CDATA[ este salto de línea,
< los espacios a la izquierda, una etiqueta </A> interno e incluso el retorno de carro final forman parte de los datos brutos
]] >
</A>
- El analizador ignora las declaraciones:
<?xml version="xx">
<?xem version="xx" licence="yy">
y las genera automáticamente como:
<?xml version="1.0" encoding="ISO-8859-1"?>
<?xem version="0.1" licence="www.in3activa.org/doc/es/LPT-ES.html"?>
- Otras PI como <?xml:stylesheet...> pueden aparecer en cualquier lugar del origen, se reproducen en el destino, colocadas antes del nodo raiz.
- Etiqueta CDATA y sintaxis PHP y ASP:
Las notaciones
<? code(); ?> <% code(); %> <?php phpcode(); ?>
se reconocen en cualquier lugar del origen, se reproducen en el mismo lugar en destino y se codifican como una secuencia:
<CDATA>[CDATA[...]] ></CDATA>
que contiene la PI completa original. Por ejemplo:
<CDATA><![CDATA[[<? phpinfo(); ?>]] ></CDATA>
Estas secuencias respetan íntegras la secuencia de espacios.
Nota: la etiqueta <CDATA> (en mayúsculas) se utiliza para delimitar el contenido porque la sintaxis <![CDATA[ no es en sí misma una etiqueta. En una transformación XSLT, el patrón siguiente extrae el contenido sin alterarlo :
<xsl:template match="CDATA">
<xsl:value-of select="text()" disable-output-escaping="yes"/>
</xsl:template>
Este punto se aplica a los datos internos de una etiqueta solamente.
El tratamiento de los espacios es similar al de XML, excepto para retornos de carro
- varios blancos interiores se reducen a uno solo no repetido
Cuando el blanco es un retorno de carro, éste prevalece sobre el espacio
Todos los demás blancos se interpretan como espacio.
- Se respetan los espacios exteriores (inicio/final)
- Se eliminan los retornos de carro exteriores (inicio/final)
El intérprete memoriza la presencia de blancos al principio o al final, y los restituye siempre como ESPACIOS.
Este punto se aplica a los datos internos de una etiqueta solamente.
Los datos de texto se interpretan como el contenido delimitado por dos etiquetas de apertura y cierre válidas.
XEM asume una conjunto de convenciones sobre el formato de presentación del texto, redactado a mano por el usuario para concatenar algunas líneas formando párrafo.
- Se concatenan las líneas que empiezan por minúsculas, comillas simples o dobles, o parentesis, si la línea anterior no termina por un signo de puntuación ":?!." ni está vacía.
- En la salida XML, un retorno de carro conservado se convierte a <P/>. En la salida XEM se conserva como tal ("\n").
<A>
Este texto XML introduce opciones:
- esta es la opción
Éste texto que se concatena con la opción porque empieza con mayúscula, incluso acentuada (según la local)
</A>
Produce en su salida XML:
<a>Este texto XML introduce opciones:
<p/>- esta es la opción
<p/>Éste texto que se concatena con la opción porque empieza con mayúscula, incluso acentuada (según la local)
</a>
- La secuencia para escribir un caracter /</ es /<</
<A> esta es la forma de indicar una <<etiqueta> literal
</A>
Produce correctamente la salida
<A> esta es la forma de indicar una <etiqueta> literal
</A>