Доброе время суток всем

Пишу здесь, потому что посетила мою голову навязчивая идея. Я подумал, что если изложу свои мысли здесь, то вполне возможно, что из идеи в итоге выйдет достойный проект

Пара слов об XML
Я думаю ни для кого не секрет, что XML плотно засел в современные информационные технологии. Его используют везде. Раньше я видел только одно предназначение XML - файлы настроек. Однако сегодня его используют в Веб, тех же самых мессенджерах, форматы файлов стали активно строить на XML. Немалый вклад в укоренение XML на мой взгляд стала технология Office Open XML, разработанная компанией Microsoft. Да что тут говорить, даже старый добрый HTML всё чаще и чаще заменяют XHTML. Совсем недавно обнаружил, что мой любимый "MindManager" тоже использует OOXML для своих файлов.

Пара слов обо мне
Программирую 14 лет. Люблю Delphi, неплохо знаю ассемблер x86, С/C++ тоже немного знаю (2.5 года официальной работы). Моя стихия - это оптимизации и удобный пользовательский интерфейс (тоже в некотором роде оптимизация - эффективности деятельности пользователя). Имею опыт генерации и распарсивания XML/HTML с очень хорошей скоростью. Тестировали с разными парсерами - получилось что-то между pugiXML и Expat, ближе к pugi. С другой стороны парсер понимал только Ansi и Utf8, не мог обрабатывать CDATA. В общем достаточно неуниверсальный парсер

Зачем ещё один парсер
Я думаю многие со мной согласятся. Несмотря на обилие достойных SAX и DOM парсеров, вопрос идентификации элементов/атрибутов, производительности, валидации, удобства использования - по прежнему остаётся актуальным. Проект который я предлагаю сделать - максимально упрощает жизнь вышеописанную рутинную работу

В чём состоит идея
Идея проста и гениальна. В большинстве случаев, распарсивая сложный (или простой) XML, мы уже разумеется знаем его строение. По умному - если предполагается обмениваться XML, то к нему существует XSD-схема (или схема в другом формате). Для идентификации имён элементов и атрибутов мы используем различные алгоритмы, чтобы в конечном счёте строку-идентификатор преобразовать к целочисленной константе. Достаточно эффективен поиск таких идентификаторов в хеш-таблице. Но это накладные расходы: хеш-функция, поиск в массиве, коллизии, перераспределение массива, надо делать сверки строк. Лично я для подобных случаев разработал более эффективный способ. Я написал утилиту, которая имеет на входе ряд идентификаторов, а на выходе выдаёт оптимальную функцию на ЯВУ, позволяющую однозначно определять идентификаторы. К примеру если я знаю, что элемент имеет одно из имён: "sheet","row","cell","data","value","style" - то код позволяющий мне определить элемент, будет выглядеть так. TAnsiPointer - это мой внутренний тип, хранящий длину строки и указатель на её символы. Мне очень нравится :)

Но суть не в том. Суть в том, что
1) идентифицировать элементы и атрибуты можно на лету
2) генерировать целочисленные константы можно на лету
3) вся эта информация уже хранится в XSD
4) существует возможность проводить валидацию документа и преобразовывать данные к нужному формату тоже на лету. Например если ожидается число - то преобразовывать к числу, если дата - то к дате. Если нужно оставить строкой - ради бога.
5) в конкретный момент парсинга ожидается ограниченно малое количество идентификаторов: элементов/атрибутов. Это позволяет существенно сократить время идентификации очередного элемента/атрибута
6) ну и наконец, как человек таки написавший парсер, заявлю. С точки зрения производительности намного эффективнее парсить очередной элемент, когда ты знаешь, как он может называться. Это значительно эффективнее поиска скобочек, кавычек, спец знаков и тд. ... с дальнейшей их универсальной идентификацией

