.NET 3.5 ne prend pas complètement en charge XPATH 2.0 ou XSLT 2.0, ce qui est tout simplement dommage. Quelqu'un sait-il si ces deux seront inclus et entièrement pris en charge dans les futures versions de .NET?
codeproject.com/Articles/24766/… La bibliothèque Java saxon implémente XSL 2.0 et XQuery 1.0. En utilisant IKVM et GNU Classpath, vous pouvez accéder à cette bibliothèque dans .NET. Cependant, les interfaces d'utilisation de Saxon sont très différentes de celles que vous utilisez dans .NET. À partir de cette page d'article, vous pouvez télécharger des adaptateurs d'interface qui aident à combler le fossé entre l'interface Saxon et le .NET XslCompiledTransform. Cela facilite à son tour le portage du code de .NET XSL 1.0 vers Saxon XSL 2.0.
gls123
3
Vous pouvez publier cette demande de fonctionnalité sur uservoice par Microsoft
Binoj Antony
Réponses:
131
Je ne pense pas qu'ils ajouteront bientôt le support de XPath 2.0 ou XSLT 2.0.
Cependant, vous ne devriez pas vous sentir mal si ceux-ci ne font pas partie de la BCL, tant que vous avez des implémentations tierces disponibles:
Microsoft est orienté client. Si les clients n'en veulent pas, ils n'y arriveront pas.
2009-11-18: J'ai contacté l'équipe XML ici et j'ai obtenu cette réponse:
Bien que XML continue d'être un élément clé de notre plate-forme à l'avenir, nous avons décidé de ne pas poursuivre une implémentation XSLT 2.0 pour le moment. S'il y a une tâche XSLT spécifique que vous essayez d'accomplir et que vous rencontrez des difficultés avec XSLT 1.0, veuillez nous en informer et nous ferons de notre mieux pour vous aider.
Ils ont initialement promis une mise en œuvre - c'est la raison pour laquelle il n'y a que peu d'implémentations, car lorsque une grande entreprise comme Microsoft dit que nous le ferons et que nous le donnerons à tout le monde dans le cadre de Windows, il n'y a aucune raison de le programmer. Mais MS a perdu plusieurs personnes clés dans l'équipe XML et depuis lors, le support 2.0 est mort.
CodeRipper
6
Cette réponse semble étrangement familière - j'ai posé une question similaire il y a quelques années et j'ai obtenu la même réponse. Honte - XSLT 2.0 ressemble à une amélioration assez importante de la convivialité du langage.
@alirobe Les gens qui ne votent pas le sont encore plus. Cela prouve seulement à quel point les gens passionnés qui aiment XSLT sont. Beaucoup de choses enseignées dans les écoles sont rarement utilisées dans le monde réel.
Il y a plusieurs raisons pour lesquelles nous n'implémentons pas XSLT 2.0 et XPath 2.0
Il faut beaucoup d'efforts et de ressources pour implémenter les 3 technologies (XQuery, XSLT 2.0 et XPath 2.0). Notre principe directeur était que nous pensons que créer une prolifération de technologies de requête XML est source de confusion pour les utilisateurs finaux. Nous préférons implémenter un langage de plus que nous poussons les gens à apprendre plutôt que de prendre en charge et d'expliquer trois autres langages de requête et de transformation XML, en plus de XPath 1.0 et XSLT 1.0 qui existent déjà dans le .NET Framework. Le fait que nos clients et nos techniciens d'assistance doivent faire face à la complexité de 3 langages de requête XML sophistiqués dont deux se ressemblent mais se comportent assez différemment dans le cas de XPath 2.0 et XQuery ne nous a pas semblé aussi bénéfique.
Cela remonte à 5 ans sur un blog intitulé "Pourquoi vous ne verrez pas XSLT 2.0 ou XPath 2.0 dans la prochaine version du .NET Framework" (je souligne)
Brian Agnew
1
Merci! Je n'ai pas remarqué ça! Je n'ai pas accepté cette réponse à nouveau, dans l'espoir d'une explication plus récente. (Bien que ce soit une bonne explication, le +1 reste.)
Wim ten Brink
3
Cela dit, il y a deux choses à garder à l'esprit lors de l'utilisation de XSLT dans .NET: 1) il prend en charge exslt: node-set (), qui couvre l'un des grands avantages de XSLT 2.0, et 2) msxsl: script vous permet définissez des fonctions arbitrairement complexes directement dans votre XSLT à l'aide de C # / VB / JScript.NET, sans se faufiler avec les API d'extensibilité. Comme il est XslCompiledTransformutilisé XPathNavigatorpour la représentation des nœuds, et que ce dernier implémente entièrement XDM, vous pouvez en fait implémenter toutes les fonctionnalités XPath2 (comme les opérateurs <<et >>) en tant que fonctions personnalisées en plus de cela.
Je crois comprendre que de nombreuses ressources Microsoft XML ont été détournées de XSLT 2.0 vers LINQ vers XML, ce qui, à mon avis, ne traite pas du tout le même problème que XSLT.
LINQ to XSD était censé améliorer LINQ to XML (ainsi que les avantages du schéma XML, la syntaxe est moins moche), mais cela a été open-source par Microsoft sur CodePlex il y a quelque temps et ne semble pas avoir de support de la communauté.
En outre, il est peu probable que Microsoft lance un nouveau processeur XSLT 2.0 sans un éditeur et un débogueur XSLT 2.0 intégrés à Visual Studio, donc un peu d'effort / de temps serait nécessaire pour annuler leur décision de `` non-adoption ''.
Nous avons donc à la place Saxon.NET, qui jouit d'une réputation de conformité aux normes irréprochable et offre d'excellentes options d'extensibilité pour .NET.
@ Oliver-Hallam: Cette prévision est-elle toujours valable? Êtes-vous sur la bonne voie?
Dimitre Novatchev le
@ Oliver-Hallam: XQSharp-XSLT 2.0 sera-t-il plus rapide que Saxon.NET?
Dimitre Novatchev le
@ Dimitre-Novatchev - C'est drôle que vous demandez maintenant; nous devrions avoir une version bêta de notre implémentation XSLT publiée dans les prochaines heures! En ce qui concerne la vitesse, nous pensons que nos performances sont aussi bonnes que celles de Saxon, même si nous sommes biaisés, nous aimerions donc avoir une opinion indépendante!
Oliver Hallam
1
XQSharp s'appelle désormais XMLPrime
Mike Gale
2
Je ne peux pas croire qu'ils ne le seront pas à un moment donné car ce sont des technologies de base du W3C. Cependant, je ne trouve aucune référence actuelle à ceux-ci (seules les informations publiées il y a longtemps).
Dans un proche avenir, vous devriez jeter un œil à Saxon qui prend en charge les versions Xpath / XSLT dont vous avez besoin.
J'utiliserais AltovaXML à la place: altova.com/altovaxml.html C'est gratuit et prend en charge Java, .NET et WIN32 via COM. C'est juste que j'espérais que .NET le prendrait en charge de manière native.
Wim ten Brink
1
L'API AltovaXML est inutile, en plus de son code natif, tandis que Saxon est géré.
Max Toro
1
Le gros problème d'Altova est qu'ils refusent d'implémenter correctement l'espace blanc uniquement en préservant les nœuds de texte.
Réponses:
Je ne pense pas qu'ils ajouteront bientôt le support de XPath 2.0 ou XSLT 2.0.
Cependant, vous ne devriez pas vous sentir mal si ceux-ci ne font pas partie de la BCL, tant que vous avez des implémentations tierces disponibles:
Microsoft est orienté client. Si les clients n'en veulent pas, ils n'y arriveront pas.
2009-11-18: J'ai contacté l'équipe XML ici et j'ai obtenu cette réponse:
Cette liste est maintenant maintenue sur github.com/maxtoroq/dotnet-xml
la source
Voir ce billet de blog
la source
XslCompiledTransformutiliséXPathNavigatorpour la représentation des nœuds, et que ce dernier implémente entièrement XDM, vous pouvez en fait implémenter toutes les fonctionnalités XPath2 (comme les opérateurs<<et>>) en tant que fonctions personnalisées en plus de cela.Je crois comprendre que de nombreuses ressources Microsoft XML ont été détournées de XSLT 2.0 vers LINQ vers XML, ce qui, à mon avis, ne traite pas du tout le même problème que XSLT.
LINQ to XSD était censé améliorer LINQ to XML (ainsi que les avantages du schéma XML, la syntaxe est moins moche), mais cela a été open-source par Microsoft sur CodePlex il y a quelque temps et ne semble pas avoir de support de la communauté.
En outre, il est peu probable que Microsoft lance un nouveau processeur XSLT 2.0 sans un éditeur et un débogueur XSLT 2.0 intégrés à Visual Studio, donc un peu d'effort / de temps serait nécessaire pour annuler leur décision de `` non-adoption ''.
Nous avons donc à la place Saxon.NET, qui jouit d'une réputation de conformité aux normes irréprochable et offre d'excellentes options d'extensibilité pour .NET.
la source
Microsoft n'a pas l'intention de publier la prise en charge de XPath / XSLT 2.0 dans .NET.
XQSharp fournit une implémentation tierce de XPath 2.0, XSLT 2.0 et XQuery pour .NET.
[modifier: XQSharp 2.0 beta (avec XSLT 2.0) a été publié]
la source
Je ne peux pas croire qu'ils ne le seront pas à un moment donné car ce sont des technologies de base du W3C. Cependant, je ne trouve aucune référence actuelle à ceux-ci (seules les informations publiées il y a longtemps).
Dans un proche avenir, vous devriez jeter un œil à Saxon qui prend en charge les versions Xpath / XSLT dont vous avez besoin.
la source