XslTransform - temat wydaje się być nie na czasie... A jednak ciągle się spotykam z aplikacjami, które używają nowej klasy XslCompiledTransform w sposób nie taki jaki był zamysłem projektantów i autorów. Nieprzypadkowo gro tych aplikacji to aplikacje przeniesione z .NET Framework 1.1. Oczywiście wszystko od strony funkcjonalnej działa poprawnie. Tylko często może być po prostu o wiele szybciej. (Oczywiście postęp w dziedzinie sprzętu jest na tyle duży, że mimo wszystko aplikacja dzisiaj może chodzić szybciej niż kilka lat temu nawet jeśli nie wykorzystuje optymalnych rozwiązań). Chyba warto sprawdzić - artykuł XslTransform a XslCompiledTransform nie jest długi. Esencja znajduje się w dziale Sztuczki Kruczki.

Część druga cyklu artykułów o Linq to Xml. Po wprowadzeniu do technologii nadszedł czas na pierwsze - stosunkowe proste - zapytania. Artykuł "Linq to Xml, cz2 - wstęp do zapytań" znajduje się tu. Natomiast strona całego cyklu znajduje się tu.

26 listopada 2008 World Wide Web Consortium opublikowało ostateczną wersję piątej edycji specyfikacji języka Xml. Główne zmiany wprowadzone w tej edycji to rozszerzenie zakresu znaków (w tym surogatów) dozwolonych w dokumentach Xmlowych (http://www.w3.org/TR/xml/#charsets) oraz rozluźnienie reguł (reguły?) dotyczących numerowania wersji dokumentu xml - do tej pory wersja mogła być tylko "1.0", teraz wersja jest zdefiniowana następująco: '1.' [0-9]+ (http://www.w3.org/TR/xml/#sec-prolog-dtd).
Link do rekomendacji: http://www.w3.org/TR/xml/.

Rzecz jest z pozoru drobna ale okazuje się, że może przysporzyć kłopotu - szczególnie jeśli ktoś z Xslt nie miał za dużo do czynienia. Otóż trzeba stworzyć atrybut, którego wartość zawiera nawiasy klamrowe... Oczywiście - można użyć instrukcji xsl:attribute, ale jest to (delikatnie mówiąc) rozwlekłe - 3 linie zamiast jednej. A jak się chce to zrobić "normalnie" to nie chce działać! Nowy punkt w dziale Sztuczki Kruczki pokazuje jak osiągnąć cel - w sposób naturalny i za razem możliwie zwięzły stworzyć atrybut, którego wartość posiada nawias klamrowy.
Czy jest to konieczne do przeżycia w dzisiejszym świecie? - na pewno nie. Czy warto wiedzieć? - na pewno nie zaszkodzi...

Linq to Xml (wcześniej nazywany XLinq) to stosunkowo nowe API do pracy z dokumentami Xml na platformie .NET (pojawiło się w wersji 3.5 .NET Frameworka). Mimo to, wiele osób nie tylko o nim "słyszało" ale wręcz używa go "od dawna". Z czego się bierze popularność tej technologii? Jest bardzo poręczna a przy tym niezbyt trudna w użyciu. Dodatkowo wypełnia pewną lukę, którą wielu programistów podświadomie czuło - idealnie nadaje się do prostych transformacji dokumentów Xmlowych czyli w miejscach gdzie zastosowanie Xslt to (nie-)lekka przesada a manipulacje za pomocą metod interfejsu DOM (XmlDocument et al.) są zbyt uciążliwe. Dodajmy do tego wsparcie w składni samego języka programowania (C#, VB.NET) i o sukces nietrudno.
Dzisiaj w xml.com.pl - pierwszy z serii artykułów opisujących Linq to Xml zawierający krótkie wprowadzenie oraz pokazujący jak zacząć prace z Linq to Xml.

W .NET Framework 2.0 zostało wprowadzone nowe API do walidacji dokumentów Xml za pomocą schemy (istniejące API - mimo, że wciąż dostępne - zostało oznaczona jako "obsolete", co w praktyce oznacza, że w tym obszarze nie są już prowadzone żadne prace developerskie). Nowe API, oprócz wielu udoskonaleń, umożliwia także użytkownikowi przekazanie dodatkowych flag zwiększających kontrolę nad przebiegiem procesu walidacji. Programiści zdają się zazwyczaj w takich przypadkach na projektantów API i (świadomie lub nieświadomie) używają wartości domyślnych zdefiniowanych w API. Niestety zastosowanie tego podejścia wraz z nowym API do walidacji dokumentów Xml (XmlSchemaSet et al.) może zakończyć się przykrą niespodzianką. Na pytania: kiedy? dlaczego? oraz jak tego uniknąć? odpowiada nowy artykuł zatytułowany: "Walidacja dokumentów a flaga XmlSchema ReportValidationWarnings" dodany do sekcji Artykuły.

Mimo, że operacje na łańcuchach znakowych to chyba jedne z najczęściej wykonywanych operacji, biblioteka funkcji do pracy z łańcuchami znakowymi w Xslt 1.0 jest bardzo uboga. Słabe wsparcie operacji na łańcuchach znakowych w Xslt 1.0 nierzadko prowadzi do umieszczania skryptów w arkuszu. Oczywiście takie rozwiązanie działa ale w wielu przypadkach identyczną pod względem funkcjonalności metodę można napisać w "czystym" Xslt (często trzeba uciec się do rekurencji). W Przyborniku została dodana jedna z tego typu funkcji - mianowicie funkcja podmieniająca łańcuch znakowy innym łańcuchem znakowym w zadanym łańcuchu znakowym (brzmi kiepsko a to po prostu replace string)

Jeśli kiedykolwiek próbowaliście bezskutecznie wpłynąć na format wynikowego dokumentu transformacji za pomocą instrukcji xsl:output istnieje duża szansa, że miało to związek ze zmianami w serializacji wprowadzonymi w wersji 2.0  .NET Frameworka. W wyniku tych zmian, w niektorych przypadkach programista sam musi zadbać o przekazanie do serializacji informacji wyspecyfikowanych w instrukcji xsl:output. Więcej szczegółów (wraz z przykładami) w dziale Sztuczki Kruczki.

Transformacja tożsamościowa (ang. identity transform) w Xslt jest na tyle przydatna i istotna, że artykuł na jej temat powinien się pojawić jako jeden z pierwszych artukułów na xml.com.pl. Tak się jednak nie stało i dzisiaj naprawiam to niedopatrzenie - w dziale artykuły pojawił się nowy artykuł opisujący transfomację tożsamościową.

Ostatnio miałem okazję pobawić się troszkę Linq to Xml (czasami też nazywane XLinq). Miła technologia. Do pewnych zastosowań nadaje się lepiej niż do innych ale ogólnie bardzo mi się podoba. Przez (krótką) chwilę miałem ochotę przejrzeć listę swoich projektów i - tam gdzie to możliwe - podmienić istniejący kod na Linq to Xml. Na szczęście szybko porzuciłem ten pomysł bo istniejący kod był przetestowany i działał poprawnie. Zmiana pociągnełaby za sobą niepotrzebne koszty (czas potrzebny na kodowanie, testy jednostkowe, testowanie itp.) oraz ryzyko wprowadzenia błędów. Trudno mi było znaleźć usprawiedliwienie dla takiego refaktoringu. O wiele bezpieczeniejsze (i tańsze) było pozostawienie istniejącego kodu bez zmian, i zastosowanie nowej technologii tylko w nowym kodzie. Przy takim podejściu trzeba było znaleźć odpowiedź na pytanie: W jaki sposób przekonwertować model danych używany w 'starym' kodzie na model danych używany w 'nowym' kodzie? W tym konkretnym przypadku - 'stary' kod używa klas z przestrzeni nazw System.Xml, a 'nowy' kod będzie dodatkowo używał Linq to Xml (czyli klas z przestrzeni nazw System.Xml.Linq). Okazało się, że konwersja - niezależnie od tego, w którą stronę konwertujemy - jest dziecinnie prosta. W dziale Sztuczki Kruczki jest pokazane jak ona wygląda.

Format Xml stał się chyba najpopularniejszym formatem do wymiany danych. Nie powinno to dziwić - Xml nie jest ściśle powiązany z żadnym systemem operacyjnym, producentem oprogramowania czy technologią a parsery Xml są dostępne na praktycznie każdej platformie. Z tego względu często dokonuje się konwersji istniejących protokołów na format Xmlowy. Większość standardów i protokołów podlega jednak innym regułom niż Xml (np. dopuszczone są do użytku znaki, których specyfikacjca Xml nie dopuszcza). W takich przypadkach automatyczna konwersja na Xml może być kłopotliwa. Rozwiązaniem (na platformie .NET) jest zastosowanie klasy XmlConvert opisanej w dziale Sztuczki Kruczki. 

Walidacja dokumentów Xmlowych za pomocą schemy (Xsd) jest dość powszechnym zagadnieniem. Mimo to (a może właśnie dlatego) wiele osób pyta jak to zrobić. Na platformie .NET dodatkowe zamieszanie stwarza fakt, że począwszy od wersji 2.0 .NET Frameworka został wprowadzony nowy sposób walidacji. Co prawda walidacja znana z wcześniejszych wersji .NET Frameworka wciąż jest dostępna ale zaleca się używanie nowej metody. Przykład pokazujący jak walidować dokumenty Xml za pomocą schemy na platformie .NET Framework został zamieszczony w Przyborniku. Dodatkowy odnośnik znajduje się też w F.A.Q.

http://xml.com.pl dorobił się wreszcie swojego kanału (?) czyli feeda. Po lewej stronie poniżej menu znajduje się link "Subskrybuj newsy", który pozwala na dodanie xml.com.pl do swoich kanałów. Jako, że jest to feed to można chyba powiedziec: "Bierzcie i jedzcie z tego wszyscy..."?

Wiele osób skarży się, że wydajność transformacji XSLT jest często niezadowalająca. Czasem trudno powiedzieć czy wina leży po stronie samego XSLT czy sposobu w jaki arkusz został napisany. Nierzadko zdarza się, że problemem jest zastosowanie w arkuszu bardzo kosztownych wyrażeń XPath (w szczególności używanie w wyrażeniach XPath '//' może powodować duże problemy z wydajnoscią). Bywa jednak, że transformacja z jakiegoś powodu jest bardzo wolna i trudno powiedzieć co tak naprawde jest tego przyczyną. Optymalizacja 'w ciemno' nie jest dobrym pomysłem ponieważ często okazuje się, że kod po zmianach nie jest wcale zauważalnie szybszy. Dodatkowo, wprowadzone zmiany mogą skutkować nie tylko mało przejrzystym, (lub wręcz nieczytelnym) kodem ale także błędami. Dlatego optymalizację kodu (szczególnie w późnych fazach proejktu) należy wprowadzać ostrożnie i tylko w miejscach gdzie jest to konieczne. Tylko jak znaleźć te miejca? Do niedawna było to zadanie dość kłopotliwe ale wydany ostatnio przez Microsoft XSLT Profiler Addin dla Visual Studio 2008 potrafi je znacznie ułatwić. Profiler można pobrać ze strony domowej: http://code.msdn.microsoft.com/xsltprofiler. Profiler współpracuje z Visual Studio 2008 Team System i wymaga zainstalowanych narzędzi do mierzenia wydajności (Performance Tools).

Grupowanie jest stosunkowo często pojawiającym się problemem podczas pracy z Xslt. Najczęściej potrzeba pogrupowac węzły ze względu na jakąś cechę (np. wartość określonego atrybutu). Zazwyczej pojawiają się w takim przypadku dwa podstawowe pytania. Pierwsze - "jak to zrobic?", oraz drugie - "jak to zrobic efektywnie"? Artykuł "Zastosowanie kluczy do grupowania w XSLT 1.0" stara się odpowiedzieć na oba te pytania. Opisana metoda (znana też pod nazwą "metoda Muencha" (ang. Muenchian method) - od nazwiska twórcy) dotyczy głównie XSLT 1.0. Wersja 2.0 zawiera wbudowane mechanizmy grupowania.

Jeśli kiedykolwiek mieliście problemy z wstawieniem znaku nowej linii (popularny '\n') w XSLT to polecam dział Sztuczki Kruczki gdzie został dodany nowy punkt zawierający przykłady rozwiązania tego zagadnienia. 

Czy wiecie, ze kilka dni temu Xml obchodził swoje 10 urodziny? Pierwsza oficjalna rekomendacja standardu XML została opublikowana przez W3 Consortium dokładnie 10 lutego 1998 r. (Dla zainteresowanych - dokument mozna znaleźć tutaj). Strona rocznicowa znajduje się tutaj.