Дискуссии об осмысленности XML

> Тюринг-полный

Ой, брацы! Дымицца!!!...

>> Статьи, в которых описывается, как всё плохо, научного интереса не представляют.

> Это не так. Умение находить контрпримеры в математике ценится не меньше умение доказывать теоремы. Другое дело, что таки да за открытие премии дают, а за закрытие только хмыкают досадливо. А ведь оба эти действия не менее важны для поика истины.

Нахождение контрпримеров не должно быть самоцелью. Условно говоря, перемыть косточки можно чему угодно. При желании - хоть CBCL :)

В свете множества претензий к XML я лично не вижу никакого смысла в ещё одной критической статье. Есть простое правило: отвергая, предлагай взамен. У автора же только в одном месте прозвучал YAML, и то как-то не очень внятно.

Чевой-та? Смотреть здесь http://www.maya.com/local/doc/xslt/FAQ/html_format/xsl/sect4/turing.html и здесь http://www.google.com/search?q=xslt+turing

>Как будто, если бы существовало удобное решение обмена данными, кто-то стал бы париться и создавать на пустом месте http://www.w3.org/XML/#wgs 4 рабочих группы и платить им деньги ни за что.

Если присмотеться к рабочим группам, и компаниям толкающим решения, то можно выяснить один любопытный факт: люди которые сейчас продвигают SOA, до этого продвигали ESB, а до этого CORBA. Из чего более-менее следует, что SOA - всё тот же маркетинговый пузырь, и лопнет он оставив после себя даже меньше, чем два предыдущих монстра.

>А вам в детском саду не говорили, что быкапы надо делать? Просто чтобы были.

Их наличие не увеличивает радости от того что пришлось физически стирать все базы постгреса и заново делать init, потому что запорол все - при любом телодвижении слетал постмастер.

> и про иерархические БД все забыли. Угу, ровным счетом до тех пор пока информация хранимая и обрабатываемая компьютерами хорошо поддавалась структуризации. А когда захотелось большего, оказалось что нужно ввести такие понятия как: - неструктурированные данные (изображения/аудио/видео); - полуструктурированные данные (semistructured data, собсно тема моего диплома семилетней давности).

И оказалось, что РБД со всей ихней масштабируемостью и нетормознутостью тоже не совсем подходят. Я не говою что РБД - это плохо. Это отлично, но для своих задач. А когда необходимо хранить полуструктурированные данные, то извините-подвинтесь! Нужны специальные хранилища. И тут XML БД очень даже ничего справляются.

Пример. Техническая документация. Нужны перекрестные ссылки из текста на какие-то темы (допустим, что в результате этого должна получится книга в PDF или файл справки в CHM). XML хранилище, каждая глава - отдельный XML файл (допустим любимый тут всеми docbook, хотя он вроде не допускает chapter корневой элемент, но для схематичности пойдет). Все файлы кладем в репозиторий. Надо вставить ссылку - вызываем диалог поиска вводим ключевые слова, которыми параметризируется XQuery запрос к XML репозиторию и получите список тем в которых встречаются эти слова. Выбрали нужную вставили в документ. Все очень просто для пользователя и достаточно просто в реализации.

Согласись, что разложить docbook в реляционной модели, так чтобы было искабельно: а) сложно; б) не быстро.

Какая версия PostgeSQL? Напиши комплейнт им.

>> Тюринг-полный

>Ой, брацы! Дымицца!!!...

>mutronix (*) (10.04.2006 17:20:36)

http://www.refal.net/~korlukov/tm/ Alexandr Korlyukov professor, the Grodno State University

>и лопнет он оставив после себя даже меньше

Вам то какая разница? Вы столько не проживете даже при самых благоприятных обстоятельствах чтобы увидеть что-то что оставит после себя больше.

>Модель естественно нужна, другое дело, что описание данной модели в файле конфига будет сделано по существующему стандарту. Увидев один DTD файлик твой брат по разуму сразу скажет "угу, понятно, вот это номер крана, а вот это его состояние", после чего схватив XML-парсер _очень бодро__ наваяет выкачивалку данных из твоего конфига. Возможен более хитрый (и более быстрый) вариант с XSLT

