SGML to bazowa klasa dla języków/standardów bazujących na specyficznym sposobie zapisu znanym z plików GML, XML, ale też i HTML. Tyle że XML to uproszczona wersja SGMLa. Można powiedzieć, że SGML to podstawa, które w swoim założeniu ma obsługiwać różne przypadki (i nie mówimy tutaj o wyłącznie zastosowania geodezyjnych), a XML to koncepcja, która ma ułatwiać tworzenie łatwo przetwarzalnych, ustandaryzowanych formatów.
np. HTML bazował na SGMLu, ale od wersji 5.0 wg niektórych źródeł stracił tę kompatybilność.

Jeśliby popatrzeć na pliki bazujące na SGML lub XML to zdecydowana większość plików jest kodowana wg koncepcji xml (GML jest również na nich oparty).

Wracając do geodezji... żeby było śmiesznie, GML jest podstawą, językiem bazowym do zastosowań mapowych/geograficznych/geodezyjnych. Natomiast to co jest u nas nazywane GML to są konkretne implementacje do zastosowań, np. EGIB BDOT..itd. Jak opracowywałem aplikacje związane z ARiMR, to oni również z jednej strony mieli pliki XML, z drugiej GML, ale w sumie oparte właśnie o GML-a. Sporo aplikacji potrafi np. zapisywać swoje ustawienia lub projekty w plikach typu XML (nawet Googlowy KML jest xmlem).

Tak więc samo rozszerzenie/nazwa formatu czy to XML/GML tak naprawdę nie wyjawia nam pełnej natury pliku. Liczy się to co jest w środku - czyli deklaracje, z jakich dany plik ma korzystać standardów. Czyli jakie typy obiektów/elementów, słowniki..itd

Natomiast wysyp różnych formatów jest związany z tym, iż:
1) dużo formatów dla danych aplikacji powstało, zanim XML/GML stał się popularny. Natomiast dostosowywanie aplikacji, aby wywalić "natywny" format i zastąpić go XML/GML jest .. hmm.. nie dość że nieopłacalne to jeszcze może generować problemy, bo...

2) ...każda aplikacja ma jakiś zestaw danych na jakich pracuje. Wydaje się, że możnaby zawsze mapować te dane 1:1 pamięć - plik, ale to nie jest zawsze możliwe. Plik tekstowy jakim jest XML/GML nie jest specjalnie wydajny do ciągłej pracy (tj. jak importujemy i eksportujemy jest OK, ale jeśli np. mielibyśmy prowadzić ciągłą edycję i zapis musiałyby być częsty, to przy dużym pliku długi zapis utrudniałby pracę).
Dlatego np. do XML/GML wypisuje się rzeczy najważniejsze z punktu widzenia wymiany danych, a resztę (np. statystyki, cache, dodatkowe opisy) przechowuje się w natywnym formacie, najlepiej binarnym, często bazodanowym (np. DWG, SHP/SHX, MJF, TSJ, DB..itd).

3) wprowadzenie pełnej obsługi danego formatu zazwyczaj wymaga dysponowania nie tylko specyfikacją, ale też i oficjalnymi przykładami (akceptowanymi). bez tego implementacja specyfikacji to ślepa uliczka - u jednych będzie działać, na jednych przypadkach tak, na innych nie. Tu nie ma prawa być większych niejednoznaczności.

Teoria nie wystarczy musi być praktyka i testy. Te przykłady to właśnie praktyka.

Jeśli więc np. projektanci GMLa do zastosowań w geodezji byliby profesjonalni i chcieliby zapewnić jak najmniej problemów przy wdrażaniu formatu, musieliby zapewnić jednoznaczne narzędzia do walidacji, przykłady i potrafić wyjaśniać problemy w zapisie (np. co do zapisu konkretnych sytuacji, które np. nie były przewidziane w przykładach załączonych do standardu).
Takie walidatory i testy oczywiście powinny być dostępne zarówno dla każdego opracowującego format, jak i we wszystkich ośrodkach, jakie mają wspierać GML-a. Ponieważ byłaby to informacja publiczna - musiałyby być dostępne BEZPŁATNIE - w końcu kasa na tworzenie poszła z naszych podatków, więc wypadałoby w końcu wywiązać się z obowiązków.

Wtedy producenci oprogramowania mieliby jasną sytuację - i łatwo byłoby sprawdzić, czy dane oprogramowanie faktycznie jest zgodne z GUGiKowym GMLem czy też nie. Geodeta mógłby przed wydaniem do ośrodka sprawdzić plik i jeśli byłby zgodny - ośrodek musiałby go przyjąć. Byłoby to jasne i oczywiste, i co ważniejsze, geodeta nie stałby na straconej pozycji, jak teraz, gdy musi zaopatrzyć się w odpowiednie oprogramowanie, bo akurat dany ośrodek pracuje na XXX, a on ma soft YYY.








pozdrawiam

Marek

kolar1 Napisał(a):
-------------------------------------------------------
> Dzięki za rzeczowe wyjaśnienie. Ten DXF to podałem
> jako przykład bo nie znam się zbytnio na tych
> rozszerzeniach. Tyle tego w ostatnich czasach
> powstało że ciężko stwierdzić który jest
> najlepszy.
> Akurat z XML miałem stycznośc i potwierdzam że
> jest bardzo uniwersalny. Mam jeszcze pytanie bo
> widzę że siedzisz w temacie.
> Czy poprzednik XML, czyli SGML, ma coś wspólnego z
> obecnie przyjętym GML?
>



Zmieniany 1 raz/y. Ostatnio 2015-01-17 22:07 przez skyraster.