Zmierzch XML

W ciągu kilku lat XML wdarł się bez mała w każdą dziedzinę technologii. Uniwersalność XML, będąca jedną z jego podstawowych zalet, zaczyna mu jednak ciążyć. Czy XML, jaki znamy - prosty, wygodny i jednoznacznie zrozumiały, odejdzie wkrótce w niebyt?

W ciągu kilku lat XML wdarł się bez mała w każdą dziedzinę technologii. Uniwersalność XML, będąca jedną z jego podstawowych zalet, zaczyna mu jednak ciążyć. Czy XML, jaki znamy - prosty, wygodny i jednoznacznie zrozumiały, odejdzie wkrótce w niebyt?

XML stał się uniwersalnym formatem zapisu niemal dowolnej informacji, w której można wyróżnić pewną strukturę. Znacznie prostszy od SGML - języka leżącego u podstaw koncepcji XML - miał być formatem, który rozumieją zarówno maszyny, jak i człowiek. Oczywiście nie użytkownik, ale raczej programista, który dzięki XML miał być w stanie szybko zweryfikować, czy to, co generuje, na pewno jest prawidłowe. XML stał się także - szybciej, niż ktokolwiek mógł przypuszczać, standardem w dziedzinie integracji aplikacji.

XML to w gruncie rzeczy plik tekstowy, w którym struktura informacji, jej rola i znaczenie określane są nie przez tabulatory, średniki czy przecinki, a przez znaczniki (tagi) będące metadanymi. Opisywane na tych łamach niejednokrotnie zalety XML, zwłaszcza w kontekście integracji aplikacji, są obecnie zagrożone, i to co najmniej na dwa sposoby.

Po pierwsze, zagrażają mu mnożące się jak grzyby po deszczu języki i formaty oparte na XML, powstające często tylko dlatego, że "tego jeszcze nie było w postaci XML". Po drugie, nie bez związku z pierwszym, coraz wyraźniej pojawia się problem wydajności przetwarzania XML, skutkujący inicjatywami dążącymi do jego przyspieszenia - najlepiej przez przekształcenie do formy binarnej. Jeśli oba te trendy się utrzymają, dorobek XML - nie tylko w dziedzinie integracji - zostanie w praktyce zaprzepaszczony. Czy tego właśnie chcemy?

Po co komu XML

Na pytanie "czym jest XML" nie można odpowiedzieć prosto. Z jednej strony jest to po prostu format pliku. Jednak - dookoła tego standardu opracowano wiele dodatkowych formatów, które określają strukturę dokumentu XML. Mamy np. standardy dotyczące "zapytań" wybierających dane z dokumentu XML (XPath, XQuery, XLink itp.), mamy infrastrukturę związaną z bezpieczeństwem, mówiącą o tym, w jaki sposób zapisać w postaci XML klucz publiczny, jak zaszyfrować dokument XML, czy też jak dodać do niego podpis cyfrowy.

Dostępne są także mechanizmy transformacji dokumentów XML - XSL i XSLT. Mogą one służyć zarówno do przekształcenia dokumentu XML z jednej postaci na inną, jak i do np. prezentacji danych zawartych w XML jako dokument PDF czy HTML. Wszystkie te mechanizmy związane z XML są opracowywane w taki sposób, że można wziąć dowolny dokument XML, wybrać z niego pewne elementy używając XPath, potem przekształcić wynik w inny dokument XML i na końcu zaszyfrować dokument. Innymi słowy cały stos usług i specyfikacji związanych z XML jest budowany tak, by można było dowolnie "składać" możliwości dawane przez różne standardy.

Prace nad technologiami XML odbywają się głównie w 3 organizacjach - W3C oraz OASIS i WS-I. W3C jest"klasyczną" organizacją standaryzacyjną, o rozbudowanej administracji i podejściu do problemu czasami "czysto" naukowym. OASIS i WS-I (organizacja zajmująca się głównie Web Services) są trochę innymi organizacjami, zrzeszającymi producentów zainteresowanych współpracą i rozwijaniem konkretnych elementów technologicznych.

XML stał się terminem zbyt "marketingowym". Wszyscy inżynierowie zaczynają go stosować, nie zastanawiając się, czy na pewno jest to właściwy wybór. Ostatnio coraz częściej podnoszone są głosy, że nawet przy obecnej mocy komputerów XML jest zbyt "kosztowny". Jeśli przyjrzeć się bliżej, okazuje się, że problem z wydajnością pojawia się główne tam, gdzie jest on stosowany "do wszystkiego".

Przykładowo, nikt się nie zastanawia, czy w danym module rzeczywiście jest potrzebna możliwość współpracy pomiędzy platformami, otwarta komunikacja itp. Pewne rzeczy robi się "na zapas", co nie zawsze ma sens. Całkowicie kuriozalne są przypadki, gdy XML służy do komunikacji pomiędzy dwoma często wywoływanymi procedurami w ramach tego samego modułu programu. Gdy jeszcze pierwszym elementem takiego dokumentu jest "identyfikator" sesji, a drugim - dane binarne zapisane jako base64... to nie jest przykład wyssany z palca.

Od prostoty do nieskończoności

Nie można nie zauważyć, że wszystko to ma miejsce, ponieważ technologie "około XML-owe" są zbyt rozbudowane i bardzo uniwersalne. To niby dobrze, ale z drugiej strony, czasem warto, by pewne elementy XML uprościć. Weźmy np. XSLT - język pozwalający określić zasady transformacji dokumentu. Programista wskazuje w nim zbiory i określa warunki, w których konkretna transformacja będzie zastosowana itp. Twórcy witryn czasami zapominają, że dany element byłoby znacznie prościej napisać przy użyciu pętli czy warunku logicznego, a więc poleceń znanych z każdego języka strukturalnego. W konsekwencji powstają bardzo złożone arkusze transformacji, które mozolnie muszą być przekształcane poprzez parser. To nie może działać wydajnie.

Początkowo idea była taka, że to serwer wysyła XML i XSLT, a przeglądarka kliencka generuje wynik. Problemem okazał się fakt, że, po pierwsze, są pewne różnice w sposobach działania konkretnych parserów w przeglądarkach, a po drugie, że czasami taka transformacja jest zbyt obciążająca dla komputera-klienta systemu - zwłaszcza w przypadku rozwiązań mobilnych. Tak więc powszechne jest to, że całą transformację XSLT wykonuje serwer i odsyła klientowi gotowy wynik. Niewiele osób zadaje sobie pytanie - czy na pewno opłacalne jest wykorzystywanie całej maszynerii standardów XSL(T). W wielu przypadkach można je zastąpić wynikiem, szybko generowanym na podstawie szablonu.