Формат передачи данных это одна из самых мелких проблем - его унификация это экономия на канцелярии. Основная проблема как эти данные представить человеку. XML давать человеку нельзя - с этим вроде уж как пришли к консенсусу.

>В общем случае плэйн-текста, васили пупкин пишет никак недокументируемый текстовый файл.

Угу. В общем случае васили пупкин пупкин пишет XML конфиг с только ему понятными тегами. Мы же говорим о том, что формат данных должен быть задокументирован - тогда без разницы как его читает программа, но человек должен читать plain text

>Простой конфиг можешь парсить в чём угодно в чём бы он не был. Лшь бы было описание структуры. Естественно никому это добро показывать нельзя, если это не plain text.

Повторно пошло уже... Описание формата и его распространение среди других софтописателей незнаю уже кому и предложить.

>Как делать конфиги читай хотя-бы Рэймонда с его Искусством программирования для Unix

Как было бы хорошо, если бы все софтописатели прочитали его и стали усиленно применять познанное на практике.

>А вот сколько-нибудь нетривиальную структуру данных обработать никакой стандартный инструментарий тебе не поможет.

Совсем? Ни XSLT, ни DOM?

>Тебе в любом случае придётся писать обработку и писать правила по каким эти данные будут представляться пользователю. От того что ты формально знаешь, что этот кусок данных означает, что кран номер 123 открыт не позволит сделать выводы - надо знать модель, которую представляют эти данные.

Модель естественно нужна, другое дело, что описание данной модели в файле конфига будет сделано по существующему стандарту. Увидев один DTD файлик твой брат по разуму сразу скажет "угу, понятно, вот это номер крана, а вот это его состояние", после чего схватив XML-парсер _очень бодро__ наваяет выкачивалку данных из твоего конфига. Возможен более хитрый (и более быстрый) вариант с XSLT.

В общем случае плэйн-текста, васили пупкин пишет никак недокументируемый текстовый файл. После этого товарищ Василия начинает писать свой парсер (предварительно выучив всю документацию по конфигам) для его файла, начинает тестировать сей парсер на предмет нормальной работы с примерами конфигов и только потом встраивает этот парсер в свой продукт.

> допустим любимый тут всеми docbook, хотя он вроде не допускает chapter корневой элемент

IIRC, корневым элементом может быть любой элемент из пространства имён, уж chapter - точно

>Какая версия PostgeSQL? Напиши комплейнт им.

Да они знают. Я не первый наступивший на эти грабли. Пофиксили уже. Там даже проблема не вслете - слетела - хрен с ним - востановлю. А в том что он не может встать без того чтобы не отжаться - потому что не может сделать transaction log recovering. В 8м такого не произойдет - fixed.

А ты думаешь, в MS SQL 5 или MySQL 3 не было таких же багов?

> Нахождение контрпримеров не должно быть самоцелью. Условно говоря, перемыть косточки можно чему угодно.

