O tym, że walidacja danych wejściowych jest istotna, pisałem już wiele razy. Tym razem będzie o XML.
Walidacja danych - dlaczego XSD jest puszysty
Od lat XML zyskuje coraz większą popularność, co jest prawdą, choć mówienie wciąż o "zyskiwaniu większej popularności" zaczyna mnie już śmieszyć. W przypadku aplikacji internetowych można wspomnieć choćby o SOAP. Często też pliki XML zawierają dane wejściowe do aplikacji, lub parametry wywołania metod są reprezentowane za pomocą XML.
Jedną z przewag XML nad (na przykład) HTML jest fakt, że dane reprezentowane w tym formacie mają jasno określoną strukturę, a przynajmniej takie jest założenie. Oczywiście, można generować XML "z ręki" otrzymując na wyjściu coś, co wygląda jak XML. Zamiast tego lepiej jest jednak poświęcić trochę czasu i "opisać" strukturę (schemat) pliku w sposób zrozumiały dla parserów XML. Formatów opisu jest kilka, między innymi DTD oraz XSD.
XSD jest nowszym rozwiązaniem w stosunku do DTD, pod wieloma względami bardziej rozbudowanym. W szczególności odnośnie walidacji danych, które w dokumencie XML mogą być zawarte. Przykładowo tworząc prosty plik XML zawierający imiona, nazwiska oraz daty urodzenia osób (taki typowy, trywialny przykład) można założyć, że:
- imię i nazwisko zawierają określony zakres znaków,
- data urodzenia jest datą w określonym formacie,
Określony zakres znaków to oczywiście wszystkie litery, ale również mogą trafić się znaki typu - ' czy spacja, nie należy jednak spodziewać się, że ktoś w nazwisku będzie miał znaki typu | > < czy ?. XSD pozwala wraz z definicją elementów odpowiadających w pliku XML zdefiniować dopuszczalny ich format. Więcej szczegółów oczywiście u źródła: W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes.
Co to daje? Zakładając, że plik XML jest wejściem do aplikacji, można wykorzystać walidatory XML w celu zweryfikowania nie tylko poprawności struktury pliku XML, ale również zawartych w nim danych. Bardzo ładne, scentralizowane podejście do walidacji danych.
