Co to jest XML (Extensible Markup Language)? Struktura i zastosowanie

XML (Extensible Markup Language) to uniwersalny, tekstowy format zapisu danych, który używa niestandardowych znaczników do strukturyzacji informacji w sposób czytelny dla maszyn i ludzi. Jego głównym, technicznym zastosowaniem jest bezstratna wymiana danych między skrajnie różnymi systemami informatycznymi, niezależnie od używanego języka programowania czy platformy sprzętowej.

To po prostu standard. Pozwala aplikacjom rozmawiać ze sobą, nawet jeśli jedna działa na starym serwerze z Windowsem, a druga to nowoczesna usługa w chmurze na Linuksie. My w branży widzimy to na co dzień. Masz stary system ERP i nową aplikację mobilną. Żeby te dwa byty mogły przesłać sobie informacje o fakturze, potrzebują wspólnego języka. Extensible Markup Language daje im ten język. Wystarczy zdefiniować odpowiednie tagi.

Do czego tak naprawdę służy XML w aplikacjach i wymianie danych?

Rozwiązuje problem niekompatybilności. Przesyłanie surowych ciągów znaków bez opisu jest bezcelowe, bo system docelowy nie wie, co czyta. XML nadaje danym kontekst. Używamy go przede wszystkim w architekturze SOAP, przy budowie starszych interfejsów API oraz w konfiguracjach serwerów. Gwarantuje bardzo sztywny rygor. Systemy bankowe, urzędowe i telekomunikacyjne opierają na nim przepływ swoich informacji, bo nie wybaczają błędów w formatowaniu.

Dobrym pomysłem jest spojrzenie na to z perspektywy zwykłego wdrożenia. Zrobiliśmy miesiąc temu integrację dla lokalnego zakładu wodociągów w Radomiu. Stary system zliczający zużycie wody wypluwał z siebie tylko pliki tekstowe. Nowy system księgowy nie potrafił tego przeczytać. Napisaliśmy prosty parser, który ubiera te surowe liczby w strukturę XML. Księgowość od razu zaczęła prawidłowo przypisywać wartości do odpowiednich kont. To działa. Zawsze.

A prawda jest zresztą absolutnie taka, że parsowanie starych plików XML z urzędów to droga przez mękę. Zrobiliśmy na wdrożeniu X parser, potem zawiesiło się czytanie węzłów, bo jakiś geniusz w 2008 roku wymyślił sobie polskie znaki w nazwach tagów bez deklaracji kodowania UTF-8 w nagłówku. Wprowadzono poprawkę na twardo przed poniedziałkiem. Do dzisiaj mnie trzęsie, jak widzę te pliki na dysku. Ale system to łyka, więc nikt tego w najbliższym czasie nie przepisze na nowsze formaty u nich w piwnicy serwerowej.

Jak wygląda poprawna struktura drzewa XML?

Dokumenty strukturalne w tym formacie zawsze mają postać drzewa. Składnia XML wymaga zachowania absolutnej hierarchii. Jeśli jej nie utrzymasz, parser wyrzuci błąd krytyczny i zatrzyma proces.

• Węzeł główny (Root element) to podstawa. Zawsze jest tylko jeden i obejmuje cały dokument. Jeśli masz dwa węzły główne, plik jest uszkodzony.
• Elementy potomne (Child nodes) to wszystkie tagi zagnieżdżone wewnątrz węzła głównego. Mogą mieć swoje własne dzieci, tworząc wielopoziomowe gałęzie.
• Atrybuty. To dodatkowe informacje umieszczane bezpośrednio wewnątrz tagu otwierającego.
• Prolog. Pierwsza linijka pliku, która mówi parserowi o wersji języka i kodowaniu znaków.

Więc to nie jest luźny zbiór notatek. To twarda, zmatematyzowana struktura. Każdy znacznik otwierający musi mieć swój znacznik zamykający. Zgubisz jeden ukośnik i cały plik staje się bezużyteczny.

Dlaczego systemy bankowe i księgowe wciąż opierają się na XML?

Bo gwarantuje bezpieczeństwo walidacji. W bankowości nikt nie pozwoli sobie na przesyłanie luźnych, niesprawdzonych struktur. Extensible Markup Language ma wbudowane potężne mechanizmy weryfikacji. Używamy do tego standardu XSD (XML Schema Definition). XSD to taki szablon, który mówi serwerowi: „Zanim wpuścisz ten plik do bazy danych, sprawdź, czy pole kwoty jest na pewno liczbą, a pole daty ma format RRRR-MM-DD”.