Опасная точка зрения. В частности это одна из реальных проблем развития науки (немного пытались эту проблему поднять здесь: http://www.nsu.ru/phpBB/viewtopic.php?t=7649&start=0 ) - все любят открывать и никто не любит проверять.

>В свете множества претензий к XML я лично не вижу никакого смысла в ещё одной критической статье. Есть простое правило: отвергая, предлагай взамен. У автора же только в одном месте прозвучал YAML, и то как-то не очень внятно.

В замен предлагается именно XML - много в замен чему и как правило совершенно необосновано.

> Мы же говорим о том, что формат данных должен быть задокументирован - тогда без разницы как его читает программа, но человек должен читать plain text

А он должен читать?

По мне, XML-конфиги среднего приложения (5-20 Кбайт) вполне читаемы (с другими не сталкивался пока), а вот когда дело доходит до текста, википодобная разметка всё же удобнее докбука, не говоря уж о вордах с райтерами, хотя да - менее функциональна.

ИМХО, сваливать в одну кучу возможные области применения XML, что некоторые тут традиционно пытаются делать, - не самая разумная идея.

>Формат передачи данных это одна из самых мелких проблем - его унификация это экономия на канцелярии. Основная проблема как эти данные представить человеку. XML давать человеку нельзя - с этим вроде уж как пришли к консенсусу.

Вы посмотрите какой щедрый дядя. Не экономия это на канцелярии - это концептуальная feature. Тут уже упоминали про переходы от одного релиза к другому всяческих IM-ов, так вот - и с конфигами те же яйца, вид сбоку.

Я всё ещё не могу уловить одну мысль - ты против чего протестуешь? Plain-text?! Дак он никак ни расширяемостью ни редактируемостью не блещет. Что не является "экономией на концелярии

>Угу. В общем случае васили пупкин пупкин пишет XML конфиг с только ему понятными тегами.

DTD + Schema. Валидация текстового файла васи пупкина и XML документа - две несопоставимые по человеко-часам задачи.

>Мы же говорим о том, что формат данных должен быть задокументирован - тогда без разницы как его читает программа, но человек должен читать plain text

Понимаешь, не надо изобретать колесо и писать новый ХМЛ. Просто не надо.

> Пример. Техническая документация. Нужны перекрестные ссылки из текста на какие-то темы (допустим, что в результате этого должна получится книга в PDF или файл справки в CHM)

Ну и чем LaTeX для этого плох? xxx.lanl.gov - смотрим и удивляемся.

>А ты думаешь, в MS SQL 5 или MySQL 3 не было таких же багов?

Это провокация флейма? ;) Постгрес мне нравится больше чем 2 вышеупомянутых.

> ну как раз текста там будет больше половины :)))

Ну, если я выкачаю lib.ru в тексте и затарю его, то текста там тоже будет больше половины :))

> я бы деньги на этот плавный переход не поставил

Я бы тоже, потому как не сомневаюсь в бесконечности человеческой глупости.

> если SExp == SXML - то уже говорилось что SXML == XML copyright anonymous

Да, но SXML --- лишь один из многих. Ничто не мешает построить другой язык на SExpr. Надо тебе, чтоб не требовал интерпретатора --- один, можно потребовать интерпретатор по условиям задачи --- другой, более навороченный.

> мы по разному понимаем масштабируемость

А как вы ее понимаете? :) В данном случае, я понимаю ее так, что на SExpr'ах я могу сделать как простейшие языки, парсеры которых будут занимать десятки строк на любом самом ущербном языке, так и мощнейшие языки с мощнейшей семантикой вплоть до Lisp, при этом они будут читаемые и пригодны для ручной правки.

> ключевое слово - в LISP

Ага, т.е. язык, который никогда никуда не интегрируется --- более масштабируем, чем язык, который позволяет выбрать требования?

> была такая задача наполовину ассеблерный код обращался к web servisу

Ну и? При надобности на SExpr'ах строится простенький язычок с простой семантикой, легко обрабатываемый на асме.

> Вы считаете что все языки должны быть заменены лиспом ?

Ну, не все, есть языки, которые в своей нише имеют преимущества.

> нет, этот парсер не делает валидацию по DTD, XML Schema, Namespaces, преобразования XSLT и пр. он просто вытаскивает данные из XML - вполне достаточно :)

Т.е., этот парсер не использует всех возможностей XML. С таким же успехом, можно строить простейшие языки и на SExpr, которые тоже будут парситься в 200 строк на асме.

2 anonymous (*) (10.04.2006 17:42:32) и остальным:

Тьюринг пишыца с мягким знаком!

>> Мы же говорим о том, что формат данных должен быть задокументирован - тогда без разницы как его читает программа, но человек должен читать plain text

>А он должен читать?

Естественно. Должен же он как-то понимать результат, который ему программы выдаёт. Подставьте вместо читать видеть как стрелка откланяется вправо - любое понятное действие, но не XML

> ты невнимательно читаешь. Если это будет в ячейке таблицы - то валидатор xml все равно ругнётся на то место, где ты закрываешь ячейку, не закрыв тег <sum>. А твой любимый лисп ругнется только на конец документа.

Нет, он ругнется на следующий тег в неположенном месте. Разница невелика.

> И CORBA, по эффективности веб сервисы никогда не перешагнут.

> CORBA, например, в самом общем случае. В зависимости от задачи, можно использовать DCOM или RMI.

