tutorial example xml xslt

xml - example - xslt tutorial



¿Vale la pena XSLT? (30)

Hace un tiempo, comencé un proyecto en el que diseñé un esquema XML html-esque para que los autores pudieran escribir su contenido (material del curso educativo) en un formato simplificado que luego se transformaría en HTML a través de XSLT. Jugué (forcejeé) con eso por un tiempo y llegué a un nivel muy básico, pero luego me molestaron demasiado las limitaciones que estaba encontrando (que bien podrían haber sido limitaciones de mi conocimiento) y cuando leí un blog sugiriendo que abandonara XSLT y simplemente escribe tu propio analizador de XML a lo que prefieras en tu idioma de elección, ansiosamente salté sobre eso y funcionó brillantemente.

Todavía estoy trabajando en ello hasta el día de hoy (se supone que estoy trabajando en ello ahora, en lugar de jugar en SO ), y estoy viendo más y más cosas que me hacen pensar que la decisión de abandonar el XSLT fue una buena.

Sé que XSLT tiene su lugar, ya que es un estándar aceptado, y que si todos escriben sus propios intérpretes, el 90% de ellos terminará en TheDailyWTF . Pero dado que es un lenguaje de estilo funcional en lugar del estilo de procedimiento con el que la mayoría de los programadores están familiarizados, para alguien que se embarca en un proyecto como el mío, recomendaría que siguieran el camino que yo hice, o lo superaran con XSLT ?

¡Tanta negatividad!

He estado usando XSLT durante algunos años y realmente me encanta. La clave que debe tener en cuenta es que no es un lenguaje de programación, es un lenguaje de plantillas (y en este sentido, me parece indescriptiblemente superior a asp.net / spit).

XML es el formato de datos de facto del desarrollo web en la actualidad, ya sean archivos de configuración, datos brutos o en representación de memoria. XSLT y XPath le brindan una forma enormemente poderosa y muy eficiente de transformar esos datos en cualquier formato de salida que le pueda gustar, dándole instantáneamente el aspecto de MVC de separar la presentación de los datos.

Luego están las habilidades de utilidad: eliminar espacios de nombres, reconocer definiciones de esquemas dispares, fusionar documentos.

Debe ser mejor tratar con XSLT que desarrollar sus propios métodos internos. Al menos XSLT es un estándar y algo para lo que podrías contratar, y si alguna vez es realmente un problema para tu equipo, es muy natural que te permita mantener a la mayor parte de tu equipo trabajando solo con XML.

Un caso de uso del mundo real: Acabo de escribir una aplicación que maneja documentos XML en memoria en todo el sistema y se transforma en JSON, HTML o XML según lo solicite el usuario final. Tuve una solicitud bastante aleatoria para proporcionar datos de Excel. Un antiguo colega había hecho algo similar programáticamente pero requería un módulo de algunos archivos de clase y ¡el servidor tenía MS Office instalado! Resulta que Excel tiene un XSD: nueva funcionalidad con un impacto mínimo en el código base en 3 horas.

Personalmente creo que es una de las cosas más limpias que he encontrado en mi carrera, y creo que todos sus problemas aparentes (depuración, manipulación de cadenas, estructuras de programación) se deben a una comprensión errónea de la herramienta.

Obviamente, creo firmemente que "vale la pena".

Actualmente tengo la tarea de recopilar datos de un sitio público (sí, lo sé). Afortunadamente se ajusta a xhtml, así que puedo usar xslt para reunir los datos que necesito. La solución resultante es legible, limpia y fácil de cambiar si es necesario. ¡Perfecto!

Debo admitir un sesgo aquí porque enseño XSLT para ganarme la vida. Pero, valdría la pena cubrir las áreas en las que veo a mis alumnos trabajando. Se dividen en tres grupos en general: publicación, banca y web.

