STxT: El Libro

Un lenguaje para la web

Capítulo 8: STxT y XML

Advertencia al lector

Este capítulo puede herir la sensibilidad de los lectores entusiastas de xml. Leed bajo vuestra propia responsabilidad ;-)

La leyenda

El origen del mal: SGML.

Todo empezó hace mucho, mucho tiempo, en una tierra oscura llamada "informática". Los encodings campaban por ese mundo. Sembrando incompatibilidades. Entorpeciendo comunicaciones. Riéndose de los que no eran como ellos. Algunos intentaron estar en paz con todos ellos.

Y entonces crearon el monstruo: SGML

El monstruo empezaba diciendo con qué encoding se quedaba. Y ya no había problema. Pero el esfuerzo era demasiado. Un montón de caracteres extraños eran necesarios. Textos repletos de "<", ">", "&xxx;". Ininteligibles.

Y se han reproducido. El mundo está lleno de sus hijos. Pequeños monstruos que llenan la tierra de estos caracteres, entorpeciendo la lectura para humanos. Sólo un puñado de élite puede tratar con los monstruos. Se los llama "Los Informáticos". Son el terror. Nadie los quiere ver, pero todos los necesitan. Son oscuros. Hablan lenguas extrañas.

Pero los monstruos todavía están aquí. Han mutado. Ahora se llaman xml's. ¡Y a la gente les gusta!!

...

Pero un pequeño grupo de gente se reunió, y decidió que no podía ser. Crearían un campeón. Alguien que los iluminara. Sólo podía quedar uno.

La hora de STxT había llegado.

La actualidad

El mundo está plagado de documentos feos, xml's que nos gustan... ¡si es un formato horrible!

Estamos heredando un formato anticuado, con encodings anticuados, con forma de pensar muy informatizada. Y está en todas partes. Y seguimos usándolo. Y queremos que esté para todo... ¡Un momento! ¡Stop! ¿Es necesario? Si no supiéramos nada de sgml y quisiéramos tener un txt rápido de parsear, con estructura, con espacio de nombres, ¿hubiésemos creado xml? Yo creo que no. Si a un niño le decimos que invente algo, supongo que jamás habría creado xml... hubiese hecho algo más natural... ¡HUBIESE CREADO STxT!

Bien, nosotros tenemos más experiencia y hemos aprendido. ¡Vamos a crearlo!

Toma de contacto

No quiero asustaros, pero STxT, comparado con xml es:

Y además se puede expresar lo mismo.

Vamos a ver un ejemplo de XML, y lo compararemos con STxT, para empezar. Será un ejemplo fácil:

<?xml version="1.0" encoding="UTF-8" ?> 
    <!-- This is a line comment  --> 
    <email>
    <from>John Smith</from>
    <to>Mery Adams</to> 
    <cc>Keyla Brown</cc> 
    <title>Project report</title> 
    <body>Hello Mery!! The book is finished!!</body> 
</email>

Vamos a ver la version de STxT:

# This is a line comment
Email (www.example.com/email.stxt):
    From: John Smith
    To: Mery Adams
    Cc: Keyla Brown
    Title: Project report
    Body: Hello Mery!! The book is finished!!

Creo que salta a la vista una primera característica:

STxT es mucho más bonito que XML, y se entiende mejor

Vamos a por el tamaño.

Longitud XML: 254
Longitud STxT: 190

Veamos cuando compactamos al máximo

<?xml version="1.0" encoding="UTF-8" ?><!-- This is a line comment  -->
<email><from>John Smith</from><to>Mery Adams</to><cc>Keyla Brown</cc>
<title>Project report</title><body>Hello Mery!! The book
is finished!!</body></email>
# This is a line comment
Email(www.example.com/email.stxt):
    From:John Smith
    To:Mery Adams
    Cc:Keyla Brown
    Title:Project report
    Body:Hello Mery!! The book is finished!!

Longitud Mínima XML: 225
Longitud Mínima STxT: 172

Si comparamos sin cabecera de xml ni namespace de STxT:

Longitud Mínima XML: 186
Longitud Mínima STxT: 149

Creo que es evidente que

STxT es más compacto que XML

Pero además

STxT es más entendible que XML en estado compactado

o dicho de otra forma

STxT mantiene su comprensión en estado compactado,
mientras que XML no

Por cierto, ¿hemos perdido información? No, pero ¿que pasaría si hubiera atributos? Lo comentaremos más adelante. De momento creedme:

Con STxT se puede expresar lo mismo que con XML

Ahora vamos a probar algo divertido... ¿Como queda un documento XML con un nodo de texto que a su vez contiene un XML?

Lo vemos:

<?xml version="1.0" encoding="UTF-8" ?> 
<!-- This is a line comment  --> 
<email>
<from>John Smith</from>
<to>Mery Adams</to> 
<cc>Keyla Brown<cc> 
<title>Project report</title> 
<body>
    Hello Mery!! The book is finished!!
    &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; ?&gt; 
    &lt;!-- This is a line comment  --&gt; 
    &lt;email&gt;
    &lt;from&gt;John Smith&lt;/from&gt;
    &lt;to&gt;Mery Adams&lt;/to&gt; 
    &lt;cc&gt;Keyla Brown&lt;cc&gt; 
    &lt;title&gt;Project report&lt;/title&gt; 
    &lt;body&gt;Hello Mery!! The book is finished!!&lt;/body&gt; 
</body> 
</email>

Y en STxT:

Email (www.example.com/email.stxt):
From: John Smith
To: Mery Adams
Cc: Keyla Brown
Title: Project report
Body:
    Hello Mery!! The book is finished!!
    <email>
    <from>John Smith</from>
    <to>Mery Adams</to> 
    <cc>Keyla Brown<cc> 
    <title>Project report</title> 
    <body>Hello Mery!! The book is finished!!</body> 
    </email>

