[ Webmaster - czerwiec 2000 | Strona główna Webmastera ]

Namespaces in XML

Zagwozdka

Marcin Jagodziński

Proces tworzenia nowych specyfikacji dotyczących XML został wstrzymany przez konsorcjum W3 - taka informacja pojawiła się na liście XML-DEV, skupiającej czołowych twórców aplikacji XML-owych. Informacja ta, zamieszczona przez anonimowego użytkownika i podpisującego się jako "Pope 32767", wywołała szok i zamieszanie. Po krótkim czasie została ona oficjalnie potwierdzona.

XML to obecnie jedna z najmodniejszych technologii. Zagrożenie dla jej dalszego rozwoju, lub choćby spowolnienie go, byłoby poważnym problemem dla największych świata IT, a także dla tysięcy użytkowników rozmaitych rozwiązań na XML-u opartych. Co więc się stało?

Gdy w 1998 roku ogłoszono specyfikację standardu XML, od razu było wiadomo, że nie skończy się na tym jednym dokumencie. W3C prowadziła i prowadzi nadal prace nad wieloma specyfikacjami "wokółXMLowymi". Jedną z pierwszych spośród nich, rozwiązującą bardzo ważny dla programistów problem, była specyfikacja "Namespaces in XML", ogłoszona na początku 1999 roku.

Czym są przestrzenie nazw, wie każdy programista. W XML-u także istnieje potrzeba ich wprowadzenia. Jak bowiem wiadomo, XML umożliwia definiowanie własnych elementów (zwanych - nie do końca poprawnie - tagami). Oznacza to, że każdy twórca dokumentu XML może określić, formalnie (za pomocą DTD) lub nieformalnie, że w jego dokumentach będzie występował np. tag , oznaczający, powiedzmy, autora książki. Inna osoba czy firma może wprowadzić do swoich dokumentów taki sam tag , ale w innym znaczeniu. Na przykład może on oznaczać osobę wystawiającą fakturę. W jednym dokumencie mogą więc się znaleźć dwa tagi mające zupełnie inne znaczenia (jeżeli jest to np. faktura za książkę). Istnieje konieczność ich rozróżnienia.

W językach programowania stosuje się różne podejścia do przestrzeni nazw. W Perlu programista "zamyka" tworzone przez siebie nazwy zmiennych w pakietach, pakietom tym nadając dowolne nazwy. Pełna nazwa zmiennej składa się z jej nazwy, poprzedzonej nazwą pakietu. Oczywiście rozwiązanie to nie zapobiega kolizjom: dwóch programistów może identycznie nazwać pakiety, a wewnątrz nich użyć tych samych zmiennych. W praktyce, dzięki istnieniu centralnej biblioteki modułów CPAN, sytuacje takie należą do rzadkości: zawsze można sprawdzić, czy nazwa nie została już zajęta. Sun, tworząc język Java, zastosował bezpieczniejszą metodę: zalecił, by nazwa pakietu była taka sama jak nazwa domeny firmy/organizacji pakiet tworzącej (ale pisana wspak np. pl.com.firma.nazwa_pakietu).

W3C postanowiło nie uzależniać możliwości tworzenia przestrzeni nazw od posiadania własnej domeny. W końcu XML jest technologią "demokratyczną". Specyfikacja "Namespaces" proponuje, by nazwą przestrzeni był adres internetowy URI. Czym jednak jest URI? Gdzie prowadzić ma ten adres i co ma się pod nim znajdować? Odpowiedź na dwa ostatnie pytania brzmi: "nie wiadomo". Teoretycznie może być to URI prowadzący donikąd. Już samo to prowadziło do wielu kontrowersji. Wiele osób uważało, że pod adresem URI będącym nazwą przestrzeni nazw powinien się znajdować schemat składniowy dokumentu (na przykład w formie DTD). I wiele rozwiązań używa takiego skojarzenia: przestrzeń nazw = schemat dokumentu. Zachęca do tego na przykład specyfikacja RDF.

URI jest nadzbiorem zawierającym URL-e (czyli adresy zawierające "typową" metodę dostępu do zasobu w swej nazwie) oraz adresy względne. I właśnie w adresach względnych tkwi sedno problemu. Oto specyfikacja "Namespaces" stwierdza, że nazwy to po prostu URI, a w innym miejscu, że dwa URI są identyczne, gdy są po prostu takie same, porównane literalnie, znak po znaku. Ale dwa różne (w sensie zapisu) mogą się rozwijać do tego samego adresu. Np. "katalog" może być tożsamy z "http://www.serwer.com/katalog".

Największy problem stanowi to, że rozmaite narzędzia przyjmowały jedno lub drugie rozumienie nazw. Wiadomo na przykład, że niektóre aplikacje Microsoftu używają relatywnych URI do odszukiwania schematów dokumentów. Z drugiej strony, inne aplikacje porównują URI litera po literze. Najprościej byłoby zabronić używać adresów względnych. Problem nie w tym, że w niektórych zastosowaniach są one użyteczne. To dałoby się jeszcze przeboleć. Gorzej, że rozwiązania, na które wydano miliony dolarów, stałyby się nagle niezgodne z XML.

Trudno powiedzieć, kiedy należy się spodziewać rozstrzygnięcia problemu, który, choć wydaje się drobny, ma wcale niemały wymiar finansowy. Jak się okazało, zanim sprawa wyszła na jaw, dla jej rozpatrzenia zebrało się plenum W3C. Nie doszło jednak do żadnego konsensusu. Tim Berners-Lee, szef W3C uchyla się od podjęcia arbitralnej decyzji, stwierdzając, że sprawa jest zbyt poważna. Pojawiła się, jak mówią programiści, "pluskwa", w wielu, bardzo wielu aplikacjach, tworzonych przez największe firmy, takie jak Sun, Microsoft, Oracle czy IBM. Jej neutralizacja może oznaczać bolesną (dla jednych bardziej, dla innych mniej - w zależności od rozstrzygnięcia) kurację. Zmianie może ulec nie tylko specyfikacja przestrzeni nazw, ale także inne: RDF, DOM, XPath, Schema. Od nich zaś zależą kolejne specyfikacje - mamy tu więc efekt domina. Jak W3C wybrnie z tej sytuacji? Stawką jest w niej przecież także pozycja tej zasłużonej organizacji.

Remedium

W dyskusjach pojawiły się trzy możliwe sposoby rozwiązania problemu: