lenguajes de programación basados ​​en xml

8

Estaba mirando wikipedia - Categoría: lenguajes de programación basados ​​en XML .

¿Por qué alguien tomaría este enfoque para diseñar un lenguaje?
¿Cuáles son las ventajas de esto?

Solo puedo pensar en desventajas.

  • difícil de mantener
  • difícil de leer
  • difícil de escribir
programming-languages language-design xml Moha el todopoderoso camello
fuente
2
Por lo general, uno tiene algún otro programa (interfaz visual o tal) que un no programador utiliza para hacer algo, que luego se almacena como XML y se procesa como XML.
2
Estoy de acuerdo con tus inconvenientes. Usa Coldfusion y los argumentos que haces contra él son muy claros.
Plataforma
@Rig: Aunque Coldfusion no está realmente en esa lista a la que enlaza OP.
FrustratedWithFormsDesigner
Supongo que una posible ventaja sería que dicho sistema podría usar las consultas y expresiones XQuery y XPath para facilitar la escritura de código auto modificable. Se puede debatir si el código de auto-modificación que funciona a través de XPath / XQuery es algo bueno ...
FrustratedWithFormsDesigner
1
@ Mhd.Tahawi: Si el código de su programa está escrito como XML válido, su programa podría usar XPath / XQuery para reflexionar sobre sí mismo. Utilizado con XSLT, podría ser posible diseñar un lenguaje de programación basado en XML que use XSLT para escribir programas que puedan modificarse. No estoy seguro de que me gustaría tener que lidiar con un programa de este tipo, pero podría ser genial desde el punto de vista de la novedad.
FrustratedWithFormsDesigner

Respuestas:

4

Una de las mayores ventajas de un lenguaje basado en XML es que parece fácil de implementar

en realidad no, hay un montón de analizadores de validación disponibles que diagnosticarán los errores de compilación relacionados con la sintaxis y le proporcionarán el AST de forma gratuita

la ejecución también es simplemente iterar sobre dicho AST y mantener un mapa de las funciones y variables

monstruo de trinquete
fuente
3
"Seem" es la palabra clave aquí. La verdad es que esas ventajas son bastante pequeñas o inexistentes, pero ciertamente parece así cuando nunca ha creado una implementación de lenguaje. El análisis es computacionalmente costoso, pero en realidad es una de las partes más simples de implementar (generadores de analizadores o escritos a mano) y diseñar (la sintaxis es barata). Y una vez que tenga el AST, la forma en que proceda no está influenciada por la forma en que analiza, lo que significa que si la ejecución es simple, sigue siendo simple si elige una sintaxis diferente (obviamente, solo si mantiene la semántica).
@delnan Exactamente. Lo único que XML parece darle gratis es la parte fácil. Digo "parece" porque en realidad no te está dando nada, ya sea simplemente empujándolo al usuario o algún tipo de GUI personalizada (probablemente complicada).
Evicatos
10

El código es datos.

O más bien, los programas son datos. Un archivo fuente es solo una serialización específica de este programa. Esta idea es, por ejemplo, común en lenguajes homoicónicos como Lisp. Tal lenguaje derriba las barreras entre el código del programa y los datos en los que está operando. Esto puede ser extremadamente poderoso y expresivo, aunque no llamaría a la apariencia del código Lisp "hermosa" o "fácil de leer".

XML es el formato de serialización de datos estructurados para el programador empresarial actual. Existen grandes cadenas de herramientas establecidas alrededor del procesamiento XML.

  • La definición de un lenguaje destinado a operar en XML en XML puede ser interesante debido a esta homoiconicidad. Un ejemplo es XSLT. En teoría, esto permite la metaprogramación, pero ninguna persona cuerda haría esto, ¿verdad?
  • Los lenguajes de plantilla están interesados ​​en tener poca separación entre datos y código. Usar un documento XML como plantilla / programa es interesante cuando la salida es XML o HTML.
  • Almacenar código de un lenguaje de propósito general en XML aún puede ser interesante. Almacenar un árbol de sintaxis abstracta serializado en XML en lugar de código fuente es viable cuando este código se manipula a través de un IDE, donde se presenta en una forma más legible para los humanos, por ejemplo, para programación visual . Esto no es diferente a los entornos Smalltalk, donde el "código fuente" es solo una representación de la imagen de bytecode real.

Curiosamente, los documentos XML a veces se utilizan para crear plantillas de código ... * shudder * (inyección de dependencia). Atribuyo esto a la ubicuidad de XML en algunas cadenas de herramientas / el mindhare XML tiene como formato de datos estructurados.

