Czym jest SGML i dlaczego warto go poznać
SGML, czyli Standard Generalized Markup Language, to międzynarodowy standard ISO (ISO 8879:1986) definiujący meta-język do tworzenia języków znacznikowych. Tak, dobrze przeczytałeś — SGML nie jest po prostu kolejnym markup language. To język do definiowania innych języków markup. HTML, XML, XHTML, DocBook, TEI — wszystkie one wywodzą się z SGML lub są przez niego inspirowane.
Dlaczego warto znać SGML w 2026 roku? Bo zrozumienie SGML to jak zrozumienie teorii względności przed nauką mechaniki newtonowskiej. Nagle widzisz, dlaczego HTML zachowuje się tak, a nie inaczej. Dlaczego XML ma taką składnię. Dlaczego pewne decyzje w web standards mają sens, a inne wyglądają jak historyczne bagaże. SGML jest kluczem do zrozumienia całego drzewa genealogicznego markup languages.
W praktyce SGML był używany głównie w dużych organizacjach: wydawnictwach, instytucjach rządowych, przemyśle lotniczym i obronnym. Jeśli kiedykolwiek pracowałeś z dokumentacją techniczną w formacie ATA (Air Transport Association) albo z dokumentami wojskowymi w standardzie MIL-STD, to prawdopodobnie pod spodem był właśnie SGML.
Krótka historia i ewolucja
Historia SGML zaczyna się w latach 60., kiedy Charles Goldfarb, Edward Mosher i Raymond Lorie pracowali w IBM nad systemem do zarządzania dokumentami prawnymi. Ich projekt, GML (Generalized Markup Language — tak, nazwa pochodzi od inicjałów twórców, nie od “general”), był pierwszą próbą stworzenia uniwersalnego systemu opisywania struktury dokumentów niezależnie od ich prezentacji wizualnej.
Goldfarb, który jest powszechnie uznawany za ojca SGML, przeniósł idee GML na poziom standardu międzynarodowego. Po latach pracy w komitetach ISO, w 1986 roku opublikowano ISO 8879 — oficjalny standard SGML. Był to moment przełomowy, bo po raz pierwszy świat miał ustandaryzowany sposób na opisywanie struktury dokumentów w sposób przenośny i niezależny od konkretnego oprogramowania.
Ewolucja SGML to w dużej mierze historia jego uproszczeń. Pełny SGML jest potwornie skomplikowany — specyfikacja obejmuje setki opcji i wariantów, a implementacja pełnego parsera SGML to projekt na wiele miesięcy. Dlatego w 1989 Tim Berners-Lee stworzył HTML jako uproszczony profil SGML (choć z wieloma odstępstwami od standardu), a w 1998 W3C opublikowało XML jako “SGML dla webu” — drastycznie uproszczoną wersję, która zachowała najlepsze idee SGML, ale pozbyła się większości złożoności. Można powiedzieć, że XML to SGML po detoksie.
Kluczowe cechy i filozofia
Podstawowa filozofia SGML to separacja treści od prezentacji. Dokument SGML opisuje co coś jest (tytuł, akapit, lista, przypis), a nie jak ma wyglądać. To podejście było rewolucyjne w latach 80., kiedy większość systemów do edycji tekstu (WordStar, WordPerfect) myślała o dokumentach w kategoriach wizualnych — pogrubienie, czcionka, rozmiar. SGML mówił: najpierw zdefiniuj strukturę, potem martw się o wygląd.
Centralnym konceptem SGML jest DTD — Document Type Definition. DTD to formalna definicja struktury dokumentu: jakie elementy są dozwolone, w jakiej kolejności, jakie atrybuty mogą mieć, które są wymagane, a które opcjonalne. DTD jest pisane w specjalnej składni i działa jak schema — parser SGML może automatycznie walidować dokumenty na podstawie DTD. Ten sam koncept przeżył później w XML DTD, XML Schema i Relax NG.
SGML wprowadza też koncept krótkich referencji (short references), tag omission (opcjonalne zamykanie tagów — brzmi znajomo z HTML?), i CONCUR (współistniejące struktury drzewa w jednym dokumencie). Niektóre z tych cech były potężne, ale większość z nich sprawiała, że parsowanie SGML było koszmarem implementacyjnym. Parser SGML musiał obsługiwać tyle wariantów i wyjątków, że pełna, zgodna ze standardem implementacja była rzadkością.
Kolejną ważną cechą jest entity system — mechanizm pozwalający definiować reużywalne fragmenty treści, odwoływać się do zewnętrznych plików i tworzyć makra. Jeśli kiedykolwiek używałeś & w HTML albo definiowałeś entities w XML, to korzystasz z uproszczonej wersji tego systemu. Pełny SGML pozwalał na znacznie więcej, w tym na warunkowe dołączanie treści i parametryzowane entities.
Gdzie SGML sprawdza się najlepiej
SGML był najsilniejszy w środowiskach, gdzie dokumenty były duże, złożone i musiały przetrwać dekady. Wydawnictwa akademickie używały go do składania książek i czasopism. Przemysł lotniczy przyjął SGML jako standard dokumentacji technicznej (ATA Spec 2100) — kiedy kupujesz samolot za 100 milionów dolarów, chcesz mieć pewność, że dokumentacja serwisowa będzie czytelna za 30 lat, niezależnie od tego, jakie oprogramowanie będzie wtedy dostępne.
Rząd USA był jednym z największych użytkowników SGML. Departament Obrony wymagał dokumentacji w formacie SGML dla wielu kontraktów (standard CALS — Computer-aided Acquisition and Logistics Support). Kongres USA używał SGML do legislacji — słynny system Thomas, który udostępniał teksty ustaw online, bazował na SGML.
Dzisiaj SGML w czystej formie jest praktycznie nieużywany. Został zastąpiony przez XML i jego pochodne. Ale jeśli trafisz na archiwalne systemy dokumentacji w dużych organizacjach — bibliotekach narodowych, agencjach kosmicznych, korporacjach lotniczych — możesz natknąć się na dokumenty SGML, które nadal są w użyciu. Konwersja tych zasobów do nowszych formatów to osobna nisza zawodowa.
Jak wygląda kod w SGML
Przykład prostego dokumentu SGML z DTD:
<!DOCTYPE artykuł SYSTEM "artykul.dtd">
<artykuł>
<nagłówek>
<tytuł>Wprowadzenie do znaczników semantycznych</tytuł>
<autor imię="Jan" nazwisko="Kowalski">
<afiliacja>Uniwersytet Warszawski</afiliacja>
</autor>
<data>1995-03-15</data>
</nagłówek>
<treść>
<sekcja>
<tytuł-sekcji>Czym są znaczniki?</tytuł-sekcji>
<akapit>
Znaczniki to strukturalne metadane osadzone w tekście,
które opisują rolę poszczególnych fragmentów dokumentu.
</akapit>
<lista typ="numerowana">
<element>Pierwszy punkt listy.</element>
<element>Drugi punkt listy.</element>
</lista>
</sekcja>
</treść>
</artykuł>
I odpowiadające mu DTD:
<!ELEMENT artykuł - - (nagłówek, treść)>
<!ELEMENT nagłówek - - (tytuł, autor+, data)>
<!ELEMENT tytuł - - (#PCDATA)>
<!ELEMENT autor - - (#PCDATA, afiliacja?)>
<!ATTLIST autor
imię CDATA #REQUIRED
nazwisko CDATA #REQUIRED>
<!ELEMENT treść - - (sekcja+)>
<!ELEMENT sekcja - - (tytuł-sekcji, akapit*, lista*)>
<!ELEMENT akapit - - (#PCDATA)>
<!ELEMENT lista - - (element+)>
<!ATTLIST lista typ (numerowana|punktowana) "punktowana">
Zwróć uwagę na - - w definicjach elementów — to flagi tag omission mówiące, że zarówno tag otwierający, jak i zamykający są wymagane. #PCDATA oznacza parsed character data (zwykły tekst). + oznacza “jeden lub więcej”, ? oznacza “zero lub jeden”, * oznacza “zero lub więcej”. Ta składnia DTD przetrwała niemal bez zmian w XML.
Ekosystem i narzędzia
W czasach swojej świetności SGML miał bogaty, ale drogi ekosystem. ArborText (później przejęty przez PTC) produkował Author/Editor — jeden z najpopularniejszych komercyjnych edytorów SGML. OmniMark był potężnym językiem przetwarzania dokumentów SGML, używanym w wydawnictwach do transformacji i publikacji. OpenSP (i jego predecessor SP, autorstwa Jamesa Clarka) był referencyjnym parserem SGML — open-source i szeroko używany.
Warto wspomnieć o narzędziu o nazwie sgmls — prostym parserze SGML, który konwertował dokumenty na strumień zdarzeń (podobnie jak SAX dla XML). Wiele pipeline’ów przetwarzania dokumentów bazowało na sgmls jako pierwszym etapie.
Dzisiaj ekosystem SGML jest praktycznie martwy. Nie znajdziesz pluginów do VS Code dla SGML, nie ma LSP servera, nie ma aktywnych community. Najbliższym żyjącym krewnym ekosystemu SGML jest świat XML — narzędzia jak Oxygen XML Editor potrafią pracować z DTD i schema, co jest najbliższe doświadczeniu pracy z SGML, jakie możesz dzisiaj mieć.
Mocne i słabe strony
Mocne strony SGML to jego potęga ekspresji. Możesz zdefiniować dowolnie złożoną strukturę dokumentu, z pełną walidacją, entities, notacjami i konkurowającymi drzewami. Separacja treści od prezentacji jest fundamentalna i wymuszona przez sam standard. Dokument SGML sprzed 40 lat jest nadal parsowalny dzisiaj, jeśli masz DTD — to prawdziwa długowieczność danych.
Słabe strony? Złożoność. Pełna specyfikacja SGML to ponad 150 stron gęstego tekstu technicznego z setkami opcji konfiguracyjnych. Implementacja pełnego parsera SGML to projekt, którego podejmowało się bardzo niewielu. James Clark (autor SP/OpenSP i później współtwórca XML) był jednym z nielicznych, którzy naprawdę rozumieli pełną specyfikację. Większość “parserów SGML” w praktyce obsługiwała podzbiór standardu.
Kolejny problem: SGML nie był zaprojektowany dla sieci. Nie miał natywnego wsparcia dla hyperlinków (to zostało dodane później jako HyTime), nie miał koncepcji encodingu znaków w sposób, który byłby naturalny dla internetu, i nie miał prostego sposobu na integrację z protokołami webowymi. Kiedy web eksplodował w latach 90., SGML był zbyt ciężki, zbyt skomplikowany i zbyt nastawiony na druk, żeby nadążyć.
Podsumowanie
SGML powinieneś poznać, jeśli interesuje Cię historia technologii webowych, pracujesz z legacy systemami dokumentacji, albo chcesz naprawdę głęboko zrozumieć, dlaczego XML i HTML wyglądają tak, jak wyglądają. To nie jest język, którego nauczysz się w weekend i zaczniesz używać w codziennej pracy — ale to jest język, którego zrozumienie uczyni Cię lepszym inżynierem.
Przyszłość SGML to dziedzictwo, nie rozwój. Standard jest stabilny od 1986 roku i taki pozostanie. Ale idee, które SGML wprowadził do świata — deklaratywny markup, separacja struktury od prezentacji, walidacja przez schemę — są żywe i mają się dobrze w każdym nowoczesnym formacie dokumentów. Kiedy następnym razem napiszesz <div class="article">, pamiętaj, że ktoś w IBM wymyślił ten koncept pół wieku temu.