Creo que sobran los comentarios. Es evidente, pero:

STxT es más sencillo que XML

Atributos XML

Vamos a por un ejemplo:

<ejemplo id="1" show="false">
    Hola Mundo
</ejemplo>

Los atributos en xml siempre han sido motivo de controversia. ¿Qué es un atributo y qué debería ser un nodo? Siempre es difícil de decidir. Está bastante aceptado que los atributos son como metadatos del nodo, es decir, aportan información pero no del contenido. Hay casos en los que es aceptable, pero (según mi modesta opinión) en la mayoría de ocasiones son una fuente de problemas.

Otro problema añadido es que todos han de tener en cuenta que los atributos existen. Esto afecta a DTD's, XSD's, librerías, programadores... ¿Y para qué? Realmente no aportan mucho. Sólo complejidad innecesaria. Además, esto es STxT. Todo tiene un significado, y todo es importante.

STxT no tiene atributos al estilo de XML

Esto lo hace MEJOR, no peor. A veces, MENOS ES MAS ;-)

El ejemplo anterior en STxT sería:

ejemplo(...):
    id:1
    show:false
    texto:Hola Mundo

De forma general, siempre podemos hacer algo de la forma:

nombre_nodo:
    metadatos:
        m1:xxx
        m2:xxx
        m3:xxx
    nodo2:
    nodo3:

DTD, XSD

XSD, DTD y STxT

Vamos a hablar de dtd's y xsd's de xml. Son documentos que nos dicen cómo tiene que ser un xml válido. Funcionan más o menos bien, y cada uno tiene sus ventajas e inconvenientes. Si miráis por Internet un poco veréis lo que quiero decir.

En resumen, DTD es más sencillo que XSD, es menos potente y está escrito en un lenguaje distinto a XML. XSD es más potente, más difícil de hacer y entender, pero está escrito en XML, no hay que aprender otro lenguaje.

¿Y qué pasa con STxT? Lo deberíais saber :-D Tiene lo mejor. Es un documento STxT. Integrado en el propio lenguaje. Potente y fácil de aprender. Como el propio STxT ;-)

¿Dónde está?

Me gustaría ver desaparecer un típico problema de xml:

¿Dónde está la gramática de este documento?

En STxT, TODO está en la web. Cuando se quiere crear un documento automáticamente hay que poder ver su definición. La gramática ha de ser accesible siempre.

Un documento STxT por definición tiene una gramática asociada.
Sino, no es STxT

XSD del XSD (*)

¿Alguien quiere comparar el xsd de un xsd? He estado tentado en incluirlo en el libro, pero hubiera ocupado más de 50 páginas, y no estoy exagerando :-D

Os dejo el enlace, por si alguien lo quiere ver:

[[http:_www.w3.org/2001/XMLSchema.xsd|http:_www.w3.org/2001/XMLSchema.xsd|xsd]]

¿Hay alguien que lo entienda? Perdón, perdón. ¿Hay alguien que no sea un superhéroe que lo entienda?

Todo es mucho más complicado. Con STxT hemos buscado la sencillez. ¡Nos gusta hacer las cosas a mano! ¡No debería ser obligatorio tener un editor o lector de XML!

Parsers y validators

¿Alguien quiere comparar los parsers y validators? No hace falta, uno con STxT es MUCHO más rápido y más sencillo de implementar. ¿Por qué? Es muy sencillo:

STxT tiene muchas menos normas que XML

Esto hace que todo sea más fácil. El código de los parsers es más rápido. Tienen menos errores. Es más fácil de mantener. De hacer. Además, otra ventaja es que parsear y validar se puede hacer de forma simultánea. Con XML hay que decidir si realmente hay que validar el xsd... ¿y dónde está? Ya estamos otra vez con el problema de siempre. Con STxT todo es mucho más claro. Cualquier documento tiene que tener una definición de cómo es. Pero es muy fácil de hacer. No se tarda nada. Vale la pena. Es una de grandes ventajas de STxT.

Nota: Para los amantes de la información privada: si el parseador o editor de STxT tiene un repositorio propio de gramáticas STxT, no tiene por qué estar visible en la web. No me gusta, estoy en contra, pero no hay nada ni nadie que impida hacer esto. De hecho, en ocasiones será necesario, como yo he tenido que hacer en mi propio libro antes de tener la web publicada.

Namespaces

Siempre he odiado los namespaces de XML. Son farragosos, difíciles de controlar, y normalmente no nos dicen nada.

Los namespaces en STxT son completamente distintos, ya que no son nada difíciles de hacer, aportan toda la información necesaria, y no se pierde la expresividad que se consigue con XML. De hecho, ¡ni tan siquiera los ves! Pero siempre están ahí, ayudando. Completando la obra.

En XML los namespaces molestan, aportan complejidad, y dan muy poco a cambio.

Por cierto, hemos desterrado el prefijo {{{http:}}} de los namespace. Ya no es necesario, ya que ello implicaría que es distinto si se obtiene con {{{http:}}} que si se hace con {{{https:}}}. Esto no tiene sentido, lo que sí lo tiene es que sea a partir de {{{}}}.

Futuro

He sido muy sincero con todo mi análisis de XML vs STxT, pero hay algo que no debemos olvidar. XML tiene mucho recorrido ya. Está probado, se usa en todas partes. Es un estándar. STxT es nuevo, apenas acaba de nacer, y tiene un largo camino por recorrer.

Pero creo que merece la pena.

Usamos cookies para mejorar su experiencia de uso y ofrecer contenidos adaptados a sus intereses Entendido! Más información