Формальний запис правил, таких, що були неформально описані вище, є першою стадією визначення структури SGML документа, а саме стадією розробки специфікації типу документа (Document Type Definition, DTD). Розробляючи DTD, дизайнер може задати тільки загальну ідею документа, не описуючі конкретностей і обмежень, або навпаки, явно задати їхній усі - у залежності від призначення типу документа; як уже відзначалося, така воля була однієї з головних цілей розробки SGML. Баланс між двома цими формами досягається при компромісі між легкістю проходження простим правилам і складністю обробки реальних текстів. Один зі складних випадків - обробка вже існуючих текстів. Розроблювач найчастіше має тільки загальне поняття про призначення оригінальних текстів і тільки базові ідеї про їхню структуру. У таких випадках найчастіше задаються самі загальні текстові елементи і найбільш вільні правила з взаємної композиції. З іншого боку, при розробки нових текстів, призначення яких точно відомо, розумно задати безліч обмежень, домагаючись тим гарантованої правильності і без проблемною подальшої обробки. Прикладом, де важливий саме такий підхід, може бути підготовка інформації для різних баз даних і знань. Навіть у випадку існуючого тексту може бути корисно задати обмежуючі правила які описують деяку гіпотезу про структуру документа - це принаймні допоможе перевірити адекватність цієї гіпотези. Важливо розуміти, що будь-яка специфікація типу документа - це інтерпретація тексту тільки з якоїсь однієї сторони. Не може бути єдиної DTD, придатної на усі випадки життя, що є "абсолютною істиною", крім, можливо, DTD, тавтологічно визначальної, що "текст є текст". Однак звичайно від такий DTD мало реальної користі. Таким чином, для різних цілей можуть знадобитися різні DTD, хоча, безумовно, невелика їхня кількість буде покривати найбільш важливі і часто використовувані області.
В даний час SGML найбільше широко застосовується в областях, де схожість структури документів - найбільш важливий критерій. Наприклад, при розробці технічної документації, має велику важливість, щоб розділи і підрозділи були правильно вкладені, перехресні посилання були коректно дозволені і т.д. У таких ситуаціях документ розглядається як напівфабрикат, що перевіряється на відповідність визначеному набору правил. Однак як відзначалося раніше, навіть для більш вільних текстів має сенс явно задати різні правила, що стосуються змісти. Цим самим оброблювач позбавить себе від тривіальних помилок, що можуть проявитися тільки при наступній обробці і полегшить собі сам процес розмітки.
DTD у SGML записується як набір операторів декларації, використовуючи простий синтаксис, визначений у стандарті. Для нашої простої моделі антології, ці декларації будуть виглядати в такий спосіб:
<!ELEMENT anthology - - (poem+)><!ELEMENT poem - O (title?, stanza+)><!ELEMENT title - O (#PCDATA) ><!ELEMENT stanza - O (line+) ><!ELEMENT line O O (#PCDATA) >Ці п'ять рядків приклад формальної декларації SGML-елементів. Декларація, також як і елемент, полягає в кутові дужки; перший символ після відкриваючої дужки повинний бути знак оклику, за яким одне з невеликого набору ключових слів SGML, що визначає, який об'єкт декларується. Усі п'ять декларацій вище того самого типу: вони починаються з ключового слова ELEMENT, що показує, що визначається елемент. Кожна декларація складається з трьох частин: ім'я тега (GI) чи група імен, два символи, які описують правила мінімізації, і модель змісту. Кожна їхньої цієї частин більш докладно описується далі. Компоненти декларації розділяються символом space, яким є послідовність пробілів, табуляцій і кінців рядків.
Перша частина декларації задає GI елемента, наприклад title, poem і т.д. Можливо одночасно визначити кілька елементів; ця можливість описується нижче.
Друга частина декларації визначає те, що називається правилами мінімізації елемента. Правила мінімізації визначають, чи є необхідним явна вказівка старт- і енд-тегів при позначці елемента і записуються за допомогою пари символів, що відносяться до старт- і енд-тегу відповідно і розділених space символом. У будь-якому випадку, повинний бути заданий символ `-' (мінус), якщо тег обов'язковий, і `O' (omissible), якщо тег може бути опущений.
Таким чином, кожен елемент, крім <line> повинний мати старт-тег. Тільки елемент <anthology> повинний мати енд-тег.
Третя частина декларації, укладена в дужки, називається моделлю вмісту (content model) елемента, оскільки вона описує елементи, що можуть міститися в даному. Вміст описується в термінах інших елементах і спеціальних зарезервованих словах. Існує кілька таких слів, з яких найбільше часто зустрічається #PCDATA, що є присутнім і в прикладі. Це абревіатура для послідовності символів, і вона означає, що елемент, описаний з її допомогою, може містити будь-як припустимі символи, тобто власне вміст тексту. Якщо розглядати специфікацію структури як дерево відносини елемент-вміст (мал. 2), що має одну кореневу вершину (у нашому випадку, <anthology>) і проміжні вершини (<poem>, <stanza>, ...), то листами цього дерева майже у всіх випадках будуть #PCDATA.
Рис. 2 Дерево відносини елемент-вміст
У нашому випадку в такий спосіб задані <title> і <line>. Оскільки їхня модель умісту містить тільки #PCDATA, те вони не можуть містити інших вкладених елементів.
При завданні моделі вмісту, а в деяких випадках і при вказівці імен тегов,що декларуються, використовуються оператори, подібні з операторами, використовуваними для завдання регулярних виражень. Далі описуються їхні функціональні групи.
Декларація елемента <stanza> у прикладі вище вказує, що строфа складається з однієї чи більш рядка. Оператор повторення `+' (плюс) указує цей факт. Синтаксис SGML містить три операторів повторення:
Таблиця 7 Оператори повторення SGML
| Символ оператора повторень | Зміст оператора |
| ? | Попередній елемент опціонален, тобто може повторюватися 0 чи 1 раз |
| * | Попередній елемент може повторюватися 0 і більш раз |
| + | Попередній елемент може повторюватися 1 і більш раз |
Як приклад, декларація для <poem> задає, що даний елемент не може мати більш одного <title>, але може не мати взагалі; і те, що він повинний містити принаймні один елемент <stanza> і може містити трохи.
Модель умісту (title?, stanza+) містить більш одного елемента і тому додатково необхідно вказати порядок їхньої появи. Цей порядок визначається оператором угруповання `,' (кома), що вказується між компонентами. Існує три можливих оператора угруповання:
Таблиця 8 Оператори групування SGML
| Символ оператора угруповання | Зміст оператора |
| , | Компоненти повинні випливати в порядку, заданому в моделі вмісту |
| & | Обидва компоненти повинні бути присутнім, але можуть випливати в будь-якому порядку |
| | | Тільки один з компонентів може з'явиться усередині описуваного елемента |