.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?
.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?
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ź:
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.
Ta lista jest teraz utrzymywana na github.com/maxtoroq/dotnet-xml
Zobacz ten wpis na blogu
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.
XslCompiledTransform
używa XPathNavigator
do 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.
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]
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.