Widzimy to w Polsce na przykładzie Ministerstwa Finansów. Jednolity Plik Kontrolny (JPK) to nic innego jak gigantyczny plik XML. Urząd Skarbowy wymaga go w tej formie, ponieważ ich serwery mogą automatycznie zwalidować miliony takich plików w ciągu nocy, opierając się na schematach XSD. Jeśli w twoim JPK brakuje wymaganego tagu, system odrzuci go w ułamku sekundy.

I tu wchodzi kwestia pewności. To u nas w sumie chyba hipoteza z wczoraj, bo pewności do tych trendów nikt obecnie nie ma o 2025 r., ale wydaje się, że urzędy nie zrezygnują z tego standardu przez co najmniej kolejną dekadę. Migracja kosztowałaby miliardy, a obecne rozwiązanie po prostu spełnia swoje zadanie.

Czym różni się atrybut od elementu w składni?

Zrozumienie tego to absolutny FUNDAMENT. Element to dane właściwe. Atrybut to metadane o tych danych. Na przykład, jeśli masz element o nazwie „Cena”, wewnątrz niego wpiszesz wartość „150”. Ale walutę, w jakiej ta cena jest wyrażona, lepiej wrzucić jako atrybut. Zapiszesz to jako tag „Cena” z atrybutem „waluta” równym „PLN”.

Często programiści kłócą się o to, kiedy używać atrybutów, a kiedy zagnieżdżać kolejne elementy. Ja trzymam się prostej zasady z warsztatu. Jeśli dana informacja musi być rozbudowywana o kolejne szczegóły w przyszłości, rób z niej oddzielny tag. Jeśli to tylko jednorazowy identyfikator, używaj atrybutu. Zmieniliśmy te zasady na robocie dwa lata temu i od tamtej pory parsowanie idzie nam o wiele szybciej.

Jak parsować pliki XML bez obciążania pamięci serwera?

Wczytywanie gigantycznych plików potrafi zabić każdy serwer. Wyobraź sobie, że dostajesz od hurtowni plik z cennikiem, który waży 4 gigabajty. Jak go przeczytać i przetworzyć?

Mamy do dyspozycji dwie główne metody. DOM (Document Object Model) oraz SAX (Simple API for XML). Wybór odpowiedniego narzędzia decyduje o tym, czy twój serwer przetrwa nocną synchronizację danych.

Drzewo DOM ładuje cały dokument prosto do pamięci RAM. Tworzy w niej pełną reprezentację pliku. To świetne rozwiązanie, jeśli plik jest mały i musisz po nim swobodnie skakać, modyfikując węzły w różnych miejscach. Ale przy pliku 4 GB, DOM zje ci całą pamięć i wywali aplikację. Wtedy wkracza parser SAX. SAX czyta dokument linijka po linijce, jak strumień. Nie trzyma całości w pamięci. Rozpoznaje tag otwierający, pobiera wartość, wyzwala zdarzenie i natychmiast o nim zapomina. Jest szybki i lekki.

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Próbowaliśmy wczytać stary zrzut bazy z systemu medycznego przez DOM. Skrypt zaciął się po pięciu minutach. Zamiana klasy parsującej na strumieniową rozwiązała problem od ręki.

Czy JSON ostatecznie zabije standard XML?

Nie zabije. JSON (JavaScript Object Notation) wygrał walkę w przeglądarkach i w lekkich interfejsach REST API. Jest lżejszy, szybszy do napisania i natywnie obsługiwany przez JavaScript. Prawie połowa nowych projektów webowych używa wyłącznie JSON-a. Ale Extensible Markup Language trzyma się mocno tam, gdzie JSON nie sięga.

JSON nie ma wbudowanego i tak mocnego standardu schematów jak XSD. Nie obsługuje natywnie przestrzeni nazw (namespaces), co jest problemem, gdy próbujesz połączyć dane z dwóch różnych źródeł, które używają takich samych nazw pól. XML pozwala na dodanie prefiksów. Dzięki temu wiesz, że tag „id” pochodzi z systemu magazynowego, a tag „id” obok pochodzi z systemu kadrowego. JSON tego nie potrafi.