Muchas de las respuestas hasta ahora se pueden resumir como "no sirve para crear sitios web" o "no se parece en nada al lenguaje X". Muchas personas de tecnología pasan por sus carreras sin exposición a los lenguajes funcionales / declarativos. Cuando estoy enseñando, los expertos en Java / VB / C / etc son los que tienen problemas con el lenguaje (las variables son variables en el sentido del álgebra, no la programación de procedimientos, por ejemplo). Esa es la mayoría de las personas que responden aquí. Nunca me he acostumbrado a Java, pero no voy a molestarme en criticar el idioma por eso.

En muchas circunstancias, es una herramienta inapropiada para crear sitios web; un lenguaje de programación de propósito general puede ser mejor. A menudo necesito tomar documentos XML muy grandes y presentarlos en la web; XSLT lo hace trivial. Los estudiantes que veo en este espacio tienden a procesar conjuntos de datos y presentarlos en la web. XSLT ciertamente no es la única herramienta aplicable en este espacio. Sin embargo, muchos de ellos están usando DOM para hacer esto y XSLT es ciertamente menos doloroso.

Los estudiantes de banca que veo usan una caja de DataPower en general. Este es un dispositivo XML y se usa para sentarse entre servicios que hablan diferentes dialectos XML. La transformación de un lenguaje XML a otro es casi trivial en XSLT y el número de estudiantes que asisten a mis cursos en este sentido está aumentando.

El conjunto final de estudiantes que veo proviene de un fondo editorial (como yo). Estas personas tienden a tener documentos inmensos en XML (créanme, la publicación como una industria se está volcando mucho en XML, la publicación técnica ha estado allí durante años y la publicación comercial está llegando ahora). Estos documentos deben procesarse (aquí viene a la mente el DocBook to ePub).

Alguien más arriba comentó que los guiones tienden a estar por debajo de las 60 líneas o se vuelven poco manejables. Si se vuelve difícil de manejar, lo más probable es que el codificador no haya captado la idea: XSLT es una mentalidad muy diferente a la de muchos otros idiomas. Si no tienes la mentalidad, no funcionará.

Ciertamente no es un lenguaje moribundo (la cantidad de trabajo que recibo me lo dice). En este momento, está un poco ''estancado'' hasta que Microsoft termine su implementación (muy tarde) de XSLT 2. Pero todavía está ahí y parece ir fuerte desde mi punto de vista.

Definitivamente recomendaría aguantar. Particularmente si está usando Visual Studio que tiene herramientas integradas de edición, visualización y depuración para XSLT.

Sí, es un dolor mientras estás aprendiendo, pero la mayor parte del dolor tiene que ver con la familiaridad. El dolor disminuye a medida que aprendes el lenguaje.

W3schools tiene dos artículos que son de particular valor: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Disfruto usando XSLT solo para cambiar la estructura de árbol de documentos XML. Me resulta engorroso hacer cualquier cosa relacionada con el procesamiento de texto y relegarlo a un script personalizado que pueda ejecutar antes o después de aplicar un XSLT a un documento XML.

XSLT 2.0 incluyó muchas más funciones de cadenas, pero creo que no es una buena opción para el lenguaje, y no hay muchas implementaciones de XSLT 2.0.

En una empresa anterior hicimos mucho con XML y XSLT. Tanto XML como XSLT grandes.

Sí, hay una curva de aprendizaje, pero luego tienes una poderosa herramienta para manejar XML. E incluso puedes usar XSLT en XSLT (que a veces puede ser útil).

El rendimiento también es un problema (con XML muy grande), pero puede abordarlo mediante el uso de XSLT inteligente y hacer algún preprocesamiento con el XML (generado).

Cualquiera con conocimiento de XSLT puede cambiar la apariencia del producto final porque no está compilado.

Es difícil trabajar con XSLT, pero una vez que lo conquistes, tendrás una comprensión muy completa del DOM y el esquema. Si también es XPath, entonces está en camino a aprender programación funcional y esto expondrá nuevas técnicas y formas de resolver problemas. En algunos casos, la transformación sucesiva es más poderosa que las soluciones de procedimiento.

He descubierto que XSLT es bastante difícil de trabajar.

