TheTarPit

XML

XML — skrót robiący w ostatnich latach niewyobrażalną wręcz (i mocno niepokojącą, o czym za chwilę) karierę. I to skrót właśnie, te magiczne trzy literki, nie nazwa "eXtensible Markup Language", i z pewnością nie specyfikacja tegoż. W zbiorowej świadomości ludzi związanych z informatyką "akurat na tyle, żeby się ciężką prac nie pobrudzić" XML zagnieździł się na dobre. A że niezupełnie w tej przegródce co trzeba, to wydaje się mało istotnym szczegółem technicznym...

Stan tej świadomości całkiem trafnie wyraża znaleziony naprędce na W3 Schools tekst o tytule "How can XML be Used?". Opiewa on zbawienne skutki stosowania XML-a w kilku prostych zdaniach, z którymi pozwolę sobie polemizować:

• With XML, your data is stored outside your HTML.
  Podobnie jak dane przechowywane w dowolnym innym formacie, pliku, bazie danych. To tylko kwestia zastosowania mechanizmu czytającego te dane i generującego kod wynikowy strony.
• With XML, data can be exchanged between incompatible systems.
  Co oczywiście wymaga jeszcze uzgodnienia formatu danych po obu stronach. A uzgodnić można wszystko, np. że dane będą kodowane w EBCDIC-u.
• With XML, financial information can be exchanged over the Internet.
  Dokładnie tak samo jak w każdym innym formacie, tekstowym lub nie.
• With XML, plain text files can be used to share/store data.
  Dokładnie tak samo jak w każdym innym formacie tekstowym o znanej/ustalonej/uzgodnionej strukturze.
• With XML, your data is available to more users.
  A to po prostu nie prawda, a w najlepszym wypadku prawda naciągana.

Ale największa bzdura dotycząca XML-a to powtarzane nader często stwierdzenie "Every tool can process every document". Jaki program zrozumie i będzie umiał sensownie przetworzyć poniższy kod?

<?xml version="1.0" encoding="ISO-8859-2"?>
<shoppinglist date="2004.07.09">
 <item>
  <name>piwo</name>
  <brand>Tatra</brand>
  <package>czteropak</package>
  <quantity>1</quantity>
 </item>
 <item>
  <name>bułka</name>
  <brand>kajzerka</brand>
  <package>sztuka</package>
  <quantity>10</quantity>
 </item>
 <item>
  <name>karma dla kota</name>
  <brand>Whiskas</brand>
  <package>saszetki 3+1</package>
  <quantity>10</quantity>
 </item>
</shoppinglist>

Nie pokazać, bo to potrafi najbanalniejszy program to podglądu dokumentów SGML czy nawet plików tekstowych, tylko przetworzyć tak, żeby było wiadomo, że jest to lista zakupów, i żeby się z tego policzył np. szacowany koszt na podstawie aktualnych uśrednionych cenników czy wskaźników rynkowych. No? Przecież every tool, więc słucham...

Obrońcy i/lub fanatycy XML-a powiedzą zaraz, że wystarczy mieć program, który będzie oczekiwał takich danych i on sobie to przeczyta. Zgodnie zresztą z zapisem specyfikacji

It is assumed that an XML processor is doing its work on behalf of another module, called the application.

Kwestia jedynie określenia czym jest "application". Jasne. Tylko, że jeżeli mam mieć program, który rozumie takiego właśnie XML-a (to znaczy będzie wiedział, że <quantity> to ilość a nie np. rozmiar), to równie dobrze mogę mieć też program, który zrozumie np. to:

SL1.0|ISO-8859-2|2004.07.09
piwo|Tatra|czteropak|1
bułka|kajzerka|sztuka|10
karma dla kota|Whiskas|saszetki 3+1|10

Bez określonej gramatyki (typu dokumentu, reguł formatu, specyfikacji) plik w formacie XML jest w praktycznym zastosowaniu tak samo dobry, czy tak samo zły, jak dowolny inny plik tekstowy lub binarny. A może nawet jest gorszy, bo redundancja XML-a jest ogromna — powyższe dwa przykłady, choć tak znacznie różne w objętości, zawierają dokładnie tą samą informację.

Oczywiście, stwierdzenie że konieczne jest określenie (lub założenie) typu dokumentu XML i dobranie czegoś sensownego w miejsce "another module, called the application" jest banalne. Jednak trzeba je powtarzać zawsze i wszędzie, gdzie występuje stwierdzenie typu "every tool, every document", ponieważ to drugie puszczone samopas powoduje więcej szkody niż pożytku^[1]. Współczesna informatyka wykorzystuje bardzo wiele różnego typu dokumentów XML (czy SGML w ogólności) i istnieje wiele pożytecznych specyfikacji łącznie z XHTML, XSLT, RSS, XMI, SOAP, WSDL i dziesiątkami innych, bez których żyć już się nie da. Jednak wszystko to są jasno określone typu dokumentów, więc pliki zapisane w tych formatach mają jasno określoną strukturę i zakres dopuszczalnej zawartości, i są przeznaczone do przetwarzania przez określone aplikacje. Na pewno nie są to "dowolne dokumenty odczytywalne przez dowolne narzędzia". Wrzucanie tego wszystkiego do wspólnego worka z naklejką XML stwarza trudną do opanowania i "odkręcenia" opinię, że "XML wszystko załatwia". Podczas gdy sam w sobie nie załatwia jeszcze absolutnie nic...

...oprócz bólu głowy kiedy trzeba uzasadnić konieczność napisania kodu interfejsu między systemami i wykazać, że "generic XML parser" to trochę mało, żeby się dwa dowolne systemy na dwóch różnych platformach dogadały.

Komentarze