On Fri, 13 Nov 2015 15:33:57 +0300 Max Dmitrichenko <[email protected]> wrote:
> > Кстати, между прочим, бинарное представление XML/SGML в виде DOM с > > которым работают браузеры, форматтеры и xslt-преобразователи > > занимает обычно в 10 раз больше места, чем текстовый формат в utf-8. > > Возьмите JSON, если хочется компактности. Проблема в том, что: В сериализованной форме у sgml/xml вполне нормальная компактность. Конечно, если использовать имена тегов на полстрочки, как в DocBook или xsl-foo, то чуть похуже, если как в html-е старательно выбирать для самых частых тегов самые короткие (вплоть д о однобуквенноых <p>,<b>,<i>) имена - чуть получше Но по сравнению с DOM-структурой в памяти это копейки. JSON нам потребуется распарсить в примерно такую же иерархическую структуру с указателями, что и XML. И эта структура тоже будет на порядок больше, чем сериализованное представление. И в общем даже ASN.1 DER encoding нам много выигрыша по сравнению с xml нам не даст. Ну в два раза, ну в три, но не на порядки. > XML/SGML/JSON данные имеют структуру, причем не фиксированную, и > доступную для обработки любым универсальным (и уже написанным) > парсером соотв. формата, а текстовый формат конкретной програмулины > надо парсить специфичной именно для этого формата программой, каждый > раз изобретая велосипед. Зачем каждый раз изобретать велосипеед? Существует уйма уже написаных генераторов парсеров, вроде yacc/bison, которые превращают формальное описание входного языка в работающий парсер. Или можно взять любой более-менее гибкий язык программирования - Lisp/Scheme, Tcl, Lua, и сделать на его основе DSL, воспользовавшись его готовым парсером. Собственно парсинг XML-я это даже не парсер, это аналог лексера в LALR(1) грамматиках. Парсинг в смысле yacc-а начинается когда мы начинаем проверять логическую структуру дерева. То есть в XML это валидация схемы. Про которую часто забывают.
