Ventajas de XSLT o Linq en XML

Question

¿Qué ventajas hay para usar XSLT o Linq en XML para analizar HTML en C#? Esto es bajo la suposición de que el html ha sido limpiado, por lo que es válido xhtml. Estos valores entrarán eventualmente en un objeto C# para ser validados y procesados.

Háganme saber si son válidas y si hay otras cosas que considerar.

Ventajas XSLT:

• fácil de cambiar rápidamente y distribuir
• bastante conocido

Desventajas XSLT:

• no compilados, por lo que es más lento para procesar
• La manipulación de cadenas se puede engordar Me
• Será más difícil de conseguir en el # objeto C al final

LINQ to Ventajas XML:

• compilado, para que se ejecute más rápido
• permite la manipulación mejor cadena

Desventajas de Linq a XML:

• debe ser compilado para la actualización

Editar: Debo aclarar, quiero éstos se ejecuten a largo plazo de un Sitio Web puede actualizar su diseño de una vez al mismo tiempo. Esa fue una de las razones más importantes por las que pensé que usaría algo que no requiriera compilación.

Answer 1

Sin más conocimiento de su caso de uso, es difícil darle recomendaciones generales.

De todos modos, de alguna manera estás comparando manzanas y naranjas. LINQ to XML (y LINQ en general) es un lenguaje de consulta, mientras que XSLT es un lenguaje de programación para transformar estructuras de árbol XML. Estos son conceptos diferentes. Utilizaría un lenguaje de consulta siempre que desee extraer una determinada información específica de una fuente de datos para hacer lo que tenga que hacer con ella (ya sea para establecer campos en un objeto C#). Una transformación, en cambio, sería útil para convertir una representación XML de sus datos en otra representación XML.

Así que si su objetivo es crear objetos de C# de XML, es probable que no quieren usar XSLT, pero ninguna de las otras tecnologías ofrecidas por .NET Framework para procesar datos XML: el viejo XmlDocument, XmlReader, XPathDocument, XmlSerializer o XDocument.Cada uno tiene sus ventajas y desventajas especiales, dependiendo del tamaño de entrada, la complejidad de la entrada, la salida deseada, etc.

Dado que solo se trata de HTML, es posible que desee consultar el HTML Agility Pack en CodePlex.

Answer 2

Dado que vas a ir a C#, en algún momento tus datos van a ir a través de Linq (o algún otro código XML para .NET) de todos modos, también puedes pegarlo todo ahí.

A menos que tenga algún motivo convincente para ir con XSLT, como que ya tiene mucha experiencia o la implementación favorece mucho el despliegue de los archivos de texto, manténgalo todo en un solo lugar.

Answer 3

No debe usar si solo está tratando de analizar HTML. HTML! = XML y no se pueden tratar de la misma manera. Por ejemplo, la secuencia de escape '& nbsp;' es perfectamente válido en HTML, pero no es una entidad válida dentro de un documento XML válido (sin graves problemas con las DTD, etc.). Esto te morderá, créeme!

También recomendaría usar HTML Agility pack - biblioteca brillante.

Answer 4

HTML Agility pack?

Déjame intentarlo.

Answer 5

En mi experiencia, XSLT es más conciso y legible cuando se trata principalmente de reorganizar y seleccionar elementos xml existentes. XPath es corto y fácil de entender, y la sintaxis xml evita ensuciar el código con las declaraciones XElement y XAttribute. XSLT funciona bien como un árbol xml transformar el idioma.

Sin embargo, su manejo de cadena es deficiente, el bucle no es intuitivo y no existe un concepto significativo de subrutinas: no puede transformar la salida de otra transformación.

Por lo tanto, si realmente quiere juguetear con el elemento y el contenido de atributos, rápidamente se queda corto. No hay problema en el uso de ambos, incidentalmente, XSLT para normalizar la estructura (por ejemplo, para garantizar que todos los elementos table tengan elementos tbody) y linq-to-xml para interpretarlo. Las posibilidades de concordancia condicional priorizadas significan que XSLT es más fácil de usar cuando se trata de muchas coincidencias similares pero distintas. Xslt es bueno en la simplificación de documentos, pero le faltan demasiadas funciones básicas para ser suficiente por sí mismo.

Habiendo brincado de todo corazón en el carro de Linq-to-Xml, diría que tiene menos superposición con XSLT que podría parecer a primera vista. (Y me encantaría ver una implementación de XSLT 2.0/XQuery 1.0 para .NET).

En términos de rendimiento, ambos técnicos son rápidos. De hecho, dado que es tan difícil expresar operaciones lentas, es poco probable que active accidentalmente un caso lento en XSLT (a menos que empiece a jugar con recursividad ...). Por el contrario, la potencia de LINQ a Xml también puede hacer que sea lenta: simplemente use cualquier objeto .NET pesado en algún bucle interno y obtendrá un incipiente problema de rendimiento.

Hagas lo que hagas, no intentes abusar de XSLT utilizándolo para realizar otra cosa que la lógica más simple: es mucho más prolijo y menos legible que el equivalente C#. Si necesita un montón de lógica (incluso cosas simples como date > DateTime.Now ? "will be" : "has" se convierten en enormes hacks inflados en XSLT) y no desea usar tanto XSLT como Linq a Xml, use Linq.