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:
- Más bonito
- Más simple
- Más compacto
- Más rápido
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!!
<?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>
</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.