Narzędzia do walidacji i przestrzenie nazw

Wspominałem o przestrzeniach nazw (namespaces). To one robią największą różnicę w dużych korporacjach. Wyobraź sobie, że łączysz dane o klientach z dwóch różnych oddziałów firmy. W obu plikach masz element o nazwie „adres”. W jednym to po prostu ulica i numer, w drugim to skomplikowana struktura z kodem pocztowym, województwem i krajem. Gdybyś połączył te pliki bez przestrzeni nazw, parser by zwariował.

Dlatego używamy atrybutu xmlns. Definiuje on unikalny identyfikator (zazwyczaj w formie URL) dla danej grupy tagów. Brzmi to skomplikowanie, ale na poziomie kodu to zwykłe dopisanie przedrostka przed każdym tagiem. Rozdziela to logikę.

Siedzisz nad logami o trzeciej nad ranem. Widzisz błąd parsowania. Zwykle okazuje się, że ktoś po stronie klienta zapomniał zaktualizować schemat XSD, a wysłał plik w nowym formacie. Walidator odrzuca to na wejściu. I dobrze. Lepiej odrzucić plik na bramce, niż wpuścić śmieciowe dane do bazy i zepsuć księgowość za cały miesiąc. Poprawa takich rekordów kosztuje tysiące złotych.

Co to jest DTD i dlaczego rzadko się go używa?

Przed erą XSD używaliśmy DTD (Document Type Definition). DTD robi to samo co XSD – definiuje strukturę dokumentu. Ale ma jedną, ogromną wadę. Jest napisane w swoim własnym, dziwnym języku. Nie jest dokumentem XML. To oznacza, że potrzebujesz osobnego parsera, żeby przeczytać plik DTD, i osobnego, żeby przeczytać właściwe dane.

XSD jest napisane w czystym XML. Parser czyta schemat dokładnie tak samo, jak czyta dane. To ujednoliciło architekturę. Dzisiaj DTD spotkasz tylko w bardzo starych systemach, tak zwanych legacy, które ktoś napisał w latach dziewięćdziesiątych i boi się ruszyć. Zostawiamy to w spokoju. Działa, więc nie dotykamy.

Sprawdźcie dzisiaj swoje logi z zewnętrznych integracji API. Gwarantuję wam, że gdzieś w tle wasza aplikacja cały czas wypluwa paczki danych w tagach, o których nawet nie wiedzieliście. Zajrzyjcie w te struktury.

FAQ – Najczęściej zadawane pytania

1. Co to jest XML w prostych słowach?

To tekstowy format zapisu danych. Używa znaczników (podobnych do HTML), aby organizować informacje w sposób zrozumiały dla różnych programów i maszyn.

2. Czy XML to język programowania?

Nie. To język znaczników (markup language). Nie zawiera logiki, pętli ani warunków. Służy wyłącznie do przechowywania i transportowania danych.

3. Jak otworzyć plik XML?

Możesz go otworzyć w każdym edytorze tekstu, takim jak Notatnik, Notepad++ czy Visual Studio Code. Przeglądarki internetowe również potrafią wyświetlić jego drzewiastą strukturę.

4. Czym XML różni się od HTML?

HTML służy do wyświetlania danych na stronach internetowych i ma z góry zdefiniowane tagi. XML służy do przenoszenia danych, a tagi wymyślasz sam, w zależności od potrzeb aplikacji.

5. Co to jest parsowanie XML?

To proces, w którym program komputerowy czyta plik tekstowy XML, analizuje jego strukturę i zamienia go na obiekty w pamięci, na których można wykonywać operacje matematyczne lub logiczne.

6. Czy XML jest jeszcze używany?

Zdecydowanie tak. Choć w aplikacjach webowych ustąpił miejsca formatowi JSON, nadal stanowi podstawę systemów bankowych, urzędowych (np. JPK), protokołu SOAP i wielu konfiguracji oprogramowania klasy Enterprise.

Bibliografia:

1. W3C – https://www.w3.org

2. MDN Web Docs – https://developer.mozilla.org

3. Microsoft Learn – https://learn.microsoft.com

4. Oracle – https://www.oracle.com

5. Ministerstwo Finansów – https://www.gov.pl/web/finanse

6. IBM – https://www.ibm.com