Не буду говорить про эффективность. С CORBA знаком очень мало, с DCOM, RMI и SOAP боль-мень.

Но у меня сложилось следующее мнение (вкратце): основное преимущество SOAP в роли RPC перед остальными заключается в том, что его можно пускать поверх HTTP, то есть он лучше адаптирован к инфраструктуре web'а.

Не NT-ли четвертая страдала от уязвимостей на RPCшных (14xx где-то) портах. Попроси админа пять-шесть лет назад открыть на firewall'е эти порты, что он тебе скажет?

То есть, если ты пишешь что-то в рамках одной организации, или группы организаций (до тех пор пока оно укладывается в VPN), я думаю, что CORBA/DCOM/RMI работоспособны. А если предоставляешь сервис тысячам клиентов за пределами организации, то наверное все таки лучше использовать web services.

Второй вопрос, наверное, комбинации раличных платформ на которых можно развернуть систему. У web services вроде как дела получше обстоят.

З.Ы. С web services активно последний раз работал в 2000-2001 годах, может чего и поменялось. Но так чтобы кардинально, вряд ли.

> Естественно. Должен же он как-то понимать результат, который ему программы выдаёт.

Мне кажется, что Вы оперируете каким-то совершенно определённым случаем применения языков разметки, но читается это так, словно речь идёт о всех возможных.

ИМХО, есть достаточно случаев, когда руками лазить в документ и читать его в родной разметке, будь то XML или TeX, совершенно излишне.

> выбор "мощнейшего из имеющихся инструментов" -это не мотивация, это понты

Это-таки один из пунктов мотивации.

> это может быть минусом. чаще желательно что-бы пользователь ничего лишнего сделать не мог, по крайней мере в первых версиях.

Угу. Надо же во второй будет включить "супер-мега фичу", за которую можно содрать ещё бабла. А эта фича --- три строки в конфиге на Lisp'е :)) Честно? Не могу придумать ситуацию, где пользователя надо ограничивать, кроме как в целях security.

Попытаюсь резюмировать.

Есть несколько видов ненавистников ХМЛ.

1) Есть плэн-текст, нафиг нам ХМЛ? Начинаешь говорить про расширяемость и способность безгеморной валидации-парсинга, начинают вещать про то, что вроде и не сложно всё это сделать (те реализовать недо-ХМЛ, только в уродливой велосипедной форме) для своего софта.

2) Даёшь лисп! Нахрен этот лисп упёрся - непонятно. Никаких плюсов не даёт, библиотек никаких, распространения никакого. Но всё-равно - даёшь! Будем всё сами писать (ато и на лисп переписывать) - лишь бы не ХМЛ.

3) Нафиг лисп в коммуникациях?! Начинают петь песни про то, что это медленно и никому не нужно. Про то, что протокол расширяем получается до бесконечности - это на всем насрать, начинают считать какие-то байты и тыкать пальцем на IP стэк.

У меня вопрос ко всем - что вам так ХМЛ дался? Ну не нравится он вам - создавайте альтернативную реальность, пишите собственные валидаторы-документацию на описание схем документа, пишите конфиги на лиспе а потом для него пишите парсеры, которые "тоже будет маленький" и конечно делайте дальше подобие xmpp в дряхлых IM и страдайте от версионизма. Не надо всем доказывать, что XML гавно только потому, что он существует, у вас всё-равно как-то плохо получается.

>> Естественно. Должен же он как-то понимать результат, который ему программы выдаёт.

>Мне кажется, что Вы оперируете каким-то совершенно определённым случаем применения языков разметки, но читается это так, словно речь идёт о всех возможных.

Гхмм. Это не было моей целью Я действительно говорю, что XML не имеет преимуществ перед уже существующими технологиями где требуется читать/править/писать текстовые фалй в текстовом редакторе. А в случае написания больших текстов XML противопоказан.

>ИМХО, есть достаточно случаев, когда руками лазить в документ и читать его в родной разметке, будь то XML или TeX, совершенно излишне.

Это не повод делать это невозможным.

Может быть, я же написал "вроде". Я использую только в sdocbook/article и то в редакторе где стили сразу apply'ятся (XXE).

