XPath et XSLT 2.0 .NET?

.NET 3.5 n'est pas complètement support de XPATH 2.0 ou XSLT 2.0, qui est tout simplement trop mauvais. Personne ne sait si ces deux-là vont être inclus et entièrement pris en charge dans le futur .NET versions?

  • codeproject.com/Articles/24766/... Le Java saxon bibliothèque implémente XSL 2.0 et XQuery 1.0. À l'aide de IKVM et GNU Classpath, vous pouvez obtenir l'accès à cette bibliothèque .NET. Cependant, les interfaces pour l'utilisation Saxons sont très différents de ceux que vous utilisez dans .NET. À partir de cet article de la page vous pouvez télécharger des cartes d'interface qui contribuent à combler le fossé entre la saxe et l'interface .NET XslCompiledTransform. Ce à tour de rôle le rend beaucoup plus facile de port code de l'aide .NET XSL 1.0 à Saxon XSL 2.0.
  • Vous pouvez poster cette demande de fonctionnalité dans le uservoice par Microsoft
InformationsquelleAutor Wim ten Brink | 2009-10-06
  1. 129

    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:

    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.

    Cette liste est maintenant maintenu à github.com/maxtoroq/dotnet-xml

    • Ils ont d'abord promis de mise en œuvre - c'est la raison pour laquelle il y a seulement quelques implémentations parce que lors de la grande entreprise comme Microsoft dit que nous allons faire et nous allons le donner à tout le monde dans le cadre de Windows il n'y a pas de raison de le programmer. Mais alors, MME la perte de plusieurs personnes clés dans le fichier XML de l'Équipe et depuis 2.0 est mort.
    • Cette réponse semble étrangement familier - j'ai posé une question similaire, à quelques années en arrière et obtenu la même réponse. La honte - XSLT 2.0 ressemble à une assez grande amélioration à la langue de la convivialité.
    • Léger XPath2 pour .NET est maintenant au github.com/StefH/XPath2.Net
    • Le vrai problème, c'est qu'aucun de ceux de la 3e partie des options ont été mis à jour pour fonctionner sur .NET Standard/Core-et plusieurs sont basées sur JKVM ce qui signifie qu'ils vous ne pouvez pas être mis à jour. Considérant combien 3ème partie commerciale des produits que vous avez lié à là, je ne suis pas sûr que le "orienté client" ligne explique quoi que ce soit..
    • C'est seulement un problème si vous l'embrassez .NET de Base. XSLT est très niche, et Microsoft aime à plaire à un large/large du marché avec des outils d'usage universel.
    • Si ils étaient vraiment à l'écoute du client, ils allaient le faire. C'est l'un des plus upvoted questions dans leur UserVoice. Tout le monde est à la mendicité pour elle. XSLT n'est pas de niche, elle est enseignée dans la plupart des Systèmes d'Information des classes. Il est fondamental de format d'échange de données.
    • Les gens pas vote pour elle sont encore plus. Il prouve seulement combien de gens passionnés qui aiment XSLT sont. Beaucoup de choses enseignées dans les écoles sont rarement utilisées dans le monde réel.
    • Pour info: .Net de Base Fonction de Demande: github.com/dotnet/corefx/issues/2295 pour XPath/XSLT v2 & 3 soutien.

    InformationsquelleAutor Max Toro
  2. 23

    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.

    • C'est à partir de 5 ans à partir d'un blog intitulé "Pourquoi Vous ne verrez pas de XSLT 2.0 ou XPath 2.0 dans le Suivant Version de la .NET Framework" (mon emphase)
    • Merci! N'ayez pas remarqué que! Unaccepted cette réponse, là encore, en espérant pour une nouvelle explication. (Même si c'est une bonne explication de sorte que le +1 séjours.)
    • Rien n'a vraiment changé depuis; c'est le dernier de la communication sur le sujet, malheureusement.
    • Cela dit, il y a deux choses à garder à l'esprit lorsque vous traitez avec XSLT dans .NET: 1) il prend en charge exslt:node-set(), qui couvre l'un des gros avantages de XSLT 2.0 et 2) msxsl:script permet de définir arbitrairement complexes des fonctions directement dans votre XSLT à l'aide de C#/VB/JScript.NET, sans coucher avec les Api d'extensibilité. Depuis XslCompiledTransform utilise XPathNavigator pour le nœud de la représentation, et ce dernier met pleinement en œuvre XDM, vous pouvez effectivement mettre en œuvre tous les XPath2 fonctionnalités (comme les opérateurs de << et >>) que des fonctions personnalisées sur le dessus de cela.
    • Ce n'est pas la dernière communication sur le sujet. E. g.: blogs.msdn.com/xmlteam/archive/2007/01/29/xslt-2-0.aspx
    • 2013, pas de changements:
    • le lien est mort, web.archive.org/web/20100118203004/http://blogs.msdn.com/... (version mise en cache à partir de 2009)
    • 2016 - XML est toujours vivant, mais Microsoft ne prend pas entièrement en charge XPath et XSLT 2.0
    • 2017: C'est la troisième société au cours de ma carrière en tant que développeur logiciel, où j'aurais apprécié XSLT2.0 de soutien par .NET. Je suppose que, ils ne seront jamais de le soutenir. <soupir>
    • 2019/20, n'importe qui? 🙂

    InformationsquelleAutor David Basarab
  3. 12

    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 à tous.

    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.

    InformationsquelleAutor pgfearo
  4. 3

    Microsoft n'avons pas de plans pour libérer support de XPath/XSLT 2.0 .NET.

    XQSharp fournit une 3ème partie de la mise en œuvre de XPath 2.0, XSLT 2.0 et XQuery pour .NET.

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

    • Est cette prévision est-elle encore valable? Vous êtes sur la bonne voie?
    • Va XQSharp-XSLT 2.0, être plus rapide que Saxon.NET?
    • C'est drôle que vous demandez maintenant; nous devrions avoir une version bêta de notre XSLT mise en œuvre libéré dans les prochaines heures! Comme pour la vitesse, nous croyons que notre performance à être aussi bon que Saxon, bien que nous sont biaisées, donc nous aimerions un avis indépendant!
    • XQSharp est maintenant appelé XMLPrime
    InformationsquelleAutor Oliver Hallam
  5. 2

    Je ne peux pas croire qu'ils ne seront pas à un certain stade, car ils sont de base technologies W3C. Cependant je ne trouve pas de actuel référence à ces (seule info posté il y a longtemps).

    Pour le proche avenir, vous devriez jeter un oeil à Saxon qui prend en charge le Xpath/XSLT versions dont vous avez besoin.

    • Je voudrais utiliser AltovaXML à la place: altova.com/altovaxml.html C'est gratuit et prend en charge Java, .NET et WIN32 via COM. C'est juste que je ne l'espérais .NET serait en charge en mode natif.
    • AltovaXML API est inutile, et en plus c'est du code natif, tandis que Saxon est géré.
    • Altova est également plus lent.
    • Altova gros problème, c'est qu'ils refusent de mettre en œuvre correctement espace blanc uniquement les nœuds de texte préserver.
    InformationsquelleAutor Brian Agnew