He tenido experiencia trabajando en un sistema similar al que describes. Mi compañía notó que los datos que regresábamos de "la capa intermedia" estaban en XML, y que las páginas debían ser renderizadas en HTML, lo que también podría ser XHTML, además de que habían escuchado que XSL era un estándar para la transformación entre XML. formatos. Entonces los "arquitectos" (me refiero a personas que piensan en pensamientos de diseño profundo pero aparentemente nunca codifican) decidieron que nuestro nivel frontal se implementaría escribiendo scripts XSLT que transformaran los datos en el XHTML para su visualización.

La elección resultó ser desastrosa. XSLT, resulta que es un dolor escribir. Y entonces todas nuestras páginas fueron difíciles de escribir y mantener. Habríamos sido mucho mejores si hubiésemos utilizado JSP (esto era en Java) o algún enfoque similar que utilizara un tipo de marcado (corchetes angulares) para el formato de salida (el HTML) y otro tipo de marcado (como <% ... %>) para los metadatos. Lo más confuso de XSLT es que está escrito en XML, y se traduce de XML a XML ... es bastante difícil mantener los 3 diferentes documentos XML directamente en la mente.

Su situación es ligeramente diferente: en lugar de crear cada página en XSLT como lo hice, solo necesita escribir UN bit de código en XSLT (el código para convertir de las plantillas a visualización). Pero parece que te has encontrado con el mismo tipo de dificultad que yo. Diría que tratar de interpretar un simple DSL basado en XML (lenguaje específico del dominio) como lo está haciendo NO es uno de los puntos fuertes de XSLT. (Aunque PUEDE hacer el trabajo ... después de todo, ¡TODO está listo!)

Sin embargo, si lo que tenía era más simple: tenía datos en un formato XML y quería hacer alteraciones simples en él, no una descripción completa de la página DSL, sino algunas modificaciones simples y directas, entonces XSLT es una excelente herramienta para ese fin. Su naturaleza declarativa (no procesal) es en realidad una ventaja para ese propósito.

- Michael Chermside

He pasado mucho tiempo en XSLT y he descubierto que si bien es una herramienta útil en algunas situaciones, definitivamente no es una solución para todos. Funciona muy bien para fines B2B cuando se utiliza para la traducción de datos para entrada / salida XML legible por máquina. No creo que esté en el camino equivocado en su declaración de sus limitaciones. Una de las cosas que más me frustró fueron los matices en las implementaciones de XSLT.

Tal vez debería ver algunos de los otros lenguajes de marcado disponibles. Creo que Jeff hizo un artículo sobre este tema relacionado con .

¿HTML es un lenguaje humano de marcado?

Echaré un vistazo a lo que escribió. Probablemente pueda encontrar un paquete de software que haga lo que quiere "de fábrica", o al menos muy cerca, en lugar de escribir sus propias cosas desde cero.

He usado XSLT (y también XQuery) extensamente para varias cosas: generar código C ++ como parte del proceso de compilación, producir documentación a partir de comentarios de doc, y dentro de una aplicación que tuvo que trabajar con XML en general y XHTML en particular mucho. . El generador de códigos en particular tenía más de 10,000 líneas de código XSLT 2.0 distribuidas en una docena de archivos separados (hizo muchas cosas: encabezados para clientes, proxy remotos, contenedores COM, contenedores .NET, ORM) para nombrar unos pocos). Lo heredé por otro chico que no entendía bien el lenguaje, y las partes más antiguas eran en consecuencia un desastre. Sin embargo, las cosas más nuevas que escribimos se mantuvieron más sanas y legibles, y no recuerdo ningún problema particular para lograr eso. Ciertamente no fue más difícil que hacerlo por C ++.

Hablando de versiones, lidiar con XSLT 2.0 definitivamente te ayuda a mantenerte sano, pero 1.0 sigue estando bien para las transformaciones más simples. En su nicho, es una herramienta extremadamente útil, y la productividad que obtiene de ciertas características específicas del dominio (lo más importante, el despacho dinámico a través de la coincidencia de plantillas) es difícil de igualar. A pesar de la verborrea percibida de la sintaxis basada en XML de XSLT, lo mismo en LINQ to XML (incluso en VB con literales XML) generalmente era varias veces más largo. Muy a menudo, sin embargo, se vuelve inútil debido al uso innecesario de XML en algún caso en primer lugar.