В целом я предлагаю разработать утилиту, которая позволяет открывать XSD-схему (или другие), выставлять им специфичные опции (например какие элементы/атрибуты пропускать или к каким типам приводить), а на выходе получать специально заточенные модули-парсеры *.pas (для Delphi/FreePascal) или *.h/*.c (для C/C++). В модулях будут объявлены все необходимые константы, а так же главная функция-парсер. Для Delphi она будет реализована в виде дампов машинного кода для платформ x86, x64, ARM. Для С/C++ будет реализация на ЯВУ, но тоже мега запутанная. Главное в этих функциях не читабильность, а стабильная эффективная работа и компилируемость.

Парсер по сути состоит из двух частей: модуль-парсер, заточенный по конкретному XSD, и один универсальный модуль, в котором будут располагаться вспомогательные функции и так же рутина для потокового чтения. Под потоковым чтением я подразумеваю эффективное чтение данных например из файла (или того же zip) и автоматическое переконвертирование в случае необходимости в нужную кодировку

На кого ориентировано
1) кому нужно обрабатывать огромные XML файлы с максимально возможной скоростью
2) кому очень хочется комфортного распарсивания с автоматической валидацией
3) кто хочет сделать DOM-чтение по конкретному XSD

Кто нужен в проект
один-два фаната XML, которые знают все его правила, знают подходы для парсинга, знают несколько эффективных реализаций
один знаток XSD который способен адекватно и в полной мере консультировать по всем особенностям схем
один-два классных специалиста, способных написать просмотрщик XSD (с возможностью выставлять наши специфические опции), с приятным и удобным пользовательским интерфейсом
один-два скептика, которые захотят на конкретных примерах доказывать, что наш парсер работает медленно и некорректно
я буду заниматься генерацией pas/h-c и вспомогательным модулем

Разумеется всё на энтузиазме
Хотя если у кого то возникнет желание разработать проект на материальной основе - буду рад продать свою идею и свой труд на его реализацию

Не умеете ?

тогда Вы нам не подходите
низкий уровень профессиональных и социальных навыков

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

рад, что с моей подачи на одного читающего человека стало больше
правда с логикой проблема. скептицизм должен быть связан с парсером, продемонстрирован конкретными примерами
могу порекомендовать почитать эти материалы: http://googletohelp.ru/?q=%D1%80%D0%B0%D0%B7%D0%B2%D0%B8%D1%82%D0%B8%D0%B5+%D0%BB%D0%BE%D0%B3%D0%B8%D0%BA%D0%B8+%D1%83+%D0%B4%D0%B5%D1%82%D0%B5%D0%B9

_Vasilisk_

спасибо за мнение

1) предложенный мной проект - это по сути и есть SAX. Вы почему то не учитываете время идентификации полученных строк, время перевода строк к интам/датам/булеанам/флоатам. Все эти вещи могут проходить автоматически и с очень высокой скоростью. Кроме бешеной скорости, объективный плюс - гигантское удобство. Можно вообще сделать так, чтобы element_start() приходил не просто со своим ID (обычно вообще указывается строка), а вместе с ID сразу же будет даваться заполненная структура согласно описанию в схеме (т.е. описание структуры генерирует утилита, а автоматическое её заполнение происходит в парсере)

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

3) я не против DOM. Кстати можно реализовать специфичный DOM-reader на основе этого SAX, где уже будут распарсеные элементы со всеми атрибутами

4) ну... меня вообще в данном случае интересует чтение. Мне представляет интерес удобно и быстро читать любые общедоступные XML. Будь то документы Excel например, или отчёты Oracle. Просто встречается в твоей жизни новый XML - и это добавляет сразу много рутины. А если схему через утилиту и получить парсер - миллион проблем просто исчезает

5) почему тысячи человекочасов ?
я согласен что это сложная задача. поэтому я её "перераспределил" на отдельного человека
но в целом почему валидация будет простой - объясню
в конкретный момент времени парсер будет знать, что ожидается например либо такой элемент, либо такой элемент, либо такой. Если ни одного из ожидаемых элементов не встретили - значит ошибка. Аналогично с атрибутами. В определённый момент времени будет ожидаться один из нескольких атрибутов. Если не встретился ни один из них - значит ошибка. Если встретился целочисленный атрибут, то нужно преобразовать символы к числу и заполнить определённое поле структуры. Если не получается преобразование - значит вызываем ошибку.

_Vasilisk_Скорость будет медленнее. Пример
я очень рад что встретил достойного опытного собеседника !
я на все Ваши вопросы отвечу, только пожалуйста, приведите пример хотя бы из 3-4 элементов, включающий объявление и главный элемент. Я схематично и псевдокодом объясню алгоритм парсинга, Вы поймёте, почему он очень эффективный. Пока Вы немного не так поняли мою идею. Но я с удовольствием объясню !

mage.lan

тебе не напомнить в каком ты разделе форума находишься, умник ? ))))))

я JSON конфиги не встречал
но ветка вообще не о JSON и Delphi если ты успел заметить. Ветка о конкретной идее, конкретном проекте. Поэтому прояви уважение, а критику XML оставь для соответствующих веток

я не ставлю под вопрос твой авторитет в вопросе современных технологий обмена данными
я говорю, что подобным сообщениям не место в ветке
если бы я спрашивал "что вы думаете о XML и JSON" или "стоит ли программировать на Delphi" - я бы понял
но таких вопросов просто не стоит, вот и всё

MasterZivЧто не понятно -- нафига вообще там нужна какая-то хэш-таблица элементов ? SAX-у то например ...
ну всё очень просто
в калбеки от парсера приходят строки: имена элементов и атрибутов
для того чтобы их обрабатывать обычно строки приводят к какой-то ID-константе и по инту уже делают case (switch)

_Vasilisk_

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

Омномнимправильно ApolloSUCKS
по себе не судят

_Vasilisk_

я отчаянно пытаюсь подобрать подходящий пример, чтобы продемонстрировать действие алгоритма :)
пожалуйста, придумайте побольше различающихся в имени элементов, лучше с иерархией, и несколько разных атрибутов
я продемонстрирую алгоритм, а потом сможем рассмотреть более сложные случаи, с необязательными или отличными элементами/атрибутами. Обещаю. Хотя когда я схематично покажу алгоритм, Вам сразу многое станет ясно !

что за новая манера дискуссии ? :)

скорость будет в разы быстрее чем Вы показали
Вы абсолютно не поняли алгоритм распасивания по XSD. И для того чтобы его продемонстрировать я прошу "побольше различающихся в имени элементов, лучше с иерархией, и несколько разных атрибутов". Я могу сам придумать, но Вы так хуже поймёте. А в том примере, который Вы привели - всего 1 разновидность элемента. Это мало

Дважды КулибинXML-Binding заново изобретаешь ? Он уже есть
ссылки на библиотеки, утилиты, статьи ?

XML-Binding заново изобретаешь ? Он уже есть
Он есть даже в Дельфи.

ну.... как бы это сказать....
идеи похожие, только XML-Binding мегатормозной по сравнению с предложенной мной идеей

petalvik
Второй достойный собеседник в ветке
Надеюсь наше общение пойдёт более удачно чем с _Vasilisk_ :)

> Бегло просмотрев, хочу высказаться.
> Т. к. я пишу в основном под .NET, то сравню вашу задумку с имеющимся в этой платформе.

ну что я могу сказать
C# (.NET) для людей делается. Тут действительно применили более удобный подход
С другой стороны он не так далеко ушёл от принципа XML-Binding

> Напоследок. Как я понимаю, весь код пишется вручную?
> Это во втором десятилетии XXI века?? Имхо, кодогенераторы рулят.
> Когда вся грамматика распарсиваемого языка описывается в виде РФБН
> в несколько десятков строк, и код парсера генерируется автоматически.

ни в коем случае не вручную!
всё кодогенератором (утилитой, которая на входе берёт XSD)

> Почему именно SAX? Гляньте это: Сравнение XmlReader и SAX Reader.
> Упомянутый XmlReader позволяет читать данные строготипизировано.
> Например, имеются методы ReadContentAsBoolean, ReadContentAsDateTime, ReadContentAsDouble и т. п.

Почему речь вообще пошла о SAX
Дело в том, что существуют 2 основные схемы распознавания XML: SAX и DOM
Собственно что я говорю, Вы и так знаете. Так вот, существуют различные задачи по обработке больших XML (100Мб и выше) с высокой скорость. И здесь SAX нет равных. По крайней мере не было.

И здесь родилась моя гениальная идея (да, я скромный). Что имея XSD мы можем существенно оптимизировать парсинг (сгенерировать конечный автомат), который будет автоматически определять идентификаторы элементов и атрибутов, и вызывать element_start() и attribute() уже не со строками в качестве имени, а уже с определёнными ID-константами, который определил парсер. Кроме того такой парсер (конечный автомат) очень легко может отслеживать неправильно или не в том порядке указанные элементы и атрибуты (валидация).

Потом я подумал, что значения атрибутов лучше тоже не всегда передавать строкой, а в случае определённого типа (числа, строковой константы, булеана, даты) - просто автоматически приводить данные к нужному типу и уже полученное значение передавать в калбек. Одновременно с этим вполне можно проводить валидацию значений! И это тоже будет проходить легко и непренуждённо!

Уже несколько суток я думаю следующее. Нафига вообще вызывать калбеки по атрибутам ?
Когда человек распарсивает элемент с атрибутами, элемент для него представляется некоей структурой. И XSD-утилита может генерировать описание такой структуры, и парсер будет в стеке выделять память под неё, заполнять все поля (в том числе по умолчанию), и в калбек уже передавать ID-структуры с указателем на данные структуры. Это мегаудобно. Кроме того это быстрее, чем дёргать калбек для каждого атрибута и заставлять пользователя его обрабатывать.

Ну и последние сутки я думаю, что на основе этого "SAX"-парсера, можно вполне сделать и DOM-парсер. Иначе говоря один парсер-"конечный автомат" одинаково хорошо может подходить и для SAX и для DOM. Фактически отличие только одно. Для SAX память под элементы будет выделяться в стеке, но для них будут вызываться калбеки. Для DOM память будет выделяться в пуле (такой способ менеджмента памяти) и наводить связи между Child-Parent ами. Серьёзными выигрышными сторонами такого DOM-решения по сравнению с тем же PugiXML и XML-Binding я считаю:
1) Максимально возможная производительность (из-за специально заточенной архитектуры парсера)
2) Практически бесплатная валидация (вообще это считается очень тяжёлой операцией). Но просто представьте, что вообще не надо будет заботиться о правильности введённых данных
3) Минимальное потребление памяти. Потому что не будет необходимости хранить в ОЗУ многочисленные строки
4) Супер удобство

P.S.
надо заботиться о пользователе
3 секунды значительно лучше, чем 10

AntonariyТолько сначала придется распарсить xsd, проверяя валидность его самого.
нет, читать ты всё-таки не научился )

AntonariyА что если определенный тип — комплексный?
комплексный тип - это и есть элемент(узел) с атрибутами
один элемент = одна структура

дочерние элементы(узлы) парсятся аналогично
в случае SAX - у элемента виден ID элемента-отца (без значений атрибутов)
в случае DOM - видно не только ID, но и значения атрибутов элемента-отца

Кстати я накидал объявления типов. Можешь начать изучать благородный язык Delphi
Хотя для *.h/*.c будут аналоги

тебя послать или ты сам знаешь дорогу ?

а можно поинтересоваться, на основе каких данных ты сделал столь мудрые умозаключения ?

Дважды Кулибин,

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

Antonariy,

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

Antonariy,
ну так я не первый день живу и не только XML-парсеры программирую )
ну и потом мы оба решили, что ты нам не подходишь
так что досвидания )

Дважды Кулибин,
о да фраза о том что автор использования указателей му**к - поистине крутая фраза )
а фразой "ну так реализовывай" ты вообще меня убил )
человек без аккаунта на форуме будет ходить раздавать всем вокруг ценные указания )
смешно :)

petalvik,

Мы говорим с Вами об одном и том же только разными словами

Рассуждая о SAX я рассматриваю данную статью: http://ru.wikipedia.org/wiki/SAX
"SAX-парсинг" в моём понимании - это процесс распарсивания XML, при котором каждая прочитанная единица отправляется системе в соответствующий калбек. Далеко не всегда удобный способ, но зато самый быстрый - потому что требует минимального потребления памяти и не содержит логики увязывания элементов и атрибутов между собой
"DOM-парсинг" в моём понимании - это процесс распарсивания XML, при котором получится иерархическое представление XML-документа, где в простейшем случае элементы будут содержать имя, список атрибутов, значение элемента, список элементов-детей и указатель на элемент-отца; атрибуты - это пара имя/значение. "DOM-парсинг" очень просто построить на основе "SAX-парсинга".
"XML-Binding" - это высокоуровневый механизм для работы с XML-документами. Но это надстройка над DOM.

> назову его pull-парсер, т. к. он не выталкивает данные, а их нужно вытягивать

я таки думаю, что там в основе всё тот же SAX-парсер. Ибо вообще сложно реализовать парсер, который разбирает семантику документа, отслеживает ошибки, перекодирует строки из XML в обычные, улаживает вопросы с кодировкой... Зачем для всего .NET писать несколько парсеров, когда можно написать производительный один, отладить его, и использовать для всех остальных разного уровня задач. Судя по Вашему описанию "pull-парсер" это высокоуровневая надстройка над обычным парсером (который я называю SAX)

> Чтобы ускорить клиентский код, имеется таблица имён (NameTable),
> куда можно занести заранее имена элементов, которые будут в xml,
> и в итоге сравнивать уже не строки (что медленно), а ссылки.

вот мы и подошли к вопросу, который я описывал ещё в самом первом своём сообщении ветки. Для того чтобы оперативно идентифицировать строки, правильнее использовать не сравнения строк, а сравнения ID-констант. В приведённом Вами примере используются не инты, а ссылки. Я о чём и говорю. "NameTable" это механизм отнесения строки к какому-то идентификатору. Для подобных задач хорошо зарекомендовали себя хеш-таблицы. Я сам очень часто использую хеш-таблицы, в том числе и для идентификации строк.

Но! Когда полный список необходимых тебе идентификаторов известен ещё до компиляции, существует в разы более эффективный способ их распознавания. Не нужно выполнять hash-функцию, не нужно хранить и управлять хеш-массивом, не нужно сравнивать строку со строкой в массиве. Я разработал утилиту, которая генерирует код, позволяющий однозначно идентифицировать и с максимальной скоростью. Опять таки посмотрите первое сообщение. Там 6 строк, определяющихся моментально. А может быть сколько угодно.

> Опять же, приведу в пример дотнетовский pull-парсер - он тщательно вылизан,
> с кучей ручных оптимизаций, и работает настолько быстро (бьюсь об заклад, вам его не побить ;) )

я не первый день живу на бренной земле :)
и подобных выражений выслушал уже не один десяток )
и когда проводится очередной тест, на котором моя реализация побеждает в разы, вместо дико восторженных возгласов "отныне ты наш бог и сенсей" я слышу что-то типа "ну для данной задачи особо то дополнительная производительность и не нужна, вот ты столько времени потратил, а мог взять стандартное решение, вот ты реализовал на ассемблере, но твоё решение не кроссплатформенное". Люди редко могут отходить от зарекомендовавших себя подходов. Люди редко способны разглядеть истинные перспективы. (Русские) люди редко искренне порадуются классным идеям других людей. И почти никогда не признают превосходство коллеги над собой

_Vasilisk_

я честно говоря не понял, где я Вас обидел, унизил, оскорбил. К чему такая реакция ?

мне прям стало интересно
с каких пор желание, умение и опыт делать качественное программное обеспечение стало проявлением неадекватности )

а вообще извольте извиниться