amon
fuente
1
Combinar código con datos no es una ventaja; Es un agujero de seguridad a nivel de idioma. El ejemplo clásico es la inyección SQL: cada vez que se piratea un sitio y se hace un daño de millones de dólares y decenas de miles de usuarios tienen que pedir nuevas tarjetas de crédito debido a una explotación de inyección SQL, la razón fundamental es porque algún desarrollador estableció una consulta de alguna manera que no separó correctamente los datos del código. Lanzar palabras elegantes como "homoiconicidad" no cambia este hecho fundamental.
Mason Wheeler
55
@MasonWheeler No estoy en desacuerdo en absoluto que es necesario escapar adecuadamente desde una perspectiva de seguridad para cada sistema de plantillas, pero esto no tiene nada que ver con la pregunta, mi respuesta o la separación del código de datos. No me asustan los rwxscripts que tengo, que son datos para mi editor, pero código ejecutable para mi shell.
amon
1
El hecho de que intente responder a esto en términos de escapar en primer lugar, que es y siempre ha sido la forma incorrecta de evitar la inyección de SQL, y no en términos de separación de código de datos a través de Parámetros, que es la única forma correcta de hacerlo: muestra que realmente no entiendes el problema. Y es por eso que los ataques de inyección SQL siguen sucediendo: las personas no entienden por qué estas cosas son importantes y cómo hacerlas bien.
Mason Wheeler
77
@MasonWheeler: sus críticos de "combinar código con datos" son correctos cuando obtiene datos de fuentes externas y crea código a partir de eso (que, por cierto, de ninguna manera es especial para XML). Pero esta respuesta tiene un enfoque completamente diferente, se trata del aspecto de la metaprogramación.
Doc Brown
66
@MasonWheeler, la inyección está ejecutando datos que no deberían ejecutarse. La homoiconicidad significa que el código y los datos son muy parecidos, en forma literal y en manipulación programática. Un lenguaje homoicónico puede manipular y ejecutar de forma segura (código generado a partir de) datos confiables, ya sea codificados en su código fuente o de otra manera. En, por ejemplo, Common Lisp, puede incluir datos en el código generado sin que se ejecute, como (eval `(foo (quote ,data))). Su argumento sobre los parámetros frente a escapar puede ser correcto, pero se perdió el punto.
Acelerado
2

Me concentraré en XSLT en lugar de lenguajes basados ​​en XML en general.

Hay una historia aquí, por supuesto. XSLT fue concebido como un sucesor de DSSSL, el lenguaje de estilo para SGML, y trató de corregir lo que DSSSL había hecho mal. Uno de los principales problemas con DSSSL se percibía como su sintaxis (tipo Esquema), y había una sensación generalizada de que la solución estaba en usar la misma sintaxis para la hoja de estilo y los datos; después de todo, la idea era que una hoja de estilo debería consistir principalmente en datos estructurados en lugar de lógica de programa, y ​​gran parte de esos datos consistirían en datos proforma ("plantilla") para agregar al árbol de resultados, con alguna parametrización.

XSLT a menudo se percibe como excesivamente detallado. Para XSLT 1.0, que desafortunadamente muchas personas todavía usan, probablemente sea cierto, pero el problema se resolvió en gran medida con XSLT 2.0, que a menudo es mucho más conciso que otras formas de resolver el mismo problema.

Ciertamente hay inconvenientes. Estás bastante obligado a usar un editor diseñado específicamente (pero, entonces, la mayoría de los programadores usan editores dirigidos por sintaxis para cada idioma, ¿no es así?). El lenguaje no es tan fácil de componer como podría ser (aunque de nuevo, XSLT 2.0 lo corrige en gran medida). Pero también hay ventajas significativas:

  1. XSLT es ampliamente utilizado por no programadores, y para ellos es una gran ventaja que solo tengan que aprender una sintaxis, no dos. Recuerde, se trata de todos los pequeños detalles, como cómo manejar la codificación de caracteres y el escape de caracteres especiales.

  2. La capacidad de procesar código XSLT usando XSLT es mucho más útil de lo que puedas imaginar. Casi todos los grandes proyectos XSLT aprovechan esta capacidad y pueden aportar grandes beneficios. Por ejemplo, vi un sistema de banca en línea que tenía un par de cientos de formas en su interfaz de usuario, cada una generada por su propia hoja de estilo, pero las hojas de estilo se generaron a partir de una biblioteca de código común que proporciona una gran reutilización y consistencia de apariencia.

  3. Hay un beneficio que no hubiera esperado, y es que el uso de un marco sintáctico restringido como XML obliga a los diseñadores del lenguaje a mantener un nivel de consistencia léxica a medida que el lenguaje evoluciona y al mismo tiempo proporciona una gran extensibilidad. XQuery WG siempre está debatiendo cómo extender el lenguaje sin romper la compatibilidad o introducir peculiaridades; XSLT no tiene tales problemas, porque se trata básicamente de definir nuevos elementos y atributos.

Michael Kay
fuente
0

Podría ver que algo así es útil en un entorno con gran cantidad de XML (piense en XSLT), donde presumiblemente ya tiene editores XML decentes y podría ser útil poder generar código usando el mismo conjunto de herramientas. También podría facilitar la escritura de verificadores de corrección u otras herramientas para garantizar que el código siga ciertos estándares o reglas (por ejemplo, un esquema define hacia dónde debe ir la lógica de negocios y / o asegura que todas las variables se inicialicen de manera consistente )

TMN
fuente
0

XSLT es el único lenguaje de programación XML que he usado, no he tenido la oportunidad de entrar en los demás.

tenemos una aplicación principal que dispara un archivo XML a una base de datos, y varias otras aplicaciones pueden tomar ese archivo y aplicarle un archivo XSLT para extraer los datos que esas otras aplicaciones necesitan, esto alivia la necesidad de exportar un nuevo conjunto de Datos para cada nueva aplicación que viene. Creo que es una gran ventaja. solo tiene que codificar un archivo XSLT para la nueva aplicación para decodificar la información que ya se está produciendo en lugar de tener que producir nueva información para una nueva aplicación.

Me doy cuenta de que no he tocado ninguno de los otros idiomas que ha enumerado, pero le he dado una idea de un buen lugar para el uso de dicho idioma. Todavía no estoy seguro de si respondí completamente o incluso parcialmente a su pregunta. pero espero haber dado alguna idea.

Malaquías
fuente
2
No, las preguntas preguntan por qué XSLT debería ser XML en sí mismo. La cadena de herramientas que ha descrito podría haberse implementado igual de bien con un script Perl o Python que analiza el XML de salida y genera algo de salida a partir de eso. La interesante decisión de diseño sobre XSLT no es que pueda transformar XML, sino más bien que no usa llaves ”
amon
o punto y coma? Veo lo que dices. cualquier lenguaje realmente podría analizar esa información fuera del documento XML, por lo que la pregunta sería "¿por qué necesitarían un lenguaje de transformación XML", ¿verdad?
Malaquías
No, un lenguaje de transformación XML tiene sentido (si está haciendo mucha transformación XML). Hay muchas cosas que XSLT hace para admitir el procesamiento XML (como la capacidad de recorrer y consultar fácilmente el árbol DOM), pero ser XML en sí mismo no está entre esas cosas.
Estaba tratando de aclarar la pregunta con mi último comentario @delnan. Entiendo y acepto que XSLT es una buena herramienta para tener.
Malaquías el
-3

XML casi no tiene sentido en ausencia de contexto histórico y político. SGML fue aún más difícil de escribir, leer y mantener, pero tenía el sello de aprobación ISO puesto en 1986, lo que lo convirtió quizás en el primer lenguaje de declaración de datos en tener tal impronta.

Fue lo suficientemente útil y documentado para inspirar a Tim Berners-Lee a usarlo como la base del HTML a principios de los años noventa. Recuerde, tenía la intención de crear una red mundial y basarla en un estándar ISO existente ayudaría aún más.

Luego, a fines de la década de 1990, con la web bastante bien arraigada, el Consorcio World Wide Web comenzó una iniciativa para el marcado estructural estándar para el intercambio de datos. El factor de exageración que rodea al XML alcanzó niveles sin precedentes de "no estamos seguros de qué hacer con esto, pero apuesto a que será realmente genial".

Tal como está, para lo que XML es principalmente bueno es para el intercambio estructurado de datos entre sistemas dispares. Como ha señalado amon, hay algunos dominios específicos donde tiene una utilidad más amplia. Me alegra que ahora sea posible codificar graffiti en un marcado estandarizado para que, en el futuro, los niños no tengan que arriesgar la vida y el enjuiciamiento, sino que etiqueten con drones controlados por pintura con control remoto.

msw
fuente