.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?
codeproject.com/Articles/24766/… La biblioteca saxon de Java implementa XSL 2.0 y XQuery 1.0. Usando IKVM y GNU Classpath, puede obtener acceso a esta biblioteca en .NET. Sin embargo, las interfaces para usar Saxon son muy diferentes a las que usa en .NET. Desde la página de este artículo puede descargar adaptadores de interfaz que ayudan a cerrar la brecha entre la interfaz Saxon y .NET XslCompiledTransform. Esto, a su vez, hace que sea mucho más fácil migrar el código desde .NET XSL 1.0 a Saxon XSL 2.0.
gls123
3
Puede publicar esta solicitud de función en uservoice por Microsoft
Binoj Antony
Respuestas:
131
No creo que vayan a agregar soporte para XPath 2.0 o XSLT 2.0 en el corto plazo.
Sin embargo, no debería sentirse mal si estos no son parte de la BCL, siempre que tenga implementaciones de terceros disponibles:
Microsoft está orientado al cliente. Si los clientes no lo quieren, no lo conseguirán.
2009-11-18: 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 buscar una implementación XSLT 2.0 en este momento. Si hay una tarea XSLT específica que está tratando de realizar y tiene dificultades con XSLT 1.0, háganoslo saber y haremos todo lo posible para ayudarlo.
Inicialmente prometieron implementación; esa es la razón por la que solo hay pocas implementaciones porque cuando una gran empresa como Microsoft dice que lo haremos y se lo daremos a todos como parte de Windows, no hay razón para programarlo. Pero luego MS perdió a varias personas clave en el Equipo XML y desde entonces el soporte 2.0 está muerto.
CodeRipper
6
Esa respuesta parece inquietantemente familiar: hice una pregunta similar hace unos años y obtuve la misma respuesta. Vergüenza: XSLT 2.0 parece una mejora bastante importante para la usabilidad del lenguaje.
@alirobe La gente que no vota por ella es aún más. Solo demuestra lo apasionadas que son las personas a las que les gusta XSLT. Muchas cosas que se enseñan en las escuelas rara vez se usan en el mundo real.
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 crear una proliferación de tecnologías de consulta XML es confuso para los usuarios finales. Preferimos implementar un lenguaje más para que las personas aprendan 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. Tener a nuestros clientes y personal de soporte tiene que lidiar con la complejidad de 3 sofisticados lenguajes de consulta XML, dos de los cuales parecen similares pero se comportan de manera bastante diferente en el caso de XPath 2.0 y XQuery nos pareció que no era tan beneficioso.
Eso es de hace 5 años de un blog titulado "Por qué no verá XSLT 2.0 o XPath 2.0 en la próxima versión de .NET Framework" (énfasis mío)
Brian Agnew
1
¡Gracias! ¡No me di cuenta de eso! Acepté esta respuesta nuevamente, esperando una explicación más nueva. (Aunque es una buena explicación, por lo que el +1 se mantiene.)
Wim ten Brink
3
Dicho esto, hay dos cosas que vale la pena tener en cuenta al tratar con XSLT en .NET: 1) es compatible con exslt: node-set (), que cubre una de las grandes ventajas de XSLT 2.0, y 2) msxsl: script le permite defina funciones arbitrariamente complejas directamente dentro de su XSLT utilizando C # / VB / JScript.NET, sin alteraciones con las API de extensibilidad. Dado que se XslCompiledTransformutiliza XPathNavigatorpara la representación de nodos, y este último implementa completamente XDM, en realidad puede implementar todas las funciones de XPath2 (como operadores <<y >>) como funciones personalizadas además de eso.
Tengo entendido que muchos recursos XML de Microsoft se desviaron de XSLT 2.0 a LINQ to XML, que, en mi opinión, no aborda el mismo espacio de problemas que XSLT en absoluto.
Se suponía que LINQ to XSD mejoraría LINQ to XML (además de los beneficios del esquema XML, la sintaxis es menos fea), pero Microsoft lo incorporó a CodePlex hace algún tiempo y parece que no tiene 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 necesitaría bastante esfuerzo / tiempo para revertir su decisión de "no adopción".
En su lugar, tenemos Saxon.NET, que tiene una reputación de cumplimiento de estándares intachable y proporciona excelentes opciones de extensibilidad para .NET.
@ Oliver-Hallam: ¿Sigue siendo válido este pronóstico? ¿Estás encaminado?
Dimitre Novatchev
@ Oliver-Hallam: ¿XQSharp-XSLT 2.0 será más rápido que Saxon.NET?
Dimitre Novatchev
@ Dimitre-Novatchev - Es curioso que preguntes ahora; ¡Deberíamos tener una versión beta de nuestra implementación XSLT lanzada en las próximas horas! En cuanto a la velocidad, creemos que nuestro desempeño es tan bueno como el de Saxon, aunque somos parciales, ¡así que nos encantaría tener una opinión independiente!
Oliver Hallam
1
XQSharp ahora se llama XMLPrime
Mike Gale
2
No puedo creer que no lo estarán en algún momento, ya que son tecnologías centrales del W3C. Sin embargo, no puedo encontrar ninguna referencia actual a estos (solo información publicada hace mucho tiempo).
En un futuro próximo, debería echar un vistazo a Saxon, que es compatible con las versiones Xpath / XSLT que necesita.
En su lugar, usaría AltovaXML: altova.com/altovaxml.html Es gratis y admite Java, .NET y WIN32 a través de COM. Es solo que esperaba que .NET lo admitiera de forma nativa.
Wim ten Brink
1
La API de AltovaXML es inútil, además de su código nativo, mientras que Saxon está administrado.
Max Toro
1
El gran problema de Altova es que se niegan a implementar correctamente los espacios en blanco que solo conservan los nodos de texto.
Respuestas:
No creo que vayan a agregar soporte para XPath 2.0 o XSLT 2.0 en el corto plazo.
Sin embargo, no debería sentirse mal si estos no son parte de la BCL, siempre que tenga implementaciones de terceros disponibles:
Microsoft está orientado al cliente. Si los clientes no lo quieren, no lo conseguirán.
2009-11-18: Me comuniqué con el equipo XML aquí y obtuve esta respuesta:
Esta lista ahora se mantiene en github.com/maxtoroq/dotnet-xml
fuente
Ver esta publicación de blog
fuente
XslCompiledTransformutilizaXPathNavigatorpara la representación de nodos, y este último implementa completamente XDM, en realidad puede implementar todas las funciones de XPath2 (como operadores<<y>>) como funciones personalizadas además de eso.Tengo entendido que muchos recursos XML de Microsoft se desviaron de XSLT 2.0 a LINQ to XML, que, en mi opinión, no aborda el mismo espacio de problemas que XSLT en absoluto.
Se suponía que LINQ to XSD mejoraría LINQ to XML (además de los beneficios del esquema XML, la sintaxis es menos fea), pero Microsoft lo incorporó a CodePlex hace algún tiempo y parece que no tiene 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 necesitaría bastante esfuerzo / tiempo para revertir su decisión de "no adopción".
En su lugar, tenemos Saxon.NET, que tiene una reputación de cumplimiento de estándares intachable y proporciona excelentes opciones de extensibilidad para .NET.
fuente
Microsoft no tiene planes de lanzar soporte para XPath / XSLT 2.0 en .NET.
XQSharp proporciona una implementación de terceros de XPath 2.0, XSLT 2.0 y XQuery para .NET.
[editar: se ha lanzado XQSharp 2.0 beta (con XSLT 2.0)]
fuente
No puedo creer que no lo estarán en algún momento, ya que son tecnologías centrales del W3C. Sin embargo, no puedo encontrar ninguna referencia actual a estos (solo información publicada hace mucho tiempo).
En un futuro próximo, debería echar un vistazo a Saxon, que es compatible con las versiones Xpath / XSLT que necesita.
fuente