XPath et XSLT 2.0 pour .NET?

Question

.NET 3.5 ne prend pas complètement en charge XPATH 2.0 ou XSLT 2.0, ce qui est bien dommage. Est-ce que quelqu'un sait si ces deux versions seront incluses et entièrement prises en charge dans les futures versions .NET?

Answer 1

Je ne pense pas qu'ils vont ajouter le support de XPath 2.0 ou XSLT 2.0 tout moment bientôt.

Cependant, vous ne devriez pas vous sentir mal si elles ne font pas partie de la BCL, aussi longtemps que vous avez 3ème partie implémentations disponibles:

• Saxon: XPath 2.0, XQuery 1.0, XSLT 2.0
• XmlPrime: XPath 2.0, XQuery 1.0, XSLT 2.0
• QueryMachine: XPath 2.0, XQuery 1.0
• Léger XPath2 pour .NET: XPath 2.0
• Exselt: XSLT 3.0 (à Venir)

Microsoft est orientée vers le client. Si les clients n'en veulent pas, ils ne se rendront pas.

---

2009-11-18: j'ai contacté le XML de l'équipe ici et a obtenu cette réponse:

Alors que XML continue à être un élément clé de notre plate-forme à l'avenir, nous avons décidé de ne pas poursuivre un XSLT 2.0 la mise en œuvre à cette époque. Si il y est un XSLT spécifique de la tâche que vous essayez d'accomplir et d'avoir la difficulté avec XSLT 1.0, s'il vous plaît laissez - nous savoir et nous ferons de notre mieux pour vous aider.

---

2011-03-23: La .NET version 4.0 a introduit un certain nombre de bugs sur XslCompiledTransform, je vais appeler ces bugs et ne manque pas de fonctionnalités parce que ces problèmes n'existaient pas dans les versions précédentes (.NET 2.0 et 3.5). Merci de voter, afin qu'ils les corriger:

• XslCompiledTransform ne prend pas en charge les avants-compatible traitement Fixe .NET 4.5
• XSLT secours d'instruction est ignorée Fixe .NET 4.5

Answer 2

Voir ce post de blog

Il y a plusieurs raisons pour lesquelles nous ne sont pas la mise en œuvre de XSLT 2.0 et XPath 2.0

Il faut beaucoup d'efforts et de ressources pour mettre en œuvre tous les 3 technologies (XQuery, XSLT 2.0 et XPath 2.0). Notre le principe directeur est que nous croyons la création d'une prolifération de requête XML technologies est source de confusion pour la fin les utilisateurs. Nous préférons mettre en œuvre un plus la langue que l'on pousse les gens à apprendre que d'avoir à appuyer et expliquer les trois plus de requête XML et de transformation les langues, en plus de XPath 1.0 & XSLT 1.0, qui existent déjà dans le .NET Framework. Nos clients et soutenir les personnes qui ont à traiter avec la complexité de 3 sophistiqué XML langages de requêtes, dont deux sont look similaire, mais se comportent tout à fait différemment dans le cas de XPath 2.0 et XQuery nous semblait ne pas l'être bénéfique.

Answer 3

Ma compréhension est que de nombreux Microsoft XML ressources ont été détournés de XSLT 2.0 sur LINQ to XML, ce qui - à mon avis - ne traite pas le même problème d'espace que XSLT.

LINQ to XSD était censé améliorer LINQ to XML et XML Schéma avantages, la syntaxe est moins moche), mais c'était open-source par Microsoft sur CodePlex il y a quelques temps et ne semble pas avoir l'appui de la communauté.

Aussi, son peu probable que Microsoft devrait lancer un nouveau processeur XSLT 2.0, sans une transformation XSLT 2.0 éditeur et débogueur intégré dans Visual Studio, donc, tout à fait un peu d'effort/temps serait nécessaire pour inverser leur " non-adoption de la décision.

Donc, au lieu de cela, nous avons Saxon.NET qui a une organisation irréprochable des normes de respect de la réputation et offre une excellente extensibilité des options .NET.

Answer 4

Microsoft ne prévoit pas de prendre en charge XPath / XSLT 2.0 dans .NET.

XQSharp fournit une implémentation tierce de XPath 2.0, XSLT 2.0 et XQuery for .NET.

[edit: XQSharp 2.0 beta (avec XSLT 2.0) a été publié]

Answer 5

Je ne peux pas croire qu'ils n'en seront pas à un stade donné, car ce sont les technologies de base du W3C. Cependant, je ne trouve aucune référence actuelle à ces informations (seulement des informations postées il y a longtemps).

Dans un proche avenir, jetez un coup d'œil à Saxon, qui prend en charge les versions Xpath / XSLT dont vous avez besoin.