> Ну и чем LaTeX для этого плох?

Не пользовался LaTeX, имею только общее представление, но, боюсь, что много чем. Просто я привел только вершину айсберга, один use case причем в разрезе XML/РБД, а не XML/LaTeX :)

> xxx.lanl.gov - смотрим и удивляемся.

Чему собственно удивляемся?

>> xxx.lanl.gov - смотрим и удивляемся.

>Чему собственно удивляемся?

Дествительно удивляться нечему - просто рабочая система. И все статистики есть, и поиск по всем ссылкам и авторов глянуть можно. И XML почему-то нет.

>2 anonymous (*) (10.04.2006 17:42:32) и остальным:

>Тьюринг пишыца с мягким знаком!

Тю! Как хочеца так и пишеца, одинаково правильно. Хоть Тьюринга, хоть Тюринга http://itc.ua/article.phtml?ID=4689&IDw=1&pid=15

http://www.google.com/search?q=%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D0%B0+%D0%A2%D1...

реализуй ф-ю Аккермана на xml'е.

... и как я еще раз повторяю - очень мало кто (если кто вообще) способен дать осмысленную критику infoset. Зато желающих поругать конкретный синтакс (при том, что он не единственный) - полный ЛОР. Ну хотите - за скромные деньги я наваяю парсер XML, использующий синтакс, максимально близкий к синтаксу .ini files?

1C предложила в качестве дополнительного слоя взаимодействия платформы со стандартными XML-технологиями будет реализована собственная технология XDTO (XML Data Transfer Objects).

http://pcweek.ru/_Article_Images/2006/mar09/ns01_02.jpg

>способность безгеморной валидации-парсинга

Это чушь. ВСЕ xml-парсеры безконтрольно жрут ресурсы и память при парсинге. Да и как может быть по другому, если невозможно предсказать ни глубину дерева, ни его объем ни даже размер конкретной секции.

Чтобы валидировать xml, надо написать хороший dtd. А хороший dtd ничуть не проще, чем процедура валидации для того же лиспа.

xslt написать - ваще ума палата должна быть. Не потому ли до сих пор для опенофиса нормального xslt в html нету? для бинарного закрытого ворда пакет wv или catdoc есть...

>Никаких плюсов не даёт, библиотек никаких, распространения никакого. Но всё-равно - даёшь! Будем всё сами писать (ато и на лисп переписывать) - лишь бы не ХМЛ.

Это как раз про XML? даже дифф написать не удосужились... Лисп проще и легче в понимании. Три строчки на XML и чтец уже в ауте из за дикого оверхеда в описании.

>Ну не нравится он вам - создавайте альтернативную реальность,