En resumen: es una herramienta increíblemente útil para tener en la caja de herramientas de uno, pero es muy especializada, por lo que es bueno siempre y cuando la uses correctamente y para el propósito previsto. Realmente me gustaría que hubiera una implementación nativa de .NET de XSLT 2.0.

He usado XSLT antes. El grupo de 6 archivos .xslt (refactorizados a partir de uno grande) tenía aproximadamente 2750 líneas antes de volver a escribirlo en C #. El código C # es actualmente 4000 líneas que contienen mucha lógica; Ni siquiera quiero pensar en lo que habría llevado escribir en XSLT.

El punto donde me rendí fue cuando me di cuenta de que no tener XPATH 2.0 estaba perjudicando significativamente mi progreso.

La especificación XSLT define XSLT como "un lenguaje para transformar documentos XML en otros documentos XML". Si está tratando de hacer algo más que el procesamiento de datos más básico dentro de XSLT, probablemente haya mejores soluciones.

También vale la pena señalar que las capacidades de procesamiento de datos de XSLT se pueden extender en .NET usando funciones de extensión personalizadas:

Mantengo un sistema de documentación en línea para mi empresa. Los escritores crean la documentación en SGML (un lenguaje similar a xml). El SGML se combina con XSLT y se transforma en HTML.

Esto nos permite realizar cambios en el diseño de la documentación fácilmente sin hacer ninguna codificación. Es solo cuestión de cambiar el XSLT.

Esto funciona bien para nosotros En nuestro caso, es un documento de solo lectura. El usuario no está interactuando con la documentación.

Además, al usar XSLT, está trabajando más cerca de su dominio problemático (HTML). Siempre lo considero una buena idea.

Por último, si su sistema actual FUNCIONA, déjelo en paz. Nunca recomendaría destrozar tu código existente. Si estuviera empezando desde cero, usaría XSLT, pero en su caso, usaría lo que tiene.

Para responder a sus tres preguntas:

  1. He usado XSLT una vez hace algunos años.
  2. Creo que XSLT podría ser la solución adecuada en ciertas circunstancias. (Nunca digas nunca)
  3. Tiendo a estar de acuerdo con su opinión de que es principalmente útil para transformaciones ''simples''. Pero creo que siempre que comprenda bien el XSLT, se puede argumentar a favor de usarlo para tareas más grandes, como publicar un sitio web como XML transformado en HTML.

Creo que la razón por la que a muchos desarrolladores no les gusta XSLT es porque no entienden el paradigma fundamentalmente diferente en el que se basa. Pero con el reciente interés en la programación funcional, podríamos ver a XSLT haciendo una reaparición ...

Personalmente me gusta XSLT, y es posible que desee darle un vistazo a la sintaxis simplificada (sin plantillas explícitas, solo un archivo HTML antiguo normal con algunas etiquetas XSLT para escupir valores), pero simplemente no es para todos.

Tal vez solo quiera ofrecer a sus autores una interfaz sencilla de Wiki o Markdown. También hay bibliotecas para eso, y si XSLT no funciona para usted, quizás XML tampoco funcione para ellos.

Personalmente utilicé XSLT en un contexto totalmente diferente. El juego de computadora en el que estaba trabajando usó toneladas de páginas de interfaz de usuario definidas usando XML. Durante un refactor importante poco después de un lanzamiento, queríamos cambiar la estructura de estos documentos XML. Hicimos que el formato de entrada del juego siguiera una estructura mucho mejor y consciente del esquema.

XSLT parecía ser la elección perfecta para esta traducción del formato antiguo -> Nuevo formato. En dos semanas tuve una conversión activa de vieja a nueva para nuestros cientos de páginas. También pude usarlo para extraer mucha información sobre el diseño de nuestras páginas de interfaz de usuario. Creé listas de los componentes que estaban incrustados en los cuales, relativamente fácil, utilicé XSLT para escribir en las definiciones de nuestro esquema.

