Lepsze wrogiem dobrego

W3C pracuje obecnie nad standardem XML 1.1, czyli nad nową wersją podstawowych zasad zapisu danych, mającą zastąpić używany obecnie standard XML 1.0. Tak zwany "Working Draft" powstał dawno - w grudniu 2001. Jedną ze zmian jest wprowadzenie pełnych "nazw" Unicode w nazwach elementów (a co za tym idzie - w schemacie) oraz obsługa Inicode. Doprawdy, trudno dojść, jaki cel przyświecał W3C we wprowadzaniu tej zmiany. Tak naprawdę dane i tak można zapisać w formacie Unicode, ale w nazwach elementów czy atrybutów - praktycznie wszyscy używają języka angielskiego - tak jest wygodniej.

Formalnie, zmiany w XML 1.1 są niby nieznaczne. Po pierwsze, pojawia się obsługa nowszych wersji Unicode. Niestety, to wprowadza dodatkowy wymóg, by pewne znaki były "poprzedzane" prefiksami. Ponieważ XML 1.0 tej możliwości nie miał, taki format nie będzie mógł być zrozumiany przez parsery stworzone dla XML 1.0. Równocześnie standard dopuszcza pomijanie informacji o wersji dokumentu w deklaracji processing instruction na początku dokumentu XML. W konsekwencji trudne jest (bez analizy całego pliku) sprawdzenie, czy to jest dokument XML 1.0, czy 1.1. Czy o to właśnie chodziło?

Z tych wszystkich powodów (a także ze względu na fakt, że standard z 2002 r. jeszcze nie ma tak naprawdę przemysłowej implementacji) można zastanawiać się, czy XML 1.1 nie podzieli losów SQL 3 - martwego standardu określającego "kolejną" generację kwerend SQL.

Binarna ślepa uliczka

Pierwszą firmą, która poinformowała, że pracuje nad binarnym standardem XML, był Borland - było to przy okazji ogłaszania C++ Builder 6. Potem temat zaniknął, by pojawić się w pracach Sun Microsystems w lipcu 2004 r. Obecnie są dostępne pierwsze testowe parsery i biblioteki do pracy z "binarnym" XML.

Rozwiązanie nazwane FastInfoSet opiera się na koncepcji XML InfoSet. Jego twórcy zakładają, że ten dokument będzie analogiczną strukturą co dokument XML-owy, a jedynie jego postać będzie inna. Rozwiązanie ma działać w taki sposób, by można było łatwo zastosować FastInfoSet, tam gdzie jest potrzebny mniejszy rozmiar plików i większa wydajność przetwarzania.

Warto zadać sobie pytanie, czy na pewno jest to dobra droga? Proszę zauważyć, że prosty tekst ujęty w struktury XML-owe będzie zawsze zajmować znacznie więcej pamięci niż sama informacja. Tylko że dzięki tym dodatkowym informacjom komputer jest w stanie określić, jaką rolę pełni dany fragment.

Z przykładu FastInfoSet oczywiste jest, że: <cbc:Name>Jerry Builder plc</cbc:Name> jest dłuższe niż 68696c6c20576f72. Niby racja, ale przecież wynik mógłby być jeszcze krótszy, gdy strony umówią się, że nazwa będzie zapisywana od bajtu 12 do 23 (zapis pozycyjny), a cały plik będzie dodatkowo skompresowany konkretnym algorytmem dobranym pod kątem zawartości dokumentu. Zwięzły zapis, szybka transmisja, a i sam proces parsowania bez porównania wydajniejszy.

Twórcy FastInfoSet proponują użycie ASN.1 do kodowania binarnego. ASN.1 jest używany w wielu protokołach - SNMP, X.509 (którym m.in. przesyłane są dokumenty EDIFAC) czy LDAP. Samo ASN.1 jest określane jako najgorszy binarny sposób zapisu, ale - z różnych powodów - jest używany w wielu rozwiązaniach. Dla porównania, wiele protokołów opisywanych w RFC, czyli rozwijanych w ramach IEFT, jak FTP, itp. używa prostszych mechanizmów. To, że są one mniej wyrafinowane, oznacza m.in. to, że są mniej podatne na błędy.

Cała siła XML tkwi w tym, że znacznik otaczający daną informację niesie pewne dodatkowe metadane, które pozwalają sprawdzić poprawność formatu itp. Twórcy FastInfoSet chcą te cechy XML przenieść do formatu binarnego, tak by również w jego przypadku można było decydować o transformacjach, definiować schemat dokumentu itp. Niby rozsądne, ale spójrzmy na konsekwencje.

Ciąg dalszy artykułu znajduje się w Internecie pod adresem https://www.computerworld.pl/archiwum