Настолько подсел на всяческие универсальные инструменты разработчиков, что отвык от написания обработок. Но тут понадобилось затолкать в XML в формате ФНС ещё одно поле, а унивесального инструмента для работы с XML не нашёл...
по следам #2921103:
— во-первых, переводить текст Никиты на хабре — это LOL
— во-вторых, шёл 2018-й год, а люди до сих пор мучаются открывать и читать большие (0.5G+) файлы редакторами (в комментах 200M, блин, те же вим и емакс легко справляются с этим, правда у них тоже есть разумный предел — на моей памяти у емакса — 1.5G, у вима — 2G — ну т.е. открывает, но ходить по файлу уже неприятно).
— далее, камушек в свой огород. брался написать анализатор XML как-то и, как водится, не довёл эту активность до конца. каюсь, грешен. интересно, подобный софт всё ещё нужен кому-то, кроме моего бывшего работодателя?!
— во-первых, переводить текст Никиты на хабре — это LOL
— во-вторых, шёл 2018-й год, а люди до сих пор мучаются открывать и читать большие (0.5G+) файлы редакторами (в комментах 200M, блин, те же вим и емакс легко справляются с этим, правда у них тоже есть разумный предел — на моей памяти у емакса — 1.5G, у вима — 2G — ну т.е. открывает, но ходить по файлу уже неприятно).
— далее, камушек в свой огород. брался написать анализатор XML как-то и, как водится, не довёл эту активность до конца. каюсь, грешен. интересно, подобный софт всё ещё нужен кому-то, кроме моего бывшего работодателя?!
en.wikipedia.org уау будующее
По итогам проведения разных тестов в #2808429 над XML 3.5 ГБ (one-line) или 4 ГБ (pretty-printed): Haskell вполне годится для потоковой обработки XML.
Тесты производились с помощью tagsoup + fast-tagsoup на ручной нарезке ленивых ByteString на чанки размером ~20 МБ (так, чтобы не разрезать события SAX парсинга).
Это Win!
Следите за ленью, юзайте beautiful folds (https://hackage.haskell.org/package/folds-0.6.3) и будет вам счастье!
Ухожу в подполье.
Тесты производились с помощью tagsoup + fast-tagsoup на ручной нарезке ленивых ByteString на чанки размером ~20 МБ (так, чтобы не разрезать события SAX парсинга).
Это Win!
Следите за ленью, юзайте beautiful folds (https://hackage.haskell.org/package/folds-0.6.3) и будет вам счастье!
Ухожу в подполье.
XML SAX Parser.
Lazy ByteString хорошо, но долго.
Добавляем туда замечательных фолдов, просто считаем число событий, максимально не ленясь. Для начала.
Итого 1035 секунд на 3.5 ГБ.
Strict ByteString хорошо, но сразу не хватает памяти.
Думаю, раз такое дело, то стоит дробить Strict ByteString на куски определенного размера +- несколько десятков байт на то, чтобы гарантированно попасть на границу событий. И затем передавать вычисленный аккумулятор дальше по списку.
Думаю, так оно быстрее выйдет.
Lazy ByteString хорошо, но долго.
Добавляем туда замечательных фолдов, просто считаем число событий, максимально не ленясь. Для начала.
Итого 1035 секунд на 3.5 ГБ.
Strict ByteString хорошо, но сразу не хватает памяти.
Думаю, раз такое дело, то стоит дробить Strict ByteString на куски определенного размера +- несколько десятков байт на то, чтобы гарантированно попасть на границу событий. И затем передавать вычисленный аккумулятор дальше по списку.
Думаю, так оно быстрее выйдет.
Кто о чём, а вшивый — о бане, в смысле, об очередной модели XML.
Если мы рассмотрим XML как цепочку символов StartTag a, EndTag a, Content a (или как говорят в соответствующей литературке — SAX), то совсем нетрудно будет заметить что он относится к классу языков сбалансированных скобок, т.е. не является регулярным.
Это не является проблемой самой по себе: мы всегда можем построить КА для разбора конкретной цепочки, и даже множества цепочек... Чем, собственно говоря, и занимаемся путём ваяния XML-схем различной степени упоротости.
А если есть способ? Нет понятно дело, можно перейти на новый уровень, взять МП-автомат и невозбранно юзать контекстно-свободные грамматики. Но тогда мы теряем всю алгебраическую вкусноту, присущую регулярным языкам... А в реальном мире алгебраические свойства регулярных языков куда важнее, чем возможность допускать более «широкие» множества цепочек!
Нет. Именно способ разбирать языки сбалансированных скобок, сохраяняя при этом все свойства регулярных языков. Как оказалось — есть!
Интуитивным объяснением почему КА не может разбирать языки сбалансированных скобок является отсутствие «памяти» . А если эту память можно присобачить?
Встречайте: Nested Word Automata (автоматы вложенных цепочек), а точнее его практическую реализацию Visibly Pushdown Automata.
Идея в том, что данный автомат жрёт три разных типа символов: «call» — обозначается как <a, «internal» — обозначается как a и «return» — обозначается как a>. Соответственно и функция переходов распадается на три: для символов «call» принимает текущее состояние и входящий call-сивол и возвращает следующее состояние и сивол который нужно засунуть на вершину стека, для «internal» принимает текущее состояние и входящий internal-символ и возвращает следующее состояние (т.е. как обычный КА), для «return» принимает текущее состояние, входящий internal-символ и символ с вершины стека и возвращает следующее состояние.
Т.е. в резултате мы получили класс МП-автомата, который не может за один символ запихивать и выпихивать символ из стека. Это повлияло на количество распознаваемых языков, но позволило сохранить свойства регулярных языков!
Более того, если у нас есть дерево t(a, b(c, d), e), то мы его можем закодировать как цепочку <t <a a> <b <c c> <d d> b> <e e> t>, т.е. ровно по такому же принципу как это делают SAX-парсеры.
За последний десякток лет была масса исследований на эту тему. С подборкой можно ознакомиться
madhu.cs.illinois.edu
cis.upenn.edu
Основополагающя статья Adding nesting structure to words: cis.upenn.edu
Слайды: cis.upenn.edu (с них лучше начать).
А теперь пара вопросов касательно первотега:
1. Неоднократно слышал что applicative-парсеры описывают регулярные языки. Где можно об этом почитать?
2. Кто-нибудь сталкивался с реализациями МП-автоматов на Х-е? Будут полезны также всякие LR/GLR/LALR реализации.
P.S.: Сабж применяется не только к XML, и вообще первоначально применялся для анализа программ, отсюда и call- и return- терминология.
Если мы рассмотрим XML как цепочку символов StartTag a, EndTag a, Content a (или как говорят в соответствующей литературке — SAX), то совсем нетрудно будет заметить что он относится к классу языков сбалансированных скобок, т.е. не является регулярным.
Это не является проблемой самой по себе: мы всегда можем построить КА для разбора конкретной цепочки, и даже множества цепочек... Чем, собственно говоря, и занимаемся путём ваяния XML-схем различной степени упоротости.
А если есть способ? Нет понятно дело, можно перейти на новый уровень, взять МП-автомат и невозбранно юзать контекстно-свободные грамматики. Но тогда мы теряем всю алгебраическую вкусноту, присущую регулярным языкам... А в реальном мире алгебраические свойства регулярных языков куда важнее, чем возможность допускать более «широкие» множества цепочек!
Нет. Именно способ разбирать языки сбалансированных скобок, сохраяняя при этом все свойства регулярных языков. Как оказалось — есть!
Интуитивным объяснением почему КА не может разбирать языки сбалансированных скобок является отсутствие «памяти» . А если эту память можно присобачить?
Встречайте: Nested Word Automata (автоматы вложенных цепочек), а точнее его практическую реализацию Visibly Pushdown Automata.
Идея в том, что данный автомат жрёт три разных типа символов: «call» — обозначается как <a, «internal» — обозначается как a и «return» — обозначается как a>. Соответственно и функция переходов распадается на три: для символов «call» принимает текущее состояние и входящий call-сивол и возвращает следующее состояние и сивол который нужно засунуть на вершину стека, для «internal» принимает текущее состояние и входящий internal-символ и возвращает следующее состояние (т.е. как обычный КА), для «return» принимает текущее состояние, входящий internal-символ и символ с вершины стека и возвращает следующее состояние.
Т.е. в резултате мы получили класс МП-автомата, который не может за один символ запихивать и выпихивать символ из стека. Это повлияло на количество распознаваемых языков, но позволило сохранить свойства регулярных языков!
Более того, если у нас есть дерево t(a, b(c, d), e), то мы его можем закодировать как цепочку <t <a a> <b <c c> <d d> b> <e e> t>, т.е. ровно по такому же принципу как это делают SAX-парсеры.
За последний десякток лет была масса исследований на эту тему. С подборкой можно ознакомиться
madhu.cs.illinois.edu
cis.upenn.edu
Основополагающя статья Adding nesting structure to words: cis.upenn.edu
Слайды: cis.upenn.edu (с них лучше начать).
А теперь пара вопросов касательно первотега:
1. Неоднократно слышал что applicative-парсеры описывают регулярные языки. Где можно об этом почитать?
2. Кто-нибудь сталкивался с реализациями МП-автоматов на Х-е? Будут полезны также всякие LR/GLR/LALR реализации.
P.S.: Сабж применяется не только к XML, и вообще первоначально применялся для анализа программ, отсюда и call- и return- терминология.
Чем парсить? По традиции самое простое, без мегафич, проще всего прикручивающееся.
Забавно, что пару лет назад, когда меня интересовал промежуточный слой XML для хранения логики BB-code разметки перед конвертацией в HTML ( linux.org.ru ) никто не предложил DocBook XML. Похоже, это то, что нужно. И позволит унифицировано задействовать разметки в других форматах, хоть Markdown, хоть AsciiDoc. Надо будет попробовать задействовать на практике.
Есть одна ебанутая спецификация, которая требует отдельные 0x0D заменять на 0x0A, а пары 0x0D 0x0A заменять на 0x0A. И пусть меня закидают ссаными тряпками, я вообще не вкуриваю как это сделать.
Не, ясен пень, нужно сварганить простейший конечный автомат (вернее, трансдюсер), который будет разбивать поступающие на вход байтстринги на более мелкие байтстринги (ленивые, без копирования). А вот как это сделать в реале?
Перейти на стринги, перейти на текст? Важна даже не столько вычислительная сложность. Важно чтобы реализация как можно меньше сношала сборщик мусора.
Обойти — не вариант. Во-первых, такое поведение — MUST. Во-вторых, без реализации такого поведения к чертям полетит вся кошер^W каноничность.
Не, ясен пень, нужно сварганить простейший конечный автомат (вернее, трансдюсер), который будет разбивать поступающие на вход байтстринги на более мелкие байтстринги (ленивые, без копирования). А вот как это сделать в реале?
Перейти на стринги, перейти на текст? Важна даже не столько вычислительная сложность. Важно чтобы реализация как можно меньше сношала сборщик мусора.
Обойти — не вариант. Во-первых, такое поведение — MUST. Во-вторых, без реализации такого поведения к чертям полетит вся кошер^W каноничность.
Если закодировать XML-дерево в бинарное с помощью техники FCNS, то получившийся результат прекрасно ложится на обычный комбинаторный парсер: комбинатор get (получить следующий токен) разбивается на два: fc (получить следующего «ребенка») и ns (получить следующего «брата»), т.е. пойти влево по дереву или пойти вправо. Понятно дело, что в реальном мире всё несколько сложнее: нужно парсить атрибуты, не давать парсить надмножество XML, парсит не well-formed документы, стримить документы и т.д. Но все базовые свойтва остаются.
Умные люди вообще считают что если закодировать XML бинарным деревом, то задачи валидации/навигации сведутся к SAT, и выдвигают туеву хучу вариантов реализации.
Есть и другая техника кодирования: карринг (или как её называют в TATA, extension encoding). Но почему-то я не нашел ни одной статьи по этому поводу.
Умные люди вообще считают что если закодировать XML бинарным деревом, то задачи валидации/навигации сведутся к SAT, и выдвигают туеву хучу вариантов реализации.
Есть и другая техника кодирования: карринг (или как её называют в TATA, extension encoding). Но почему-то я не нашел ни одной статьи по этому поводу.
Ну что за хуйня!? Есть xunpickleDocument и xpickleDockument. При этом прервая принимает URI который для винды будет /d:/foo/bar.xml , а вторая путь к файлу d:\foo\bar.xml . И нету функции что нормализует путь в ФС к URI.
Ну ёб вашу мать.
Ну ёб вашу мать.
Норот тут вот есть необходимость хранить конфиг в xml-е . Чем его лучше сериализовать/десериализовать? Примеры на HXT видел.
Оказывается у Вадлера есть несколько весьма интересных публикаций по второтегу! А сам он принимал участие в рабочей группе W3C XML Query от компании Avaya. Охренеть!
Неблагодарное это дело — перегонять XML в текст при помощи XSL =_=
Taggy, еще один парсер на хакейдже.
Камрады, кажется я наконец ущучил как сформулировать задачу валидации XML, а заодно и JSON!
Дано: порождающая грамматика g, дерево t полученное из дерева x, которое производит парсер XML. Нужно проверить что дерево t может быть порождено g.
Тогда задача будет состоять из двух этапов:
1. Описать преобразование x -> t, т.е. XMLTree -> OurDomainTree. Это задача обычного парсера, с самой обычной КС-грамматикой. ЧСХ, на этом этапе будет задетекчены практически все возможные ошибки XML, собранного printf, а именно: отсутствующие аттрибуты, нарушение формата аттрибутов, левые теги, левые аттрибуты.
2. Проверить что дерево t может быть порождено g.
Как я понимаю, для «сферического XML в вакууме», будет достаточно самой обычной КС-грамматики, причем в LR(1) форме (рекурсивно, снизу-вверх и так далее...). Подойдет, наверно, и PEG. А в некоторых случаях и вообще регулярные грамматики. Например, моя задача ничего кроме Нетерминал/нетерминал/.../терминал не предусматривает.
Более того, грамматика g послужит железобетонной базой для определения катаморфизмов для t.
Вопрос, что можно почитать по п. 2? Может быть кто-то что-то похожее уже делал?
Дано: порождающая грамматика g, дерево t полученное из дерева x, которое производит парсер XML. Нужно проверить что дерево t может быть порождено g.
Тогда задача будет состоять из двух этапов:
1. Описать преобразование x -> t, т.е. XMLTree -> OurDomainTree. Это задача обычного парсера, с самой обычной КС-грамматикой. ЧСХ, на этом этапе будет задетекчены практически все возможные ошибки XML, собранного printf, а именно: отсутствующие аттрибуты, нарушение формата аттрибутов, левые теги, левые аттрибуты.
2. Проверить что дерево t может быть порождено g.
Как я понимаю, для «сферического XML в вакууме», будет достаточно самой обычной КС-грамматики, причем в LR(1) форме (рекурсивно, снизу-вверх и так далее...). Подойдет, наверно, и PEG. А в некоторых случаях и вообще регулярные грамматики. Например, моя задача ничего кроме Нетерминал/нетерминал/.../терминал не предусматривает.
Более того, грамматика g послужит железобетонной базой для определения катаморфизмов для t.
Вопрос, что можно почитать по п. 2? Может быть кто-то что-то похожее уже делал?
Каждый раз когда делаю XSL какой, у меня возникает вопрос о том, что более правильно: apply-templates и вложенные template на кажды тип блока (там, книга, клава, абзац) или for-each, и перечисление всех блоков в цикле с таким же вложением?
Кстати, недавно тут спрашивал насчет xml и latex.
Короч, нашел texml генерю xml для него, оно высирает latex.
Само все искейпит, полет нормальный.
Правда пришлось повозиться когда надо вводить незаэскейпеные символы для латеха,
но накидал простой DSL, все норм.
Короч, нашел texml генерю xml для него, оно высирает latex.
Само все искейпит, полет нормальный.
Правда пришлось повозиться когда надо вводить незаэскейпеные символы для латеха,
но накидал простой DSL, все норм.
Проще ли генерить из латеха html, чем из XML?
fdik.org
YSLT — XSLT C style
Ссылка на YBlog2 битая, правильная — auchdieserschwachsinnmussinsinternet.de
А вообще я смотрел на этот проект: beremiz.org
YSLT — XSLT C style
Ссылка на YBlog2 битая, правильная — auchdieserschwachsinnmussinsinternet.de
А вообще я смотрел на этот проект: beremiz.org
Для анализа xml и выдёргивания из него нужных данных давно с удовольствием использую python + lxml +xpath. А как вы это делаете?
я наверное никогда не пойму смысл xsd:sequence в схемах xsd. Точнее так, я не могу вообразить случая, когда в хмл нужен, даже строго необходим, определённый порядок следования элементов; ведь только в этом случае нужно использовать в схеме именно sequence, а не xsd:all.
Но блять, схемостроители, и уж тем более тулзы автоматизации построения схем, везде лепять именно ёбаный сиквенс! A это нихуя не сахар, если ты валидируешься по чужой схеме.
Но блять, схемостроители, и уж тем более тулзы автоматизации построения схем, везде лепять именно ёбаный сиквенс! A это нихуя не сахар, если ты валидируешься по чужой схеме.
Кстати, хорошая идея. Хочу посмотреть на то, как будет выглядеть HTML страница в виде JSON. Конвертер написать что ли и натравить на что-нибудь вроде ЛОРа или ЖЖ.
manifest.sysapps.org JSON захватывает (уже захватил) разум веба. Чем эта лапша лучше XML — не понятно :3
Надо было мне распарсить xml и записать их в базу. И, блин, сделал я две версии одного и того же класса, в одном поля пометил JAXB аннотациями, а в другом хибернейтовскими аннотациями. И шо делать теперь? Долго — долго копипастить аннотации из одного класса в другой? (Классов много)
судя по тому, что я нагуглил, элемент xml не знает, кто его parent, и средствами etree это выковырять нельзя (напрямую — если хорошенько поизгаляться, то можно). в связи с чем вопрос — знает ли кто питонскую библиотеку для работы с xml, где есть стандартные средства для нахождения parent'а? не охота велосипеды городить
Не понимаю я такой формат как .plist. Это вообще нормально, что ключ и значение идут отдельными элементами друг за другом в хмл? Типа <key>название ключа</key><string>значение</string>.
Развал башки от всех этих web-приложений... Чуть шевельнёшь и уже ничего не работает :-|
Залез руками в конфиг VirtualBox. Все в целом понятно, и неплохо, но в упор не понимаю почему уж если взяли нормальный формат разметки не использовать его до конца. Один из примеров:
<ExtraDataItem name="GUI/DetailsPageBoxes" value="general,preview,system,display,storage,audio,network,usb,sharedFolders,description"/>
В другом месте увидел список путей через точку с запятой.
Имхо можно было разбить на отдельные ноды, и сунуть их внутрь... Мда, не понимаю.
<ExtraDataItem name="GUI/DetailsPageBoxes" value="general,preview,system,display,storage,audio,network,usb,sharedFolders,description"/>
В другом месте увидел список путей через точку с запятой.
Имхо можно было разбить на отдельные ноды, и сунуть их внутрь... Мда, не понимаю.
Задачка подствить в XML переменные из bash-скрипта. Не смог справиться с апострофом. С учётом вот этого webmasters.stackexchange.com "вывернулся" подставив '. См. unclev.ru
There was a task to evaluate bash variables within an XML. I couldn't cope with apostrophe. But found out webmasters.stackexchange.com and solved by replacing apostrophe character with '. See unclev.ru
There was a task to evaluate bash variables within an XML. I couldn't cope with apostrophe. But found out webmasters.stackexchange.com and solved by replacing apostrophe character with '. See unclev.ru
document category: schemaless
решил оставить тут как решилась проблема с кавычками внутри выводимого текста (она ломала то xml то json то не хотела появляться в html). используется MSSQL2K, для генерации xml был раскурен for xml explicit
1. SQL — в выбранных данных кавычка меняется на '<![CDATA['+replace(fieldname,'"', '\"')+']]>', т.е. экранируется по-хитрому
2. XML — поле выводится отдельным элементом, а не аттрибутом. можно. например, воспользоваться конструкцией [node!2!fieldname!xml]
3. XSL — убираются всякие disable-output-escaping="yes", т.е. не делается ничего. но не забыть что это не аттрибут и в <xsl:value-of select="fieldname"/> без @
4. JS — приготовленный в п.3 json использовать AS-IS (протестировано с document.createTextNode)
5. HTML — добавить CSS по вкусу, подавать свежим =)
1. SQL — в выбранных данных кавычка меняется на '<![CDATA['+replace(fieldname,'"', '\"')+']]>', т.е. экранируется по-хитрому
2. XML — поле выводится отдельным элементом, а не аттрибутом. можно. например, воспользоваться конструкцией [node!2!fieldname!xml]
3. XSL — убираются всякие disable-output-escaping="yes", т.е. не делается ничего. но не забыть что это не аттрибут и в <xsl:value-of select="fieldname"/> без @
4. JS — приготовленный в п.3 json использовать AS-IS (протестировано с document.createTextNode)
5. HTML — добавить CSS по вкусу, подавать свежим =)
котаны, а как в xpath получить значение атрибута? ну у меня есть вот такое:
<?xml version="1.0" ?>
<ipmi>
<bmc_reset>
<state code="ok"/>
</bmc_reset>
</ipmi>
я пишу
> root.xpath('//state/@code')
> ['ok']
это оно типа список выдало, а можно как-то без списка? ну, [0] я то могу добавить в конце, но это помоему не то
а xml оказывается достаточно хорош, если его применять к месту. написал генератор древовидного меню с на основе xml-структуры, крутота :3
А теперь можете меня бить:
$messages = $xml->xpath('/validationErrors/validationError/message');
$messages = json_decode(json_encode($messages), TRUE);
Как включить в ткаббере обычное сжатие передаваемого xml при условии поддержки такового сервером?
1) установить пакеты ztcl, tclmore
deb people.debian.org etch main
либо ждите пока в вике выложат актуальную информацию: en.tkabber.jabe.ru
хотя тут актуально: =) ru.tkabber.jabe.ru
2) также нужна библиотека zlib (вероятно zlib1g или zlib1, в крайнем случае исходники где-то здесь: zlib.net )
3) в настроках выбираем Login->::::loginconf(stream_options) или в окне логина выбираем вкладку SSL&Сжатие
ставим там Сжатие или Шифрование (STARTTLS). наслаждаемся =)
не забываем сохранить в настройках эту опцию для текущей и следующих сессий.
1) установить пакеты ztcl, tclmore
deb people.debian.org etch main
либо ждите пока в вике выложат актуальную информацию: en.tkabber.jabe.ru
хотя тут актуально: =) ru.tkabber.jabe.ru
2) также нужна библиотека zlib (вероятно zlib1g или zlib1, в крайнем случае исходники где-то здесь: zlib.net )
3) в настроках выбираем Login->::::loginconf(stream_options) или в окне логина выбираем вкладку SSL&Сжатие
ставим там Сжатие или Шифрование (STARTTLS). наслаждаемся =)
не забываем сохранить в настройках эту опцию для текущей и следующих сессий.
Самое непонятное в FOR XML EXPLICIT это вопрос как правильно выстроить порядок сортировки... Получил вот Check the ordering, теперь буду второтегать.
cherianajay.hubpages.com
На волне обсуждения html — говно, наткнулся на возможность создания кастомных html-тегов с помощью js.
На волне обсуждения html — говно, наткнулся на возможность создания кастомных html-тегов с помощью js.
Задался на досуге вопросом о том, может ли существовать адекватная и гибкая альтернатива html как языка для проектирования чего-либо подобного веб-страницам с относительно произвольным контентом (или хотя бы для веб-приложений). Такое ощущение, что сейчас практически все языки для описания интерфейсов по факту упираются в xml или во что-то xml-подобное. Есть, впрочем, HAML и прочие, в которых внутренность тега отмечается отступом, но фактически от этого html не становится сильно удобнее. Собственно вопрос — никто не видел каких-нибудь интересных рассуждений на тему, отходящих от xml-подобного формата с сохранением гибкости?
А что, в xml нельзя закомментить один атрибут? Хотя, конечно, всегда можно переименовать...