.NET 3.5 nie obsługuje w pełni XPATH 2.0 ani XSLT 2.0, co jest po prostu bardzo złe. Czy ktoś wie, czy te dwie zostaną uwzględnione iw pełni obsługiwane w przyszłych wersjach .NET?
codeproject.com/Articles/24766/… Biblioteka Java Saxon implementuje XSL 2.0 i XQuery 1.0. Korzystając z IKVM i GNU Classpath, możesz uzyskać dostęp do tej biblioteki w .NET. Jednak interfejsy do używania języka Saxon są bardzo różne od tych, których używasz w .NET. Z tej strony artykułu można pobrać adaptery interfejsu, które pomagają wypełnić lukę między interfejsem saksońskim a .NET XslCompiledTransform. To z kolei znacznie ułatwia przenoszenie kodu z używania .NET XSL 1.0 do Saxon XSL 2.0.
gls123
3
Możesz opublikować tę prośbę o funkcję na stronie uservoice firmy Microsoft
Binoj Antony
Odpowiedzi:
130
Nie sądzę, aby w najbliższym czasie dodali obsługę XPath 2.0 lub XSLT 2.0.
Jednak nie powinieneś czuć się źle, jeśli nie są one częścią BCL, o ile masz dostępne implementacje innych firm:
Microsoft jest zorientowany na klienta. Jeśli klienci tego nie chcą, nie dadzą rady.
2009-11-18: Skontaktowałem się tutaj z zespołem XML i otrzymałem następującą odpowiedź:
Chociaż XML nadal jest kluczową częścią naszej platformy w przyszłości, zdecydowaliśmy się obecnie nie wdrażać XSLT 2.0. Jeśli próbujesz wykonać określone zadanie XSLT i masz problemy z XSLT 1.0, daj nam znać, a postaramy się pomóc.
Początkowo obiecywali implementację - dlatego wdrożeń jest niewiele, bo kiedy duża firma, taka jak Microsoft, mówi, że to zrobimy i damy to każdemu jako część Windowsa, nie ma powodu, aby to programować. Ale potem MS stracił kilka kluczowych osób w zespole XML i od tego czasu wsparcie 2.0 jest martwe.
CodeRipper
6
Ta odpowiedź wygląda niesamowicie znajomo - kilka lat temu zadałem podobne pytanie i otrzymałem taką samą odpowiedź. Wstyd - XSLT 2.0 wygląda na dość ważne ulepszenie użyteczności języka.
Eamon Nerbonne
1
Prawdziwym problemem jest to, że żadna z tych opcji innych firm nie została zaktualizowana do działania na platformie .NET Standard / Core - a kilka z nich jest opartych na JKVM, co oznacza, że nie można ich aktualizować. Biorąc pod uwagę, z
iloma
1
Gdyby byli naprawdę zorientowani na klienta, zrobiliby to. Jest to jeden z najczęściej zgłaszanych problemów w ich UserVoice. Wszyscy o to błagają. XSLT nie jest niszą, uczy się go na większości zajęć z systemów informatycznych. To podstawowy format wymiany danych.
Istnieje kilka powodów, dla których nie wdrażamy XSLT 2.0 i XPath 2.0
Wdrożenie wszystkich 3 technologii (XQuery, XSLT 2.0 i XPath 2.0) wymaga wiele wysiłku i zasobów. Naszą naczelną zasadą było to, że naszym zdaniem tworzenie mnogości technologii zapytań XML jest mylące dla użytkowników końcowych. Wolelibyśmy wdrożyć jeszcze jeden język, który zachęcamy do nauki, niż obsługiwać i wyjaśniać trzy inne języki zapytań i transformacji XML, oprócz XPath 1.0 i XSLT 1.0, które już istnieją w .NET Framework. Nasi klienci i pracownicy pomocy technicznej muszą radzić sobie ze złożonością 3 wyrafinowanych języków zapytań XML, z których dwa wyglądają podobnie, ale zachowują się zupełnie inaczej w przypadku XPath 2.0 i XQuery wydawało nam się nie być tak korzystne.
To sprzed 5 lat z bloga zatytułowanego „Dlaczego nie zobaczysz XSLT 2.0 lub XPath 2.0 w następnej wersji .NET Framework” (moje wyróżnienie)
Brian Agnew
1
Dzięki! Nie zauważyłem tego! Ponownie nie zaakceptowałem tej odpowiedzi, mając nadzieję na nowsze wyjaśnienie. (Chociaż jest to dobre wyjaśnienie, więc +1 pozostaje.)
Wim ten Brink
3
To powiedziawszy, są dwie rzeczy, o których warto pamiętać, gdy mamy do czynienia z XSLT w .NET: 1) obsługuje on exslt: node-set (), który obejmuje jedną z największych zalet XSLT 2.0, oraz 2) msxsl: script umożliwia definiuj dowolnie złożone funkcje bezpośrednio w swoim XSLT przy użyciu C # / VB / JScript.NET, bez modyfikowania za pomocą rozszerzalnych interfejsów API. Ponieważ XslCompiledTransformużywa XPathNavigatordo reprezentacji węzłów, a ta ostatnia w pełni implementuje XDM, możesz w rzeczywistości zaimplementować wszystkie funkcje XPath2 (takie jak operatory <<i >>) jako funkcje niestandardowe.
Rozumiem, że wiele zasobów Microsoft XML zostało przekierowanych z XSLT 2.0 do LINQ to XML, co - moim zdaniem - w ogóle nie rozwiązuje tej samej przestrzeni problemowej, co XSLT.
LINQ to XSD miał ulepszyć LINQ to XML (a także korzyści ze schematu XML, składnia jest mniej brzydka), ale został on udostępniony przez firmę Microsoft jako open source do CodePlex jakiś czas temu i wydaje się, że nie ma wsparcia społeczności.
Ponadto jest mało prawdopodobne, aby Microsoft wypuścił nowy procesor XSLT 2.0 bez edytora XSLT 2.0 i debuggera zintegrowanego z Visual Studio, więc potrzeba sporo wysiłku / czasu, aby cofnąć decyzję o braku adopcji. [Aktualizacja] Dostępne jest teraz rozszerzenie XSLT 3.0 dla Microsoft VSCode (zarządzane przeze mnie), które integruje się z procesorem XSLT Saxon 3.0.
Zamiast tego mamy Saxon.NET, który cieszy się niezrównaną reputacją w zakresie zgodności ze standardami i zapewnia doskonałe opcje rozszerzalności dla .NET.
@ Oliver-Hallam: Czy ta prognoza jest nadal aktualna? Czy jesteś na dobrej drodze?
Dimitre Novatchev
@ Oliver-Hallam: Czy XQSharp-XSLT 2.0 będzie szybszy niż Saxon.NET?
Dimitre Novatchev
@ Dimitre-Novatchev - Zabawne, o co pytasz teraz; powinniśmy mieć wersję beta naszej implementacji XSLT wydaną w ciągu najbliższych kilku godzin! Jeśli chodzi o szybkość, uważamy, że nasze wyniki są równie dobre jak saksońskie, chociaż jesteśmy stronniczy, więc chcielibyśmy uzyskać niezależną opinię!
Oliver Hallam,
1
XQSharp nazywa się teraz XMLPrime
Mike Gale
2
Nie mogę uwierzyć, że nie będą na jakimś etapie, ponieważ są to podstawowe technologie W3C. Jednak nie mogę znaleźć żadnego aktualnego odniesienia do nich (tylko informacje opublikowane dawno temu).
W najbliższej przyszłości powinieneś spojrzeć na Saxon, który obsługuje wersje Xpath / XSLT, których potrzebujesz.
Zamiast tego użyłbym AltovaXML: altova.com/altovaxml.html Jest darmowy i obsługuje Java, .NET i WIN32 przez COM. Po prostu miałem nadzieję, że .NET będzie obsługiwał to natywnie.
Wim ten Brink
1
AltovaXML API jest bezużyteczne, plus jego natywny kod, podczas gdy Saxon jest zarządzany.
Max Toro
1
Dużym problemem Altovy jest to, że odmawiają prawidłowego implementacji białych znaków, zachowując tylko węzły tekstowe.
Odpowiedzi:
Nie sądzę, aby w najbliższym czasie dodali obsługę XPath 2.0 lub XSLT 2.0.
Jednak nie powinieneś czuć się źle, jeśli nie są one częścią BCL, o ile masz dostępne implementacje innych firm:
Microsoft jest zorientowany na klienta. Jeśli klienci tego nie chcą, nie dadzą rady.
2009-11-18: Skontaktowałem się tutaj z zespołem XML i otrzymałem następującą odpowiedź:
Ta lista jest teraz utrzymywana na github.com/maxtoroq/dotnet-xml
źródło
Zobacz ten wpis na blogu
źródło
XslCompiledTransformużywaXPathNavigatordo reprezentacji węzłów, a ta ostatnia w pełni implementuje XDM, możesz w rzeczywistości zaimplementować wszystkie funkcje XPath2 (takie jak operatory<<i>>) jako funkcje niestandardowe.Rozumiem, że wiele zasobów Microsoft XML zostało przekierowanych z XSLT 2.0 do LINQ to XML, co - moim zdaniem - w ogóle nie rozwiązuje tej samej przestrzeni problemowej, co XSLT.
LINQ to XSD miał ulepszyć LINQ to XML (a także korzyści ze schematu XML, składnia jest mniej brzydka), ale został on udostępniony przez firmę Microsoft jako open source do CodePlex jakiś czas temu i wydaje się, że nie ma wsparcia społeczności.
Ponadto jest mało prawdopodobne, aby Microsoft wypuścił nowy procesor XSLT 2.0 bez edytora XSLT 2.0 i debuggera zintegrowanego z Visual Studio, więc potrzeba sporo wysiłku / czasu, aby cofnąć decyzję o braku adopcji. [Aktualizacja] Dostępne jest teraz rozszerzenie XSLT 3.0 dla Microsoft VSCode (zarządzane przeze mnie), które integruje się z procesorem XSLT Saxon 3.0.
Zamiast tego mamy Saxon.NET, który cieszy się niezrównaną reputacją w zakresie zgodności ze standardami i zapewnia doskonałe opcje rozszerzalności dla .NET.
źródło
Firma Microsoft nie planuje udostępnienia obsługi XPath / XSLT 2.0 w .NET.
XQSharp zapewnia implementację XPath 2.0, XSLT 2.0 i XQuery dla platformy .NET.
[edycja: XQSharp 2.0 beta (z XSLT 2.0) została wydana]
źródło
Nie mogę uwierzyć, że nie będą na jakimś etapie, ponieważ są to podstawowe technologie W3C. Jednak nie mogę znaleźć żadnego aktualnego odniesienia do nich (tylko informacje opublikowane dawno temu).
W najbliższej przyszłości powinieneś spojrzeć na Saxon, który obsługuje wersje Xpath / XSLT, których potrzebujesz.
źródło