Trudno jest oceniać technologie, jeśli nie masz do nich głębokiego doświadczenia, ale oczywiście to właśnie wtedy musisz podejmować decyzje, więc nie ma prostej odpowiedzi na ten dylemat.
Przytaczasz dwie obawy: wydajność i użyteczność. Spróbuję rozwiązać oba poniżej.
Po pierwsze, wydajność. Wydajność kursu zależy nie tylko od języka, ale także od implementacji, a także od wiedzy użytkowników. Różne procesory XSLT mogą się znacznie różnić pod względem wydajności, a ten sam procesor może się bardzo różnić w zależności od tego, w jaki sposób jest używany (na przykład w Saksonii ludzie, którzy mają problemy z wydajnością, bardzo często używają go z DOM, co jest złym połączeniem , a wydajność może wzrosnąć dziesięciokrotnie, jeśli zamiast tego użyjesz natywnego modelu drzewa w Saksonii). Pierwszą radą jest, aby nie brać udziału w pogłosie, mierzyć; a druga rada to upewnienie się, że osoba dokonująca pomiaru ma wystarczające doświadczenie, aby nie popełniać głupich błędów. Łatwiej powiedzieć niż zrobić.
Z grubsza można podzielić zadania transformacji na dwie kategorie: proste i złożone. W przypadku prostych transformacji przy dobrym procesorze XSLT cały czas jest analizowany i serializowany, a czas przetwarzania XSLT prawie nie pojawia się na zdjęciu. Ponieważ każda inna technologia będzie wiązać się z takimi samymi kosztami analizy i serializacji, wybór technologii transformacji nie zrobi dużej różnicy (z wyjątkiem być może bardzo bardzo niskiego poziomu kodowania za pomocą przesyłania strumieniowego, ale niewiele osób może sobie pozwolić na programowanie czas i umiejętności potrzebne do wdrożenia tego). W przypadku złożonych transformacji dużych dokumentów zaczynają się pojawiać te same problemy, co w przypadku programowania SQL: osiągnięcie dobrej wydajności wymaga dobrej interakcji między umiejętnościami i wiedzą programisty a możliwościami optymalizatora. Podobnie jak w przypadku SQL, to „ w tak wysokim języku bardzo łatwo jest napisać kilka prostych instrukcji, które powodują, że procesor musi wykonać bardzo dużo pracy. Ale tak jak w przypadku SQL, programiści, którzy wiedzą, co robią, zrobią znacznie lepiej niż nowicjusze.
Po drugie, użyteczność. Oparta na XML składnia XSLT jest bardzo odrażająca dla wielu osób, które po raz pierwszy zetknęły się z tym językiem. Ale istnieją dobre powody i realne korzyści z robienia tego w ten sposób: istnieje argument „szablon”, że duża część kodu składa się z XML, który ma zostać zapisany w dokumencie wynikowym, a najlepszym sposobem na zapisanie XML jest XML. I jest argument „refleksji”; w dużych złożonych systemach bardzo często można znaleźć arkusze stylów, które generują arkusze stylów. Następnie jest argument „narzędzia”; jeśli jesteś w sklepie XML, prawdopodobnie masz dużo narzędzi XML, takich jak edytory sterowane składnią, i dobrze jest móc korzystać z tych samych narzędzi do obsługi programów i danych. Wady okazują się dość kosmetyczne w porównaniu: tam ” s liczba naciśnięć klawiszy związanych z edycją (łatwa do naprawienia za pomocą dobrego narzędzia do edycji) i istnieje szczegółowość kodu (zmniejszająca jego czytelność). Szczegółowość jest znacznie zmniejszona w XSLT 2.0 dzięki wprowadzeniu takich funkcji, jak wyrażenia regularne i funkcje arkuszy stylów: wiele arkuszy stylów jest zmniejszonych do połowy lub jednej trzeciej, gdy w pełni korzystają z XSLT 2.0.
Twoja wzmianka o DSSSL wywołuje u mnie cierpki uśmiech. Nigdy nie korzystałem z DSSSL, ale historie, które słyszałem, były niepotrzebne, ponieważ jego składnia była tajemna i niezwiązana ze składnią danych (SGML). Zastosowanie składni XML dla XSLT było silnie motywowane doświadczeniem z DSSSL.
Są ludzie, którzy kochają XSLT i są ludzie, którzy go nienawidzą. Nic dziwnego, że ci, którzy często go używają, należą do pierwszej kategorii. Ci, którzy go nie lubią, to na ogół ci, którzy nie nauczyli się „myśleć w sposób XSLT”. Można argumentować, że język programowania nie powinien wpływać na twój sposób myślenia, ale tak jest: pisanie w języku opartym na regułach ma inny sposób myślenia niż pisanie w języku imperatywnym. Pierwszą reakcją wielu programistów jest to, że czują się mniej pod kontrolą (opisując problem, zamiast mówić komputerowi, co robić krok po kroku). Jest to bardzo podobne do reakcji, którą obserwowałeś, kiedy ludzie po raz pierwszy zostali zapoznani z SQL. W dzisiejszych czasach ludzie uczą się SQL wcześniej w swojej karierze, więc wymagana jest mniejsza korekta mentalna.
Ostatecznie powinieneś wybrać technologię opartą na obiektywnych, mierzalnych kryteriach, a nie na reakcjach miłości / nienawiści. Te pomiary są trudne. Ale wiele osób używa XSLT bardzo intensywnie i bardzo skutecznie, więc nie ma wątpliwości, że można to zrobić.