Этих альтернатив просто до чертиков написано и еще будет написано столькоже. Cat /etc/* - все альтернативы ;)

XML - мода. И его как раз и пихают всюду, что само по себе очень плохо.

>Только в редком случае, если нужны формулы

Мальчик, у тебя все мозги на парсинг xml'я ушли? На осознания факта, что если используется MathML, то формулы нужны в 100% случаев сил уже не хватает? Бедные, бедныи xml'щики.

> документации проще написать в docbook

Голословный бред сивой кобылы.

>и редаткоры поддерживают

emacs перестал поддерживать (что бы это ни значило) ЛаТеХ?

>и проблем с модулями нет

У ЛаТеХа есть такие проблемы?

> результат быстрее

Да? Бенчмарк в студию.

>и без геморроя виден.

Да что ты говоришь. Наверное набрать $ xpdf file.pdf или $ xdvi file.dvi это очень-очень-очень большой геморой, которого лишены xml'щики.

Короче, ты срезался по всем пунктам.

>> ну как раз текста там будет больше половины :)))
> Ну, если я выкачаю lib.ru в тексте и затарю его, то текста там тоже будет больше половины :))

ладно пиши бровзер - интересно посмотреть

>> мы по разному понимаем масштабируемость
> А как вы ее понимаете? :) В данном случае, я понимаю ее так, что на SExpr'ах я могу сделать как простейшие языки, парсеры которых будут занимать десятки строк на любом самом ущербном языке, так и мощнейшие языки с мощнейшей семантикой вплоть до Lisp, при этом они будут читаемые и пригодны для ручной правки.

линейный рост сложности, желательно с небольшим коофициентом

>> ключевое слово - в LISP
> Ага, т.е. язык, который никогда никуда не интегрируется --- более масштабируем, чем язык, который позволяет выбрать требования?

интеграция уже 2 чужеродных языков не сверхсложная задача, но и не сахар
XML тут неплохое решение

>> Вы считаете что все языки должны быть заменены лиспом ?
> Ну, не все, есть языки, которые в своей нише имеют преимущества.

значит надо учитывать интеграцию языков

>> нет, этот парсер не делает валидацию по DTD, XML Schema, Namespaces, преобразования XSLT и пр. он просто вытаскивает данные из XML - вполне достаточно :)
>Т.е., этот парсер не использует всех возможностей XML. С таким же успехом, можно строить простейшие языки и на SExpr, которые тоже будут парситься в 200 строк на асме.
>> была такая задача наполовину ассеблерный код обращался к web servisу
> Ну и? При надобности на SExpr'ах строится простенький язычок с простой семантикой, легко обрабатываемый на асме.

я не говорю что SExpr все - финал, я говорю что XML - хорошая замена
как говорилось - SXML == XML

>> выбор "мощнейшего из имеющихся инструментов" -это не мотивация, это понты
> Это-таки один из пунктов мотивации.

сколько в евро, стоит эта мотивация ?

>> это может быть минусом. чаще желательно что-бы пользователь ничего лишнего сделать не мог, по крайней мере в первых версиях.
> Угу. Надо же во второй будет включить "супер-мега фичу", за которую можно содрать ещё бабла. А эта фича --- три строки в конфиге на Lisp'е :)) Честно? Не могу придумать ситуацию, где пользователя надо ограничивать, кроме как в целях security.

ТЕСТИРОВАНИЕ !!! - если я ограничу пользователя мне надо будет меньше тестировать
хотя-бы на начальных этапах, е пр ст


в вашей схеме, например guile + GoodLanguage в определенный момент
может произойти взрывное увеличение сложности
из-за размазанности сементики представления данных по разным частям программы
есть только два пути -
1 - емакс
2 - упрощение семантики представления данных - XML

боюсь что даже будучи таким хорошим емакс единственный представитель такого пути
(по крайней мере из широко известных)
второй случай представлен значительно шире
(вероятнее всего наименее энергозатратный путь :)

>ИМХО, есть достаточно случаев, когда руками лазить в документ и читать его в родной разметке, будь то XML или TeX, совершенно излишне.

особенно размером в несколько мегов и пожатый зипом...

Вообще миф о читабельности xml уже порядком раздражает...

> Чтобы валидировать xml, надо написать хороший dtd. А хороший dtd ничуть не проще, чем процедура валидации для того же лиспа.

Добавлю 0.02. Вообще говоря, "хороший dtd" - оксиморон. Еще можно обсуждать хорошую схему (или как там оно называется в relax ng). Уж больно убог по своим возможностям dtd. Поэтому наваять dtd as good as it can be - относительно несложно. Вот хорошый xsd/rng сделать - да, иногда есть где поиграться...

Кстати, сила XML еще и в том, что dtd/xsd shareable - поэтому часто (и чем дальше, тем чаще) есть шанс, что для данной предметной области уже кто-то сделал его до тебя...

>Но при этом его _можно_ править руками.

Вызывающе неверная информация.

>тем не менее злые буратины активно юзают dockbook :)

Пожелаем им удачи в этом нелёгком деле.

>svg - он не для ручной правки.

Тогда зачем вообще нужен этот xml?

>> способность безгеморной валидации-парсинга
> Это чушь. ВСЕ xml-парсеры безконтрольно жрут ресурсы и память при парсинге. Да и как может быть по другому, если невозможно предсказать ни глубину дерева, ни его объем ни даже размер конкретной секции.

минимальный парсер использует объем памяти == размеру xml документа

>> XML - мода. И его как раз и пихают всюду, что само по себе очень плохо.

да и грех ею не воспользоваться :)

> И XML почему-то нет.

Ну и что что нет? А причем здесь РБД? При том, что в ней статьи проиндексировали (так информация о статье структурированная)? Или при том что полнотекстный поиск работает (а структура текста статьи игнорируется)?

Но при создании документа мне надо сделать ссылку не на целый документ, а на какую-то его часть:

- chapter - topic - image/title - ol или ul

в том случае если эта часть содержит определенные ключевые слова. Запрос выбирает мне структурные части документа, в которых есть необходимые слова, а не документ целиком.

Я вот что-то не нашел возможности в поисковой форме получить точное местоположение и уникальный идентификатор картинки, заголовок которой содержит текст "LaTeX is great". Я что-то упустил?

Не используй js, а используй lisp. (load-file "/home/ugoday/.gnuemacs.el") и всё в ажуре.

> Я вот что-то не нашел возможности в поисковой форме получить точное местоположение и уникальный идентификатор картинки, заголовок которой содержит текст "LaTeX is great". Я что-то упустил?

Угу. Индиксируются только осмысленные вещи. Индексировать всё подряд лишь бы было как это делает google - это не от хорошей жизни, а от того что никто инфу нормально помечать не хочет.

В научной статье смысл выводится в абстракт - это и есть разумная структурированность. Нет особой необходимости даже в полнотекстном поиске. Везде следует делать разумные допущения и ограничения основываясь на модели данных - экономит массу времени, причём времени пользователя.

Можно посмотреть на функцию, вычисляющу квадратный корень пользуясь четырьма арифметическими действиями и функциями "<", ">", и "=", реализованную на xslt. Очень интересно. Спасибо.

> Я использую связку

Всё замечательно. Одно не понятно. Зачем xml? лисп здесь смотрелся бы гораздо лучше.

>>svg - он не для ручной правки.

>Тогда зачем вообще нужен этот xml?

Пример. Есть многоязычный сайт. Для облегчения выбора языка пользователю предлагается карта, с помощью которой он может выбрать свой регион/язык. Так как показать все страны за раз не очень юзабельно, делается многоуровневая схема:

1ый уровень - карта мира, при наведении на соответствующий полигон он подсвечивается, полигоны соответствуют континентам: Европа, Азия, Африка и пр...

2ой уровень (например, если пользователь кликнул на Европе): Германия, Франция, Голландия...

Конфигурация регионов зависит от желания владельца сайта.

Решение: пишется XML конфигурация, которая задает состав и вложенность регионов. Берется SVG карта мира. Пишется XSLT трансформация, которая интерпретируя конфигурацию используя SVG генерирует: - набор SVG изображений (простых и со всеми highlighted регионами); - необходимый для отображения карты HTML и JS.

Все сгенерированные SVG изображения batik'ом перегоняются в PNG. 2 минуты... и все готово к deployment'у на сайт . Надо добавить новый регион? Добавили одну строчку в конфигурацию [процесс описанный выше был в Ant'овском build скрипте], набрали ant... 2 минуты... и все готово к деплойменту на сайт.

Заслушаю вариант решения без SVG.

>Господи, какой ужас! А для парсинга своих ini-подобный конфигов ты наверно ничего не пишешь, да?

а) ini-конфиги не нужны. Нужен лисп.

б) для лиспа всё давно написано.

>Мой тебе совет - попробуй потом свой конфиг выпарси из чего-нибудь быдлокодерского (джавы, С, бэйсика...).

Это не проблемы лиспа.

>Вы вместо SQL-я тоже будете свой лисп пропихивать?

sql --- правильный dsl. Против него ничего не имею.

>> ИМХО, есть достаточно случаев, когда руками лазить в документ и читать его в родной разметке, будь то XML или TeX, совершенно излишне.

> Это не повод делать это невозможным.

Откуда эта склонность к преувеличениям? Почему невозможным-то? Для меня лично сложный XML по воспринимаемости равен plain TeX. Что туда слазить руками, что туда - всё едино.

> Может быть, я же написал "вроде". Я использую только в sdocbook/article и то в редакторе где стили сразу apply'ятся (XXE).

А, ну так это к аффтарам редактора претензии :)