Del lenguaje de marcado al lenguaje estructurado. Parte I

Actualmente en la industria del software se usa XML para casi todo tipo de estructuras de información, desde ficheros de configuración, plantillas de presentación hasta formato de intercambio entre sistemas.
Cualquiera que haya participado en un proyecto web de tamaño mediano-grande, habrá experimentado un hastío después de trabajar constantemente con estos ficheros XML. Y es que este lenguaje es muy verboso, y su verbosidad viene dictada porla función inicial para el que se pensaron los lenguajes de marcado . Por ejemplo la frase "A markup language provides a way to combine a text and extra information about it. The extra information, including structure, layout, or other information, is expressed using markup, which is typically intermingled with the primary text." nos demuestra una de las motivaciones iniciales de estos tipos de lenguaje, el entremezclar texto primario, con información extra. Por tanto estos lenguajes están orientados a generar un lenguaje primario con facilidad anotado con pequeños trozos de información extra; y por eso, la información extra es muy verbosa.Por ejemplo, un fragmento típico sería :

<exampleText>Lorem ipsum dolor sit amet, consectetur adipisici elit, sed eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, <tag1>quis nostrud</tag1> exercitation ullamco laboris nisi ut aliquid ex ea commodi consequat. Quis aute iure reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla <tag2 attrib="some">pariatur</tag2>. Excepteur sint obcaecat cupiditat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</exampleText>

En este fragmento, la mayoría es de texto primario, y por eso no resulta tan verboso y hasta comprensible (por ejemplo hay una relación de 45/2 en caracters de información vs. caracteris de marcado). Sin embargo, tomando otro ejemplo de un script de maven:

<goal name="performanceTest" prereqs="eclipse:prepare">
 <attainGoal name="test:single">
 <property name="testcase" value="com.germinus.xpression.jcr.JCRPerformanceTest"/>
</attainGoal>
</goal>
<goal name="install" >
 <attainGoal name="jar:install"/>
 <maven:reactor
basedir="${basedir}/modules"
includes="*/project.xml"
goals="install"
banner="Installing Module"
ignoreFailures="false"
/>
</goal>
<goal name="deploy" >
<attainGoal name="jar:deploy"/>
<maven:reactor
basedir="${basedir}/modules"
includes="*/project.xml"
goals="deploy"
banner="Deploying Module"
ignoreFailures="false"
/>
</goal>
<goal name="test:all">
<j:set var="testcase" value="com.germinus.xpression.cms.AllTests"/>
<attainGoal name="test:single"/>
</goal>

nos encontramos con un caracter de marcado por cada 6 de información (724 caracteres por 116 de marcado; no he contado los ':' dentro de los nombres de los elementos ya que se pueden considerar como parte de información semántica, no léxica), que ya empieza a ser bastante significativo. ¿Os parece legible este fragmento a simple vista? a mi no... (y eso que no habeis visto la versión "escapada" que he tenido que poner para que muestre todos los caracteres HTML ;-) )
Si os fijáis además en este último ejemplo podéis apreciar que no hay nada de texto fuera de los elementos, osea no hay "marcado" alguno en todo el documento, cosa muy habitual en los XML que se manejan en el mundo del desarrollo hoy en dia. ¿Es necesario un lenguaje de marcado para representar este tipo de información? Realmente no, lo que me está pidiendo es un luenguaje "estructurado". ¿Qué tal algo así?:

goal {    name "performanceTest"
prereqs "eclipse:prepare"
attainGoal{ name "test:single"
      property{ name"testcase"
              value "com.germinus.xpression.jcr.JCRPerformanceTest"
      }
}
}
goal { name"install"
attainGoal{name "jar:install"}
maven_reactor {
basedir "${basedir}/modules"
includes "*/project.xml"
goals "install"
banner "Installing Module"
ignoreFailures "false"
}
}
goal { name "deploy"
attainGoal{ name="jar:deploy"}
maven_reactor {
basedir "${basedir}/modules"
includes "*/project.xml"
goals "deploy"
banner "Deploying Module"
ignoreFailures "false"
}
}
goal { name="test:all"
j_set{
var "testcase"
value "com.germinus.xpression.cms.AllTests"
}
attainGoal{ name "test:single" }
}

Más legible ¿no?. Además se han reducido los caracteres de escapado a 71 (1 cada 10 de información), pero, además hemos eliminado caracteres totales también ya que en esta versión no es necesario reescribir el nombre del elemento de nuevo al cerrar un tag (lo que me lleva a pensar que en realidad es información redundante y por tanto podría estar incluidos en los caracteres de escapado).
Y ¿qué diría si os dijese que el parseador para este lenguaje se puede implementar en una mañana? Pues sí, ya que el analizador sintáctico y léxico ya existe y se llama Groovy.

to be continued...