Además, viniendo de un fondo de C ++, era un lenguaje muy divertido e interesante de dominar.

Creo que es una herramienta fantástica para traducir XML de un formato a otro. Sin embargo, no es la única forma de definir un algoritmo que toma XML como entrada y genera algo . Si su algoritmo es lo suficientemente complejo, el hecho de que la entrada sea XML se vuelve irrelevante para la herramienta que elija, es decir, ejecute la suya en C ++ / Python / lo que sea.

Específico para su ejemplo, me imagino que la mejor idea sería crear su propia conversión XML-> XML que siga su lógica comercial. A continuación, escriba un traductor XSLT que solo sepa sobre el formateo y no haga nada inteligente. Ese podría ser un buen término medio pero depende totalmente de lo que estés haciendo. Tener un traductor XSLT en la salida facilita la creación de formatos de salida alternativos: imprimible, para móviles, etc.

Recuerdo todo el bombo alrededor de XSLT cuando el estándar fue lanzado recientemente. Toda la emoción en torno a poder construir una interfaz de usuario HTML completa con una transformación ''simple''.

Admitámoslo, es difícil de usar, casi imposible de depurar, a menudo insoportablemente lento. El resultado final es casi siempre peculiar y menos que ideal.

Antes me arrancaré la pierna que usaré un XSLT mientras haya mejores formas de hacer las cosas. Todavía tiene su lugar, es bueno para tareas simples de transformación.

Sí, lo uso mucho. Al usar diferentes archivos xslt, puedo usar la misma fuente XML para crear múltiples archivos HTML políglotas (X) (presentando los mismos datos de diferentes maneras), una fuente RSS, una fuente Atom, un archivo descriptor RDF y un fragmento de un mapa del sitio .

No es una panacea Hay cosas que hace bien, y las cosas no funcionan bien, y como todos los demás aspectos de la programación, se trata de usar la herramienta adecuada para el trabajo correcto. Es una herramienta que bien vale la pena tener en su caja de herramientas, pero debe usarse solo cuando sea apropiado hacerlo.

Si puede usar XSLT en un estilo declarativo (aunque no estoy del todo de acuerdo en que sea un lenguaje declarativo), entonces creo que es útil y expresivo.

