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.

Jakiś czas temu Microsoft wydał nowy parser Xml o nazwie XmlLite. Parser ten jest przeznaczony do użytku w środowisku natywnym (C++). Jego celem jest bardziej uzupełnienie niż zastąpienie znanego od lat parsera MSXML. Z założenia XmlLite jest 'lekkim', zawierającym jak najmniej powiązań z innymi komponentami, szybkim parserem Xml działającym na wzór znanych ze środowiska .NET XmlReadera i XmlWritera. W obecnej wersji posiada XmlLite sporo ograniczeń - między innymi - brak implenentacji struktury DOM, brak walidacji przetwarzanego dokumentu za pomocą xsd czy DTD czy brak obsługi XSLT. W kwietniowym numerze MSDN Magazine znajduje się doskonały artykuł o XmlLite. Wersja online'owa artykułu dostępna jest pod poniższym linkiem:
http://msdn.microsoft.com/msdnmag/issues/07/04/Xml/default.aspx.
XmlLite jest częścią systemu operacyjnego Windows Vista. Dla wcześniejszych wersji systemów Windows Istnieje możliwość ściągnięcia osobnego pakietu instalacyjnego.

W nowym dziale będą umieszczane przydatne fragmenty kodu - w większości gotowe funkcje Xslowe. Dorobiłem sie ich pracując przez ostatnie kilka lat z techonologiami Xmlowymi. Zwykle są one niezależne od projektu nad którym aktualnie pracowałem więc myślę, że - generalnie - mogą się przydać każdemu. Dzisiaj pierwsza funkcja - zamiana łańcucha znakowego rozdzielony separatorami na listę node'ów zawierającą poszczególne tokeny - czyli Split String.

Zapraszam do działu Przybornik X(ml)-mana

Jedno ze środowisk, którego używam służy do wykonywania zewnętrznych skryptów. Skrypty te są dokumentami Xmlowymi i mogą wywoływać zewnętrzne funkcje. Parametry typu string przekazywane do funkcji powinny znajdować się w apostrofach. W związku z pewnymi modyfikacjami uległo to zmianie i apostrofy stały się zbyteczne lub wręcz niepożądane i trzeba było je usunąć. Ponieważ skryptów było sporo, a niektóre z nich miały dość pokaźne rozmiary obawiałem się, że zwykłe "search and replace" może spowodować wiele błędów. Napisałem więc mały arkusz XSLT, który "odwalił za mnie czarną robotę". Jednym z interesujących zagadnień podczas pisania tego arkusza była obsługa apostrofów w argumentach funkcji XPath. O tym w jaki sposób sobie radzić z apostrofami w argumentach funkcji XPathowych traktuje nowo dodany punkt w dziale Sztuczki Kruczki.