Niechlujni czy może chlujni?

Różnice w kolejnych wersjach modelu podstawowego wynikają z kilku przyczyn o różnym charakterze: redakcyjnym, edycyjnym czy merytorycznym. Cześć z tych różnic wzięła się ze zwykłego przeoczenia czy błędów ludzkich (tzw. literówki), np. zamiast „wyciągZKW” powinien być „wyciagZKW” czy zamiast „wykonwaca” powinien być „wykonawca”. Zarówno na etapie tworzenia projektu, jak i potem – na etapie prac legislacyjnych – dużo takich problemów zostało wychwyconych. To jest, niestety, sytuacja normalna podczas pisania jakichkolwiek tekstów, tym bardziej tekstów tak skomplikowanych technicznie i redakcyjnie. Każda informacja o tego typu problemach była i jest inwentaryzowana. I jeśli może mieć istotny charakter, będzie oczywiście korygowana.

Sporo zamieszania wywołał stereotyp voidable. Dla przypomnienia: stosuje się go w przypadku atrybutów wymagalnych (taki atrybut w bazie danych musi zostać wypełniony wartością), co do których mamy podejrzenie, że może w niektórych przypadkach brakować dla nich danych. Został on zapisany w XSD, a w praktyce okazało się, że zapis w XSD nie jest zły czy błędny, ale w niektórych przypadkach nie jest wystarczający, tzn. wcześniejszy sposób zakodowania voidable w XSD spełniał wymagania i był prawidłowy dla wszystkich przypadków oprócz list wyliczeniowych. Zapis został poprawiony. Zmiana ta wywołała konieczność jeszcze kilku innych korekt. Bardzo podobnie sytuacja wygląda np. w przypadku zmiany typów ReferenceType na PropertyType. Pytanie: czy byliśmy rzeczywiście tak bardzo niechlujni?

Inny rodzaj zmian. Czasem są, a czasem nie ma definicji klas, atrybutów w schematach XSD. Są one umieszczane w częściach oznaczonych jako annotation i documentation. Części schematów oznaczone tymi znacznikami są traktowane jako informacyjne i pomijane podczas weryfikacji plików XSD za pomocą walidatorów. To, czy te informacje są, czy ich nie ma, nie wpływa na merytoryczną zawartość schematów XSD. Dlaczego więc w pewnym momencie z tych definicji zrezygnowaliśmy? Uznaliśmy, że umieszczanie ich powoduje tylko wzrost pojemności schematów, a nie ma żadnego znaczenia merytorycznego.

Większość zmian powstała w wyniku zauważonych przez nas niedociągnięć (jak w przypadku voidable, nie traktujemy tego jako poważnego błędu) lub jest naszą reakcją na uwagi różnych życzliwych osób, instytucji czy firm (dziękujemy za te uwagi) albo dotyczą korekty literówek, spacji itp. Od momentu przesłania modelu do konsultacji czekaliśmy na takie uwagi, reagowaliśmy na nie i czekamy nadal, bo to pozwoli opracować lepsze modele. Nikt nie jest doskonały. Powinni to wiedzieć zwłaszcza ci, którzy przysyłają do GUGiK pliki GML do weryfikacji i ciągle jest „troszkę nie tak”.

Natomiast takie dogłębne analizy, jaką przedstawił na Geoforum.pl Waldek Izdebski („Modele podstawowe – takie same, a jednak różne”), są cenne, choć lekko spóźnione, zwłaszcza że my te zmiany wprowadziliśmy i są one wynikiem naszej reakcji na różne uwagi. W tak „poważnej” analizie wypadałoby, oprócz pokolorowania różnic (co, jak rozumiemy, wyczerpało możliwości autora) umieścić parę wyjaśnień, tzn. które różnice są bardzo poważne i pociągają za sobą równie poważne konsekwencje oraz konieczność zmiany dużej części oprogramowania, a które różnice są, z praktycznego punktu widzenia, nieistotne i często wynikają z przyjętych rozwiązań implementacyjnych. Byłoby to szczególnie cenne, ponieważ języki UML i GML ciągle jeszcze dla bardzo wielu geodetów są nowością.