Project report

Document (globalcampus.site/namespace.stxt): Capítulo 8: @STxT@ y XML Default: Title: STXT: El Libro Metadata: Title: Capítulo 9: STxT y XML Description: Comparamos STxT con XML y mostramos similitudes y diferencias. Author: Joan Costa Mombiela last modif: 2013-03-01 header: Advertencia al lector Content: Este capítulo puede herir la sensibilidad de los lectores entusiastas de xml. Leed bajo vuestra propia responsabilidad ;-) header:La leyenda Content: 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. alert: La hora de @STxT@ había llegado. header:La actualidad Content: 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! header:Toma de contacto Content: 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: code: John Smith Mery Adams Keyla Brown Project report Hello Mery!! The book is finished!! Content: Vamos a ver la version de @STxT@: code: # 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!! Content: Creo que salta a la vista una primera característica: assert: @STxT@ es mucho más bonito que XML, y se entiende mejor Content: Vamos a por el tamaño. Longitud XML: 254\\ Longitud @STxT@: 190 Veamos cuando compactamos al máximo code: John SmithMery AdamsKeyla Brown Project reportHello Mery!! The book is finished!! code: # 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!! Content: 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 assert: @STxT@ es más compacto que XML Content: Pero además assert: @STxT@ es más entendible que XML en estado compactado Content: o dicho de otra forma assert: @STxT@ mantiene su comprensión en estado compactado,\\ mientras que XML no Content: Por cierto, ¿hemos perdido información? No, pero ¿que pasaría si hubiera atributos? Lo comentaremos más adelante. De momento creedme: assert: Con @STxT@ se puede expresar lo mismo que con XML Content: 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: code: John Smith Mery Adams Keyla Brown Project report Hello Mery!! The book is finished!! <?xml version="1.0" encoding="UTF-8" ?>  <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> Content: Y en @STxT@: code: 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!! John Smith Mery Adams Keyla Brown Project report Hello Mery!! The book is finished!! Content: Creo que sobran los comentarios. Es evidente, pero: assert: @STxT@ es más sencillo que XML header:Atributos XML Content: Vamos a por un ejemplo: code: Hola Mundo Content: 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. assert: @STxT@ no tiene atributos al estilo de XML Content: Esto lo hace _MEJOR_, no peor. A veces, _MENOS ES MAS ;-)_ El ejemplo anterior en @STxT@ sería: code: ejemplo(...): id:1 show:false texto:Hola Mundo Content: De forma general, siempre podemos hacer algo de la forma: code: nombre_nodo: metadatos: m1:xxx m2:xxx m3:xxx nodo2: nodo3: header:DTD, XSD subheader:XSD, DTD y @STxT@ Content: 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@ ;-) subheader:¿Dónde está? Content: Me gustaría ver desaparecer un típico problema de xml: assert: _¿Dónde está la gramática de este documento?_ Content: 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. assert: Un documento @STxT@ por definición tiene una gramática asociada.\\ Sino, no es @STxT@ subheader:XSD del XSD (*) Content: ¿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! header:Parsers y validators Content: ¿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: assert: @STxT@ tiene muchas menos normas que XML Content: 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. header:Namespaces Content: 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 {{{_}}}. header:Futuro Content: 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.