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

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

Пара слов об 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_

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