Nowy artykuł w dziale artykuły zatytułowany "System.Xml i klasa NameTable" przedstawia korzyści jakie może przynieść zastosowanie obiektów klasy NameTable podczas pracy z dokumentami Xmlowymi oraz pokazuje w jaki sposób używać te obiekty. Artykuł jest o tyle ciekawy, że chociaż skupia się na szczególe implementacyjnym zastosowanym przy implementacji API Xmlowego na platformie .NET, to opisuje pewien wzorzec który można z powodzeniem zastosować niezależnie od platformy i niekoniecznie przy przetwarzaniu dokumentów Xmlowych.

Trzecia część cyklu artykułów o technologii Linq to Xml kontynuuje tematykę zapytań. Artykuł "Linq to Xml, cz. 3 - zapytania - kontunuacja" znajduje się tu. Natomiast strona całego cyklu znajduje się tu. Tym razem jako bonus do artykułu dołączone są źródła w postaci pliku .CS.

Poprawne zastosowanie klasy XslCompiledTransform opisane w artykule "XmlTransform a XslCompiledTransform" pozwala na osiągnięcie maksymalnej wydajności transformacji dokumentów XMLowych za pomocą XSLT na platformie .NET. Jednak sama transformacja to nie wszystko. Często ładowanie i kompilacja arkuszy xslt ma negatywny wpływ na wydajność aplikacji. Fajnie by było, gdyby te czynności można było wykonać wcześniej - np. podczas kompilacji aplikacji zamiast w czasie wykonywania... Marzenia? Niekoniecznie. Proszę sprawdzić artykuł "xsltc.exe - kompilator arkuszy xslt" w sekcji Artykuły.

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..."?