|
|
![]() |
Архив | ![]() |
![]() |
![]() |
14 июня. SGML | ![]() |
![]() |
1999
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() 1998 ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
![]() |
В начале был SGML SGML (Standard Generalized Markup Language) - Стандарт ISO 8879, предложенный сотрудником IBM Чарльзом Ф. Гольдфарбом в 1974 и опубликованный в 1986 году. Это во многих отношениях замечательный и достаточно удивительный документ. Он предлагает описание структуры (электронного) документа. Поэтому широко распространенное в России мнение, будто SGML - метаязык, или язык конструирования языков разметки - неверно. А из этого вытекает несколько важных выводов. Давайте разберемся. Сначала - несколько слов о том, зачем это нужно. Технические стороны вопроса замечательно изложены в уже классической статье Б. Тоботраса (БТ), но нас интересуют принципы (principies), то есть начала. Что такое электронный документ? А что такое документ вообще? В художественой литературе ХХ века встречаются произведения, построенные как неструктурированный поток сознания. Выглядят (или выглядели) они к моменту свое появления как новаторство. Новаторство это сомнительное. Впервые структурированные документы появляются в западной цивилизации только в XIII веке, в работах схоластов - например, св. Фомы. До схоластов не было списков, не было "содержаний" (или "оглавлений"), самого разбиения на главы - и того не было. Недаром готика считается искусством классификации и компендиумов - сводов знаний. Сложно представить себе цивилизацию, не использующую структурный подход к созданию документа, однако это было не так уж давно. Напротив, в TEXе современный подход жестко вшит в саму программу, как составная часть (и даже вместе с оформлением, что есть перегиб на местах). Почему? Потому, что мы в веке ХХ не можем мыслить себе документа без его структуры. В упоминавшихся литературных экспериментах легко видеть автора, лирического героя и читателя текста, и т.д. Попробуйте подумать о каком-нибудь тексте, отвлекшись от его структуры. Останется... не знаю, что останется, но текст - пропадет. Вне структуры о тексте может думать я знаю кто - модем, тупо дующий в трубу поток байтов. А наша задача - хранение, модификация и распространение больших объемов информации, т.е. больших объемов текстов. Мы (уже) думаем о тексте в терминах его структуры. Значит, мы хотим думать об этом ясно. Мы знаем, что читатель будет воспринимать текст структурно. Значит, мы хотим управлять этим процессом эффективно. Все, больше никаких причин использовать SGML нет. Как мы дошли до жизни такой? С появлением электронной формы хранения документов (и даже, наверное, раньше, с появлением) электронной формы передачи документов - я имею в виду телеграф) проявилась проблема преобразования документа из одной формы в другую. И проблема корректности такого преобразования. Все помнят еще времена, когда текст, набранный в IBM, был недоступен в Макинтоше. Но ведь когда мы посылаем письмо на бумаге, или открытку с картинкой по почте, наш адресат получает в точности то, что мы отослали, и никаких проблем не возникает? Почему же они возникают в электронном формате? Можно ведь поступать по аналогии с бумагой и пересылать и хранить документы в RTF или Adobe Acrobat'e? Нельзя. Отсутствие проблем с бумагой - иллюзия. Ваша открытка, полученная китайцем, может быть им и не прочитана. А ваша открытка, посланная русалке, размокнет. Не прочитает ее и слепой (а вам ну очень надо послать ему черную метку). Вообще это иллюзия, будто мы видим и понимаем мир одинаково. Я не буду вдаваться в подробности, но в XX веке это признанный факт. А передать сообщение надо, и передать его смысл - надо верно. Так что в наше время эти проблемы стали более заметны, но были они всегда. И вернуться к "бумаге" - значит, прятать голову в песок от проблем, которые все равно встанут (уже встали). Вот почему SGML, а вовсе не по тем конкретным, и очень точно и замечательно описанным причинам, которые Вы увидите в статье БТ. Они лишь следствие. Само наличие этих причин - доказательство того, что если бы SGML не было, его надо было бы выдумать. SGML родил HTML, но первенец вышел не очень удачным. Прямо скажем, довольно чудовищное порождение, в котором структурные по замыслу теги имеют форматирующие атрибуты. Вообще, мы живем в эпоху чудовищного искажения веба. Самый жуткий пример - таблицы. Весь мир использует таблицы для вестки страниц, а это чудовищно. Девушки, не выходите за дизайнеров, которые используют для верстки таблицы с фиксированной шириной. Из них получатся плохие мужья - тираны и насильники. Впрочем, некоторым нравится. Почему чудовищно? Потому что есть много форматов распространения документов, я их упоминал, тот же RTF, которые сильно озабочены тем, чтобы в любой "медиа" - на экране, на бумаге, в IBM и в Macintosh-е документ выглядел одинаково. Ради бога. Мы пошли другим путем. И на тебе! Мудрость Марка Андрессена, наверное, несколько преувеличена. Когда он писал Mosaic под HTML 2.0, он был революционер. Но если сейчас Навигатор не умеет работать со стилевыми таблицами - это не преступление, это хуже. Это ошибка. Каскадным таблицам стилей - CSS - а это тот механизм, который отвечает за внешний вид, то есть за форматирование текста при структурном подходе к документу - будет посвящена одна из будущих заметок. Неудивительно, что народ не очень представляет себе, что такое SGML - вот антипример не с худшего сайта: "The moral of this section, and the key to understanding SGML is that the structure of a document is the foundation from which the appearance is deduced." Именно наоборот, из структуры текста никак нельзя логически вывести его внешний вид. По-моему, это даже очевидно. Более того, "ключ к пониманию SGML" следующий: для эффективного управления информацией содержание, структура и оформление должны быть решительно и категорически разделены. Порождаться, управляться, модифицироваться отдельно. Храниться отдельно. И т.д. Именно это и было воплощено в SGML его создателями. Если мы показываем один и тот же документ в графическом браузере и в Линксе, то мы должны подключать разные стилевые таблицы. И "автор" ("sender", etc.), выделяемый курсивом в одном случае, может выделяться, например, цветом в другом. Вообще распространенное мнение, что во всех браузерах "картинка должна быть одинакова" (tm заказчик) - в принципе "ненаблюдаемая величина". Кто это смотрит на одну и ту же страницу в разных (тем более во всех) браузерах? Картинка должна быть "узнаваема" (стиль), логична, удобна, красива, эргономична... Но "одинаковой" она быть не может. Даже портрет в музее смотрит на Вас - и значит, не смотрит в этот момент на другого посетителя. -- А с точки зрения... -- Да-да, это разные портреты. Это не очень общеупотребительная практика? Общепринято ругать кривизну браузеров? Ну-ну. Вот именно это я и хотел показать. Понимание простой вещи -- SGML описывает логику -- изменяет подход к восприятию реальных и каждодневных проблем. Осталось несколько слов: SGLM родил XML. Казалось бы, размечать документ в SGML не сложнее, чтом HTML-е или TEXе, дело привычное миллионам людей. Чем же сложен SGML? Исторически сложилось так, что SGML перекодируется в определенное множество "медиа", вот неполный список, я приведу конкретный пример: % sgml2txt foo.sgml - текст,
и т.д. И если вы нарушите что-то, что нужно для конвертирования туда, куда вам никогда не понадобится конвертировать ваш текст, вас вежливо остановят и скажут: fatal error. Другой прикладной пакет может добавить что-то, или отнять (немного), но в принципе, как придумать правила разметки, удовлетворяющие любой "медиа"? В данном конкретном пакете, кстати, нет конвертации в GIF и во FLASH - а это открытые форматы. Например, одна "медиа" поддерживает гиперссылки, другая нет. И то, что было приличной гиперссылкой, становится совершенно неудобочитаемым именем раздела. И нужно ли это? Ведь наиважнейшим среди всех искусств для пролетариата является, как известно, веб. Так появляется XML - упрощенный и заточенный под веб SGML, но это уже совсем другая история. К истории SGML Я процитирую высказывания Робина Ковера (Robin Cover), которые вы найдете в оригинале на, возможно, лучшем источнике по SGML и XML в настоящее время - http://www.oasis-open.org/cover. "Мне представляется несомненным, что по крайней мере три следующие идеи были широко распространены уже в 60-е, зачастую в сообществах, которые редко контактировали друг с другом: (а) представление о разделении "содержания и структуры" в задачах преобразования текста [для печати] ([print] processing), (б) представление об использовании имен для разметки элементов, которые определяли бы текстовые объекты "описательно" или "процедурно" ("descriptively" or "generically"), (в) представление об использовании (формальной) грамматики для задач моделирования структурных взаимосвязей кодируемых объектов текста". Эти идеи, и конкретные задачи и нужды людей и привели в свое время к появлению данного мощного и красивого стандарта.
На данный комментарий был получен очень интересный отзыв Александра Таранова -- Бориса Тоботраса, с рядом существенных замечаний. С первым замечанием я, конечно, согласен. SGML был использован как "метаязык", и следовательно он, формально, метаязык. Однако он создавался и задумывался просто как "язык разметки структуры", потому и потомок -- уродец. И, главное, к нему в пару не был создан соответствующий стандарт для представления данных в зримом виде -- без изменения структуры -- (CSS, XSL, DSSSL). Однако это тема будущей заметки. Этот отзыв мы также предлагаем
вашему вниманию.
06.07.99 MB. |
![]() |
![]() |
© IPLabs Linux Team , 1999 , 1998 | Использование материалов═ разрешается только со ссылкой═ на═ первоисточник. |