¿XPath y XSLT 2.0 para .NET? [cerrado]
.NET 3.5 no es completamente compatible con XPATH 2.0 o XSLT 2.0, lo cual es una lástima. ¿Alguien sabe si estos dos se incluirán y serán totalmente compatibles en futuras versiones de .NET?
No creo que agreguen soporte para XPath 2.0 o XSLT 2.0 en el corto plazo.
Sin embargo, no debería sentirse mal si no forman parte de la BCL, siempre y cuando tenga implementaciones de terceros disponibles:
- Sajón : XPath 3.1, XQuery 3.1, XSLT 3.0
- XmlPrime : XPath 3.1, XQuery 3.1, XSLT 2.0
- Máquina de consulta : XPath 2.0, XQuery 1.0
- XPath2 ligero para .NET : XPath 2.0
- Excelente : XSLT 3.0
Microsoft está orientado al cliente. Si los clientes no lo quieren, no lo lograrán.
18/11/2009: Me comuniqué con el equipo XML aquí y obtuve esta respuesta:
Si bien XML sigue siendo una parte clave de nuestra plataforma en el futuro, hemos decidido no implementar XSLT 2.0 en este momento. Si hay una tarea XSLT específica que está intentando realizar y tiene dificultades con XSLT 1.0, háganoslo saber y haremos todo lo posible para ayudarle.
Esta lista ahora se mantiene en github.com/maxtoroq/dotnet-xml
Ver esta publicación de blog
Hay varias razones por las que no estamos implementando XSLT 2.0 y XPath 2.0.
Se necesita mucho esfuerzo y recursos para implementar las 3 tecnologías (XQuery, XSLT 2.0 y XPath 2.0). Nuestro principio rector fue que creemos que la proliferación de tecnologías de consulta XML resulta confusa para los usuarios finales. Preferimos implementar un lenguaje más que instamos a las personas a aprender que tener que admitir y explicar tres lenguajes de transformación y consulta XML más, además de XPath 1.0 y XSLT 1.0 que ya existen en .NET Framework. Hacer que nuestros clientes y personal de soporte tengan que lidiar con la complejidad de 3 sofisticados lenguajes de consulta XML, dos de los cuales tienen un aspecto similar pero se comportan de manera bastante diferente en el caso de XPath 2.0 y XQuery, no nos pareció tan beneficioso.
Tengo entendido que muchos recursos XML de Microsoft se desviaron de XSLT 2.0 a LINQ to XML, lo que, en mi opinión, no aborda en absoluto el mismo espacio de problemas que XSLT.
Se suponía que LINQ to XSD mejoraría LINQ to XML (así como los beneficios del esquema XML, la sintaxis es menos fea), pero Microsoft lo abrió en CodePlex hace algún tiempo y parece no tener soporte de la comunidad.
Además, es poco probable que Microsoft lance un nuevo procesador XSLT 2.0 sin un editor y depurador XSLT 2.0 integrado en Visual Studio, por lo que se requeriría bastante esfuerzo/tiempo para revertir su decisión de "no adopción". [Actualización] Ahora hay una extensión XSLT 3.0 para Microsoft VSCode (administrada por mí) que se integra con el procesador XSLT 3.0 de Saxon.
Así que en su lugar tenemos Saxon.NET, que tiene una reputación intachable de cumplimiento de estándares y proporciona excelentes opciones de extensibilidad para .NET.