He escrito aplicaciones web que usan un lenguaje OO (C # en mi caso) para manejar la capa de datos / procesamiento, pero generan XML en lugar de HTML. Esto puede ser consumido directamente por los clientes como una API de datos, o traducidos como HTML por XSLT. Debido a que C # estaba generando XML que era estructuralmente compatible con este uso, todo fue muy sencillo, y la lógica de presentación se mantuvo declarativa. Era más fácil de seguir y cambiar que enviar las etiquetas desde C #.

Sin embargo, como requiere más lógica de procesamiento en el nivel XSLT, se vuelve intrincado y prolijo, incluso si "obtiene" el estilo funcional.

Por supuesto, en estos días probablemente habría escrito esas aplicaciones web usando una interfaz RESTful, y creo que los "lenguajes" de datos como JSON están ganando tracción en las áreas en las que tradicionalmente XML ha sido transformado por XSLT. Pero por ahora XSLT sigue siendo una tecnología importante y útil.

Solía ​​pensar que XSLT era una gran idea. Quiero decir que es una gran idea.

Donde falla es la ejecución.

El problema que descubrí con el tiempo fue que los lenguajes de programación en XML son solo una mala idea. Lo hace todo impenetrable. Específicamente, creo que XSLT es muy difícil de aprender, codificar y comprender. El XML en la parte superior de los aspectos funcionales simplemente hace que todo sea demasiado confuso. Intenté aprenderlo unas 5 veces en mi carrera, y simplemente no funciona.

De acuerdo, podría ''herramienta'' - creo que fue en parte el objetivo de su diseño - pero esa es la segunda falla: todas las herramientas XSLT en el mercado son, simplemente ... ¡mierda!

Todavía creo que XSLT puede ser útil, pero es un lenguaje feo y puede llevar a un lío horrible, ilegible e inmanejable. En parte porque XML no es lo suficientemente legible para los humanos como para formar un "lenguaje" y en parte porque XSLT está atascado en algún lugar entre declarativo y de procedimiento. Habiendo dicho eso, y creo que se puede hacer una comparación con expresiones regulares, tiene sus usos cuando se trata de problemas simples bien definidos.

Usar el enfoque alternativo y analizar XML en el código puede ser igualmente repugnante y realmente desea emplear algún tipo de tecnología de vinculación / vinculación de XML (como JiBX en Java) que convierta su XML directamente a un objeto.

Todo se reduce a lo que necesita. Su principal fortaleza es la fácil mantenibilidad de la transformación, y escribir su propio analizador generalmente lo borra. Dicho esto, a veces un sistema es pequeño y simple y realmente no necesita una solución "sofisticada". Siempre que su constructor basado en código sea reemplazable sin tener que cambiar otro código, no es gran cosa.

En cuanto a la fealdad de XSL, sí, es feo. Sí, toma un tiempo acostumbrarse. Pero una vez que te acostumbras (no debería tomar un IMO largo), en realidad es una navegación fluida. Las transformaciones compiladas se ejecutan bastante rápido en mi experiencia, y ciertamente puedes depurarlas.

Un lugar donde xslt realmente brilla es generando informes. Encontré un proceso de 2 pasos, con el primer paso exportando los datos del informe como un archivo xml, y el segundo paso generando el informe visual del xml usando xslt. Esto permite buenos informes visuales mientras se mantienen los datos sin procesar como un mecanismo de validación si es necesario.

Usé XML, XSD y XSLT en un proyecto de integración entre sistemas de bases de datos muy similares en 2004. Tuve que aprender XSD y XSLT desde cero, pero no fue difícil. Lo bueno de estas herramientas fue que me permitió escribir código C ++ independiente de los datos, confiando en XSD y XSLT para validar / verificar y luego transformar los documentos XML. Cambie el formato de datos, cambie los documentos XSD y XSLT, no el código C ++ que utilizó las bibliotecas Xerces.

Para mayor interés: el XSD principal era de 150 KB y el tamaño promedio del XSLT era <5 KB IIRC.

El otro gran beneficio es que el XSD es un documento de especificación en el que se basa el XSLT. Los dos trabajan en armonía. Y las especificaciones son raras en el desarrollo de software en estos días.

Aunque no tuve demasiados problemas para aprender la naturaleza declarativa XSD y XSLT, encontré que otros programadores de C / C ++ tenían grandes problemas para ajustarse a la manera declarativa. Cuando vieron eso, ah procedimental murmuraron, ¡ahora que lo entiendo! Y procedieron (¿juego de palabras?) A escribir XSLT de procedimiento. Lo que pasa es que debes aprender XPath y comprender los ejes de XML. Me recuerda a los programadores antiguos de C que se ajustan al empleo de OO cuando escriben C ++.

Utilicé estas herramientas, ya que me permitieron escribir una pequeña base de código C ++ que estaba aislada de todas las modificaciones de la estructura de datos excepto la más fundamental, y estas últimas eran cambios en la estructura de la BD. Aunque prefiero C ++ a cualquier otro idioma, utilizaré lo que considero útil para beneficiar la viabilidad a largo plazo de un proyecto de software.

Usamos XSLT extensamente para cosas como la documentación, y hacemos que algunas configuraciones de configuración complejas puedan ser reparadas por el usuario.

Para la documentación, usamos mucho DocBook, que es un formato basado en XML. Esto nos permite almacenar y administrar nuestra documentación con todo nuestro código fuente, ya que los archivos son de texto plano. Con XSLT, podemos construir fácilmente nuestros propios formatos de documentación, lo que nos permite generar automáticamente el contenido de una manera genérica y hacer que el contenido sea más legible. Por ejemplo, cuando publicamos notas de la versión, podemos crear XML que se parece a algo así como:

<ReleaseNotes> <FixedBugs> <Bug id="123" component="Admin">Error when clicking the Foo button</Bug> <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug> <Bug id="127" component="Admin">Error when clicking the Bar button</Bug> </FixedBugs> </ReleaseNotes>

Y luego, usando XSLT (que transforma lo anterior en DocBook), terminamos con buenas notas de lanzamiento (PDF o HTML generalmente) donde los identificadores de errores se vinculan automáticamente a nuestro rastreador de errores, los errores se agrupan por componente y el formato de todo es perfectamente consistente . Y el XML anterior se puede generar automáticamente al consultar nuestro rastreador de errores para ver qué ha cambiado entre versiones.

El otro lugar donde hemos encontrado que XSLT es útil está en realidad en nuestro producto principal. A veces, al interactuar con sistemas de terceros, tenemos que procesar datos de alguna manera en una página HTML compleja. Analizar HTML es feo, por lo que alimentamos los datos a través de algo como TagSoup (que genera eventos XML SAX correctos, esencialmente dejándonos tratar con el HTML como si estuviera escrito correctamente XML) y luego podemos ejecutar algunos XSLT contra él, para convertir el datos en un formato "estable conocido" con el que podamos trabajar. Al separar esa transformación en un archivo XSLT, eso significa que, si cambia el formato HTML, la aplicación no necesita actualizarse, sino que el usuario final solo puede editar el archivo XSLT, o podemos enviar un correo electrónico. un archivo XSLT actualizado sin necesidad de actualizar todo el sistema.

Diría que para proyectos web, hay mejores formas de manejar el lado de la vista que XSLT hoy en día, pero como tecnología definitivamente hay usos para XSLT. No es el idioma más fácil de usar en el mundo, pero definitivamente no está muerto, y desde mi punto de vista todavía tiene muchos buenos usos.

Uso XSLT (a falta de una mejor alternativa), pero no para la presentación, solo para la transformación:

  1. Escribo transformaciones cortas en XSLT para hacer ediciones masivas en nuestros archivos maven pom.xml.

  2. He escrito una serie de transformaciones para generar esquemas XML de XMI (Diagrama UML). Funcionó por un tiempo, pero finalmente se volvió demasiado complejo y tuvimos que sacarlo detrás del granero.

  3. He utilizado transformaciones para refactorizar esquemas XML.

  4. He solucionado algunas limitaciones en XSLT usándolo para generar un XSLT para hacer el trabajo real. (¿Alguna vez intentó escribir un XSLT que produce una salida utilizando espacios de nombres que no se conocen hasta el tiempo de ejecución?)

Sigo volviendo a esto porque hace un mejor trabajo al hacer una ronda: tropezar con el XML que está procesando que con otros enfoques que he probado, que parecen innecesariamente con pérdidas o simplemente malinterpretar XML. XSLT es desagradable, pero encuentro que usar Oxygen hace soportable.

Dicho esto, estoy investigando el uso de Clojure (un lisp) para realizar transformaciones de XML, pero aún no he llegado lo suficiente como para saber si ese enfoque me traerá beneficios.

Uso XSLT extensamente, para un front-end personalizado de estilo MVC. El modelo se "serializa" a xml (no a través de xml serializaiton), y luego se convierte a html a través de xslt. La ventaja sobre ASP.NET radica en la integración natural con XPath y los requisitos más rigurosos de buena formación (es mucho más fácil razonar sobre la estructura del documento en xslt que en la mayoría de los demás lenguajes).

Desafortunadamente, el lenguaje contiene varias limitaciones (por ejemplo, la capacidad de transformar el resultado de otra transformación) lo que significa que ocasionalmente es frustrante trabajar con él.

Sin embargo, la separación de las inquietudes que se otorga fácilmente y que se puede aplicar con facilidad, no es algo que vea que otra tecnología ofrezca en este momento, por lo que para las transformaciones de documentos sigue siendo algo que recomendaría.

Ventajas de XSLT:

  • Dominio específico para XML, por lo que no es necesario citar literal XML en el resultado.
  • Admite XPath / XQuery, que puede ser una buena forma de consultar los DOM, de la misma manera que las expresiones regulares pueden ser una buena forma de consultar cadenas.
  • Idioma funcional.

Desventajas de XSLT:

  • Puede ser obsceno y prolijo: no tiene que citar XML literal, lo que significa que tiene que citar código. Y no de una manera bonita. Pero, una vez más, no es mucho peor que su SSI típico.
  • No hace ciertas cosas que la mayoría de los programadores dan por hecho. Por ejemplo, la manipulación de cadenas puede ser una tarea difícil. Esto puede conducir a "momentos desafortunados" cuando los novatos diseñan el código, luego buscan frenéticamente en la web para obtener pistas sobre cómo implementar funciones que suponían que simplemente estarían allí y no se dieron tiempo para escribir.
  • Idioma funcional.

Una forma de obtener un comportamiento de procedimiento, por cierto, es encadenar múltiples transformaciones juntas. Después de cada paso, tiene un nuevo DOM para trabajar que refleja los cambios en ese paso. Algunos procesadores XSL tienen extensiones para hacer esto de manera efectiva en una transformación, pero olvido los detalles.

Por lo tanto, si su código es principalmente de salida y no tiene mucha lógica, XSLT puede ser una forma muy clara de expresarlo. Si hay mucha lógica, pero principalmente de formularios que están incorporados en XSLT (seleccione todos los elementos que parecen bla, y para cada uno de ellos, bla), es probable que sea un entorno bastante amigable. Si te apetece pensar XML-ishly en todo momento, dale una oportunidad a XSLT 2.

De lo contrario, diría que si su lenguaje de programación favorito tiene una buena implementación DOM soportando XPath y permitiéndole construir documentos de una manera útil, entonces hay algunos beneficios al usar XSLT. Los enlaces a libxml2 y gdome2 deberían funcionar muy bien, y no hay que avergonzarse por seguir apegados a los lenguajes de uso general que conoces bien.

Los analizadores de XML de uso doméstico generalmente están incompletos (en cuyo caso se despegará algún día) o no son mucho más pequeños que lo que podría haber obtenido de la estantería (en cuyo caso probablemente esté perdiendo el tiempo), y dan tiene muchas oportunidades para introducir problemas de seguridad graves en torno a entradas maliciosas. No escriba uno a menos que sepa exactamente lo que gana al hacerlo. Lo que no quiere decir que no pueda escribir un analizador para algo más simple que XML como formato de entrada, si no necesita todo lo que XML ofrece.

XSLT es un ejemplo de lenguaje de en.wikipedia.org/wiki/Declarative_programming .

Otros ejemplos de lenguajes de programación declarativos incluyen expresiones regulares, Prolog y SQL. Todos estos son altamente expresivos y compactos, y por lo general muy bien diseñados y potentes para la tarea para la que están diseñados.

Sin embargo, los desarrolladores de software en general odian dichos lenguajes, porque son muy diferentes de los OO principales o los lenguajes de procedimiento que son difíciles de aprender y depurar. Su naturaleza compacta generalmente hace que sea muy fácil causar mucho daño inadvertidamente.

Entonces, aunque XSLT es un mecanismo eficiente para combinar datos en la presentación, falla en el departamento de facilidad de uso. Creo que esa es la razón por la que realmente no se ha puesto de moda.

XSLT no es la transformación final de la transformación xml. Sin embargo, es muy difícil juzgar con base en la información proporcionada si hubiera sido la mejor solución a su problema o si hay otros enfoques más eficientes y sostenibles. Usted dice que los autores pueden ingresar su contenido en un formato simplificado, ¿qué formato? ¿Cajas de texto? ¿A qué tipo de html estaba convirtiéndolo? Para juzgar si XSLT es la herramienta adecuada para el trabajo, sería útil conocer las características de esta transformación con más detalle.