Здравствуйте, netch80, Вы писали:
V>>>>да главное что парсеры не сломаются об такие ошибки N>>>А лучше бы сломались, раз это ошибки. V>>это не просто ошибки, это "такие" ошибки.. V>>о которых ломаться не должно N>Так это ошибки или нет?
в традиционных парсерах — это ошибки времени парсинга
в xml — это в худшем случае семантические ошибки, а в лучшем программа даже не заметит ничего и отработает "как надо", пропустив непонятные опции/данные
N>Вот именно что "вкурить". Это уже дзэн какой-то получается, а не опыт.
называйте как хотите, я описываю реальность данную мне в ощущениях, какая бы она не была и как бы она не противоречила вашему мировоззрению
вы описываете — сон своего разума
N>>>>>Ойвэй, так таки и не будут. Годами программисты нарабатывали методы, как читать не только "старые данные" но и старые форматы, как их различать и по явным указаниям, и эмпирически (если где-то не получилось пометить явно). А тут вдруг раз — и не будут. V>>>>угу.. годами.. и лучшее средство которое придемули — XML V>>>>где раскрученное средство весовой категории yacc/XML которое бы для yacc-а обеспечивало это? N>>>Что именно обеспечивало бы? Определить в начале потока какой-то признак формата и дальше выполнить "условный switch"? ЛЮБОЕ средство такое может. Тот же yacc, только надо в грамматику это вставить. V>>а зачем я должен поддерживать несколько веток для switch-а? V>>это bad smell вообще то! V>>а зачем я должен заставлять пользователя прописывать версию и следить за её актуальностью? N>Пользователь как раз ничего не прописывает. Вы о чём?
разве? а как же "в начале потока какой-то признак формата"?
а ведь ещё хуже бывают варианты..
когда даже не в начале потока а почти в каждой строке приходится формат писать..
типа такого:
#ifdef MSVC
...
#endif
или такого:
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
N>Опять — я про то, зачем XML, а Вы — про yacc. Это и есть передовой опыт отрасли — перевод разговора на иное? N>(Это я уж не вспоминаю в каких случаях вводился XML. А вводился он, как правило, вместо того, что в разы кривее, N>и для описания данных, а не для программирования)
скажите а вы оригинальную статью Голуба читали? в начале топика?
он именно жалуется на то что XML используется не только для данных
N>Думаете, он 13 лет зарождался?
а вы думаете он приснился во сне как таблица Менделеева?
Здравствуйте, kan, Вы писали:
kan>eao197 wrote:
>> А какая альтернатива в XML будет, например, у: >> >> if something && ( something_else || ( first && second && third ) ) >> ...bla-bla-bla... >> elsif another || yet_another || or_yet_another >> ...bla-bla-bla... >> else >> ...trundec... >> end
kan>Если что-то типа подхода xslt (для условий используется xpath):
kan>
kan><choose>
kan> <when test="something and (something_else or (first and second and third))">
kan> ...bla-bla-bla...
kan> </when>
kan> <when test="another or yet_another or or_yet_another">
kan> ...bla-bla-bla...
kan> </when>
kan> <otherwise>
kan> ...trundec...
kan> </otherwise>
kan></choose>
kan>
kan>Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в kan>html/svg javascript тоже активно юзается, никто не жалуется.
Хм. А почему совершен переход в условиях на свой синтаксис? Потому что так удобней? Значит, ещё чуть-чуть добавить к нашему парсеру, и получится без лишнего синтаксического оверхеда.
А если мы не хотим писать свой парсер, то тогда придётся писать, при условии простой вложенности конструкций что-то вроде
_Winnie wrote:
> kan>Хотя в условиях и javascript можно использовать. Испольозование xml > не запрещает использовать другие языки. Вон, в > kan>html/svg javascript тоже активно юзается, никто не жалуется. > Хм. А почему совершен переход в условиях на свой синтаксис? Потому что > так удобней? Значит, ещё чуть-чуть добавить к нашему парсеру, и
Потому что требование удобства написания программ превышает сложность написания своего парсера.
> получится без лишнего синтаксического оверхеда. > А если мы не хотим писать свой парсер, то тогда придётся писать, при > условии простой вложенности конструкций что-то вроде
В каких-то условиях и такие вещи могут оказаться лучше.
Что-то ты некрофилией увлёкся.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
E>XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне...
Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).
Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).
E>Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
E>>Еще пару капелек масла в огонь священной войны против XML На этот раз в качестве информации к размышлению о производительности. Разработчики распределенной системы контроля версий Bazaar в новой версии 0.15 отказались от использования XML в качестве формата для хранения описаний в рабочей копии. За счет чего получили серьезный прирост производительности на некоторых операциях (по ссылке рассказывается об ускорении операции status на дереве исходников ядра Linux-а от 2.2 до 13.9 раз(!)). До этого разработчики Subversion так же отказались от использования XML в описателях рабочей копии (см. 1.4 release notes, раздел Working copy performance improvements).
E>>Т.е. имеет смысл задумываться о выборе XML в качестве хранилища данных. Далеко не все ладно в Датском-то королевстве
К>В свете этого я не совсем понимаю смысл XML DB
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Курилка, Вы писали:
К>>В свете этого я не совсем понимаю смысл XML DB
L>А XML DB не использует XML в качестве формата для хранения.
Имхо — это только гиперболизация проблем xml.
Давайте вместо уровня абстракции введём ещё один уровень сложности.
Придумаем думателя.
Для шаблонных задач — это решение.
Для остальных — дополнительный геморрой.
Здравствуйте, eao197, Вы писали:
E>XML, вероятно, худший из когда-либо появлявшихся языков программирования. Я не говорю об XML как о языке описания данных, которым он был в своем первоначальном дизайне.
XML — это язык разметки (markup), то есть берется текст и его смысловые части размечаются:
Мама мыла раму, причем голубую
-->
<washing><who>Мама</who> мыла <what>раму</what>, причем голубую</washing>
Для описания данных предназначен, например, yaml (он так расшифровывается YAML Ain't Markup Language). Yf
washing:
who:Мама
what:Раму
Просто XML получил широкую поддержку и многие считают что проще использовать его, чем городить что-то свое или использовать что-то нераспространенное, хотя и заплатим некоторую цену читабельности.
_>я жалуюсь. при всей моей любви к этой игрушке трафик, при большОй стимости за оный, достаточно велик и точно проигрывает icq-шному.
Особенно на мобильнике J2ME+GPRS
Вот тут бы что-то типа EBML было бы сильно лучше.
Впрочем там и протокол надо пересматривать — например не грузить ростер целиком при запуске, а только изменения от последней загрузки.
GZ>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
jabber/gzip уменьшает трафик до 20-33%
При это zlib на J2ME работает не очень и память кушает дай боже — не каждый телефон справляется.
На вскидку, если из XMPP убрать повторения и избыточность и вместо XML сделать двоичный формат — сожмётся сильнее и при этом гораздо легче будет и для клиента-мобильника и для сервера, которому не придется для каждого соединения отдельный словарь LZW хранить
Здравствуйте, Cyberax, Вы писали:
C>XML — это язык конфигурирования и программирования данных. Я НЕ хочу C>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат,
Google использует множество различных типов данных, которые передаются в виде сообщений между серверами. Большинство из них имеют иерархическую структуру, которую необходимо представлять в определенном виде. Использование XML в этом случае неэффективно, так как когда сеть и узлы работают на полную мощность, обработка XML отнимает слишком много ресурсов. Кроме того, код для работы с деревом DOM иногда может быть очень громоздким.
Protocol Buffers позволяет описывать простые структуры данных используя специальный язык, который затем компилируется в классы, однозначно представляющие эти структуры в любом выбранном языке программирования. Классы обрабатываются хорошо-оптимизированными парсерами и могут быть сохранены в очень компактной форме. Но что более важно, это легкость их использования: у каждого поля структуры есть свои "get" и "set" методы, и в случае надобности сохранения (или чтения) этого поля в виде массива байтов или же I/O потока, оно осуществляется вызовом соответствующего метода. Полная независимость структуры классов от программ-обработчиков позволяет безболезненно обновлять программы, скомпилированные под «старый» формат.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>XML — это язык конфигурирования и программирования данных. Я НЕ хочу C>>разбираться с кучей яызков для описания ДАННЫХ — я хочу один формат, ANS>А прийдётся разбираться Google открыл протокол обмена данными Protocol Buffers:
Собственно, я о нём аннонс в форум по C++ писал
Protobuf — это как раз ПРАВИЛЬНОЕ применение для кастомного языка. Так как он используется для не-human-readable данных, для которых критична скорость и занимаемый объём.
Там место для XML — это разве что описание самих протоколов. Но формат а-ля-idl для них уже просто стал стандартом.