Kompatybilność składni XML

Kompatybilność składni XML dotyczy obsługi metod i zapytań na danych w tym formacie w poszczególnych wersjach serwera.

Na czym polega kompatybilność składni XML

Kompatybilność składni XML oznacza możliwość poprawnego odczytywania, przetwarzania i zapisywania dokumentów XML przez określone narzędzie, bibliotekę albo wersję silnika. Sam dokument może być zgodny z regułami XML, a mimo to nie działać poprawnie w konkretnym programie, ponieważ aplikacja obsługuje tylko wybrany zestaw typów danych, funkcji zapytań lub metod pracy z dokumentem. Z tego powodu trzeba odróżnić poprawność składniową pliku od zgodności funkcjonalnej z używanym środowiskiem.

Podstawowe reguły XML określają między innymi konieczność istnienia jednego elementu głównego, prawidłowego zamykania znaczników, poprawnego zagnieżdżania elementów oraz stosowania cudzysłowów przy wartościach atrybutów. Dokument spełniający te warunki jest nazywany poprawnie sformułowanym, czyli well-formed. Nie oznacza to jednak, że będzie zgodny ze schematem XSD, definicją DTD albo konkretnym interfejsem programistycznym. Kompatybilność obejmuje więc zarówno samą strukturę danych, jak i sposób, w jaki dane są wyszukiwane oraz interpretowane.

Wersja XML a możliwości parsera i zapytań

W deklaracji dokumentu można wskazać wersję XML, na przykład XML 1.0 albo XML 1.1. XML 1.0 pozostaje najczęściej obsługiwaną wersją, natomiast XML 1.1 wprowadza odmienne zasady dotyczące niektórych znaków sterujących i wymaga świadomej obsługi po stronie parsera. Program, który nie implementuje XML 1.1, może zgłosić błąd już podczas otwierania dokumentu, nawet jeżeli dokument został przygotowany zgodnie z regułami tej wersji.

Różnice pojawiają się również w językach zapytań i metodach dostępu do danych. XPath służy do wskazywania węzłów w strukturze XML, ale obsługiwany zakres zależy od wersji biblioteki. XPath 1.0 nie zapewnia wszystkich możliwości znanych z nowszych implementacji, takich jak funkcje i wyrażenia wprowadzone w późniejszych wersjach. XQuery jest odrębnym językiem o szerszym zakresie zastosowań, dlatego zapytanie napisane dla jednego procesora może wymagać zmiany w innym. Przed migracją trzeba sprawdzić, które funkcje, typy danych i osie lokalizacji są rzeczywiście dostępne.

Typowe źródła niezgodności w dokumentach i zapytaniach

Częstym problemem jest kodowanie znaków. XML może określać kodowanie w deklaracji, na przykład UTF-8, ale faktyczny zapis pliku może używać innego kodowania. Niezgodność między deklaracją a bajtami odczytanymi z pliku prowadzi do błędów dekodowania albo do nieprawidłowego wyświetlania polskich znaków. Znaczenie ma także przestrzeń nazw XML. Element zapisany jako <item> nie jest tym samym węzłem co element należący do przestrzeni nazw, nawet jeśli prefiks został pominięty lub zmieniony.

Niekompatybilność może dotyczyć również schematów, typów wartości i konwersji danych. Jeden system może oczekiwać daty w formacie zgodnym z typem xs:date, a inny może przyjmować wyłącznie tekst. Podobna różnica występuje przy wartościach pustych, brakujących elementach, liczbach dziesiętnych oraz wartościach logicznych. Dokument może przejść podstawową walidację XML, ale zostać odrzucony przez aplikację, która wymaga konkretnej kolejności elementów, określonych atrybutów lub ograniczeń zdefiniowanych w XSD.

Przy analizie zapytania należy sprawdzić, czy użyte nazwy elementów są prawidłowe, czy zapytanie uwzględnia przestrzenie nazw oraz czy wynik ma oczekiwany typ. Błąd może wynikać z odwołania do węzła tekstowego zamiast elementu, z użycia niewłaściwego kontekstu bieżącego w wyrażeniu XPath albo z funkcji niedostępnej w danej wersji procesora. Bez porównania dokumentu, schematu, wersji biblioteki i komunikatu błędu sama zmiana składni często tylko maskuje przyczynę.

Sprawdzanie zgodności przed wdrożeniem dokumentu XML

Rzetelna weryfikacja powinna rozpocząć się od ustalenia, jaki parser, silnik zapytań albo moduł aplikacji przetwarza dokument. Następnie sprawdza się wersję XML, kodowanie, deklarację przestrzeni nazw oraz zgodność z wymaganym XSD lub DTD. Dokument warto przetestować na danych reprezentatywnych, ponieważ prosty przykład może nie ujawnić problemów z opcjonalnymi elementami, powtarzalnymi węzłami, znakami specjalnymi i pustymi wartościami.

W środowisku diagnostycznym należy rozdzielić trzy wyniki: błąd składni XML, błąd walidacji struktury oraz błąd wykonania zapytania. Pierwszy wskazuje na niepoprawnie sformułowany dokument, drugi na niezgodność ze schematem, a trzeci na ograniczenia konkretnej implementacji lub nieprawidłową logikę odwołania do danych. Pomocne jest porównanie działającego i niedziałającego pliku, zapisanie dokładnej wersji używanego komponentu oraz odtworzenie zapytania na małym, kontrolowanym zbiorze danych. Takie postępowanie ułatwia ustalenie, czy problem wynika z treści XML, migracji do nowszej wersji programu, czy z różnic między implementacjami.

Jeżeli niezgodność XML powoduje nieprawidłową pracę aplikacji na komputerze, diagnostyka obejmuje sprawdzenie programu przetwarzającego dane, jego konfiguracji, bibliotek oraz komunikatów systemowych. W przypadku problemów ze środowiskiem użytkownika można także zweryfikować integralność instalacji i zależności wymagane przez aplikację, bez zmieniania dokumentu na podstawie przypadkowych prób. Naprawa powinna zachować zgodność z wymaganym formatem danych i potwierdzać poprawne działanie zarówno parsera, jak i zapytań używanych przez program.