Парсер XML

← →
KilkennyCat © (2009-05-25 01:24) [80]

> огромное количество раз встречается <Compiler Name="...">.
> ..</Compiler>.

<Compiler>
<Compiler Name="A">8</Compiler>
</Compiler>

я бы так создал
<Compiler>
<A value="8"></A>
</Compiler>

Тем самым избежав возможной ошибки закрывающего тэга

← →
Mystic © (2009-05-25 01:29) [81]

> Я правда не совсем понимаю, нафига 3 миллиона "открывать",
> но у шахматистов свои тараканы

"Открытие" условно говоря равно экспорту с свой формат. А открывать надо не все три миллиона партий, а, например, чтобы узнать статистику по позиции. Например, челябинский вариант (обычно возникает после ходов 1. e4 e5 2. Nf3 Nc6 3. d4 cxd4 4. Nxd4 Nf6 5. Nc3 e5 6. Ndb5 d6 7. Bg5 a6 8. Na3 b5, но может получиться и из схевиненгена 1.e4 c5 2.Nf3 e6 3.Nc3 Nc6 4.d4 cxd4 5.Nxd4 Nf6 6.Ndb5 d6 7.Bf4 e5 8.Bg5 a6 9.Na3 b5) встретился по моей базе в 6578-партиях. В этой позиции основные (примерно равноценные) продолжения 9. Bxf6 (3289 партий) и 9.Nd5. Вот статистика:

Move ECO Frequency Score AvElo Perf AvYear %Draws 1: Bxf6 B33s 3289: 50.0% 55.7% 2368 2395 1999 32% 2: Nd5 B33l 3273: 49.7% 52.2% 2331 2348 1998 42% 3: Nab1 12: 0.1% 54.1% 2348 2432 1992 58% 4: [end] B33l 3: 0.0% 50.0% 2001 100% 5: Naxb5 1: 0.0% 50.0% 2005 100% _______________________________________________________________ TOTAL: 6578:100.0% 54.0% 2350 2372 1998 37%

из которой видно, что Nd5 ведет к более спокойной игре (больше процент ничьих). И что небольшой акцент сместился в сторону Bxf6 (и рейтинг на чуть-чуть выше и средний год).

← →
KilkennyCat © (2009-05-25 01:38) [82]

> Mystic © (25.05.09 01:29) [81]

Прикольно. Обожаю такие анализы. Можно все в студию? Иль сие - коммерческое?

← →
Игорь Шевченко © (2009-05-25 01:41) [83]

Mystic © (25.05.09 01:29) [81]

> из которой видно, что Nd5 ведет к более спокойной игре (больше
> процент ничьих). И что небольшой акцент сместился в сторону
> Bxf6 (и рейтинг на чуть-чуть выше и средний год).

Для меня это китайская грамота. Но, насколько мне известно, шахматные программы, разбирающие партию(и) для анализа использу.т механизмы, аналогичные СУБД и мало того, даже и хранят такие разобранные партии в своем внутреннем двоичном формате (а не в тексте и не в XML). Опять же, потому что им так удобнее. Поэтому для партии текстовое представление и XML - это промежуточные звенья, необходимые для создания рюмки коньяка с ломтиком лимона, а следовательно, твой наезд на XML с этой точки зрения ничем не обоснован.

← →
Mystic © (2009-05-25 01:50) [84]

Это не анализ, это статистическая обработка на лету. Программа Scid небольшая, в свободном доступе, ее можно скачать. Базу я экспортировал из коммерческой версии Fritz, там около миллиона партий. Если надо больше и свежее, обычно по конкретному варианту, то смотрю в online базе http://www.chesslive.de/ потом экспортирую в PGN, потом открываю в scid. Базы можно поискать на этом форуме http://immortal223.borda.ru/ но там обычно используется формат Chess Base CBV. Он закрытый, приходится конвертировать в PGN, потом экспортировать в Scid.

Если интересно, то из начальной позиции статистика такая:

Move ECO Frequency Score AvElo Perf AvYear %Draws 1: e4 B00a 476394: 47.5% 53.2% 2316 2343 1993 32% 2: d4 A40a 338257: 33.7% 55.0% 2363 2392 1992 36% 3: Nf3 A04 88738: 8.8% 55.3% 2378 2403 1993 40% 4: c4 A10 72635: 7.2% 55.1% 2367 2391 1991 37% 5: g3 A00t 8136: 0.8% 55.4% 2373 2391 1993 37% 6: f4 A02 4519: 0.4% 46.9% 2175 2184 1992 27% 7: [end] A00a 3495: 0.3% 54.9% 2311 2359 1991 19% 8: b3 A01 3448: 0.3% 51.6% 2301 2312 1996 31% 9: Nc3 A00l 2088: 0.2% 50.5% 2215 2249 1997 27% 10: b4 A00p 1270: 0.1% 48.1% 2138 2150 1997 25% 11: e3 A00k 605: 0.0% 42.8% 2149 2146 1991 20% 12: d3 A00j 447: 0.0% 48.3% 2241 2221 1995 26% 13: a3 A00f 344: 0.0% 47.6% 2193 2204 1998 24% 14: c3 A00i 199: 0.0% 44.4% 2237 2225 1994 29% 15: g4 A00n 187: 0.0% 46.2% 2260 2197 1997 14% 16: h3 A00d 56: 0.0% 53.5% 2242 2321 1998 21% 17: h4 A00c 41: 0.0% 32.9% 2169 2035 2001 22% 18: Nh3 A00g 21: 0.0% 38.0% 2163 2169 1994 38% 19: f3 A00b 15: 0.0% 26.6% 2143 1907 2001 13% 20: a4 A00e 14: 0.0% 53.5% 1999 21% 21: Na3 A00h 7: 0.0% 78.5% 1997 14% _______________________________________________________________ TOTAL: 1000916:100.0% 54.1% 2342 2369 1993 35%

← →
KilkennyCat © (2009-05-25 01:51) [85]

> Mystic © (25.05.09 01:50) [84]

спасибо.

← →
Mystic © (2009-05-25 02:02) [86]

> Игорь Шевченко © (25.05.09 01:41) [83]

Ну это как я укажу. Во-первых, PGN используется для обмена. Например, сыгран турнир, все партии турнира выкладываются в PGN, я могу их экспортнуль в свою базу. Или, например, базы данных игровых серверов. Во-вторых, я могу PGN просмотреть глазами. Так даже удобнее. Если прошел турнир, я его открываю как текстовый файл и смотрю кто что сыграл. В целом сразу смотрю те варианты, что играю сам и смотрю что там нового произошло. В-третьих небольшие базы я храню непосредственно в PGN. Которые посвящены отдельному варианту, который я использую. Да и просто, избранная база партий французской защитой в PGN занимает 56 Mb. Читается это файл 10 секунд, после чего с ним можно нормально работать. Базы поменьше пополняю руками. Например, если я сыграл интересную партию на сервере, я ее экспортну в PGN (или, еще проще, скопирую PGN в буфер) и вставлю в нужный файлик (файлики). Так быстрее и удобнее. Все эти операции были бы затруднены с XML.

← →
Mystic © (2009-05-25 02:13) [87]

Залезая немного вовнутрь, могу попытаться объяснить, за счет чего можно добиться ускорения работы. PGN формат текстовый. В 56 Mb текста содержится 56000 партий. Прочитать 56 Mb надо 10 секунд. Поскольку скорость считывания данных с диска медленна, то можно на лету их обрабатывать, дольше не будет. Для каждой партии я могу отмечать в качестве битовых масок где были пешки и фигуры за всю партию. И в итоге в памяти хранить нечто такое: партия #1, смещение 0, белые пешки были на полях a2, b2, c2, d2, d4, ... партия #2, смещение 1560, ... Таким образом при поиске позиции я вначале проверяю, могла ли возникнуть позиция в партиях по той информации, что я сохранил в кэше. Если могла, я перехожу к партии в файлике и читаю его уже проверяя на каждом ходу.

Насколько я знаю, стандартные XML-парсеры таким образом мне манипулировать не позволят. Они абстрагируют меня от таких ньюансов, как строка/столбец узла, и не позволяют перечитать часть файла...

← →
Игорь Шевченко © (2009-05-25 02:23) [88]

Mystic © (25.05.09 02:13) [87]

Я вот одного не понимаю - религия запрещает использовать XML для обмена, переводя его в нужное для анализа представление ?

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

← →
Mystic © (2009-05-25 02:37) [89]

> Один только момент - если я в твой текстовый файл повставляю
> недопустимых как с точки зрения текста, так и с точки зрения
> шахмат, сколько времени тебе потребуется, чтобы определить,
> что он некорректен ?

На моей машине файл 50 Mb читается 10 секунд, при этом происходит полная проверка: допустимые символы, допустимые ходы. Если под рукой не будет никаких утилит, то писать валидатор придется самому. Но формат очень простой. На XML я могу проверить синтаксис, но вот легкой проверки семантики я не вижу. Как легко определить, является ли ход

<move n="34" piece="N" from="b5" to="c3" display="Nc3"/>

допустимым с точки зрения правил шахмат? Есть ли в этот момент на доске конь на поле b5? Свободно ли поле c3? Не открывает ли этот отскок шах королю? Ошибки такого рода достаточно часты в PGN.

Второй вопрос состоит в том, что восстановление после ошибок в текстовом файле проще. По не прочту я три партии из десяти тысяч. Бог с ними. А вот как обстоят дела в этом случае с XML, я честно говоря, не в курсе. Можно ли как-то из поврежденного XML вытащить максимум данных?

← →
Игорь Шевченко © (2009-05-25 02:45) [90]

Mystic © (25.05.09 02:37) [89]

> Можно ли как-то из поврежденного XML вытащить максимум данных?

Все зависит от семантики и парсера.

> На XML я могу проверить синтаксис, но вот легкой проверки
> семантики я не вижу. Как легко определить, является ли ход
>
>
> <move n="34" piece="N" from="b5" to="c3" display="Nc3"/>
>
> допустимым с точки зрения правил шахмат?

По меньшей мере можно проверить, что ход

<move n="34" piece="N" from="n5" to="c9" display="Nc3"/>

допустимым не является, не привлекая дополнительных валидаторов.

> Есть ли в этот момент на доске конь на поле b5? Свободно
> ли поле c3?

XML вообще-то декларативный язык, потому выражения "в этот момент" мне не представляются осмысленными именно с этой точки зрения.

← →
T&F (2009-05-25 16:06) [91]

Господа, простите, что помешаю дискуссии насчёт "какашка ли XML или не совсем какашка", а также верну обсуждение к сабжу - выбору XML-парсера:

> Насчёт парсеров - тоже актуальный
> вопрос для меня. Хочется услышать мнение об OmniXML. Что
> за зверь? Кто с ним работал? С чем можно сравнить по скорости?
> В идеале бы даже неплохо кусочек кода, чтобы оценить основные
> возможности, но это уже второстепенное

Итак, кто использовал OmniXML? Если никто - признавайтесь :)

И ещё раз - TXMLDocument - класс, супер, лучший вариант для делфи, однако ещё раз повторюсь, что он тормознутый для обработки приличных размеров файлов, а также "педант" - не переваривает малейшие ошибки в структуре XML-документа и тут же заматерится error-ами, хотя сторонние парсеры могут в этом случае продолжить парсинг дальше

Поэтому хочется альтернативу. Судя по ветке, тут все либо используют биндинги, либо свои наработки, которые невозмодно сюда запостить, так как они слишком индивидуальные, либо не используют XML из принципа ))) Вопрос - есть хоть кто-то, кто использует сторонний более-менее известный сторонний парсер? В интернете вообще что-то по этому поводу глухо, какие-то факты и сравнения столетней давности, хочется услышать СВЕЖЕЕ МНЕНИЕ, свежую информацию :) АУ!

PS: взрослые дяди, а насчёт таких вопросов спорите :) XML - естественно не панацея, но и не стоит его сравнивать с реестром или INI-файлами. Выбор способа сохранения данных определяется индивидуально для каждого случая (и для каждого индивидуума, так и хочется добавить), это ж ежу понятно. XML иногда вредит своей избыточностью, например, реестр - не подойдёт для хранения крупных массивов данных (разве что в Windows 7 можно этим заняться: теперь чтение выполняется из файла подкачки и обращения в реестр не требуют размещения данных в таблице памяти), INI - часто заставляют тратить силы на защиту "от дураков" (если программа ориентирована на аудиторию с шаловливыми пальчиками, то пальчики так и стараются что-то там изменить. Залезть в XML решаются лишь самые отважные :) само собой, "дуракозащита" должна быть в каждой программе, хоть XML там юзают, хоть INI, но есть случаи, когда нужно сэкономить на этом драгоценное время, хоть и вопреки качеству).
JSON - вещь хорошая, но это именно альтернатива XML, использовать её для чего-то, кроме веб-программирования (обмен информацией через AJAX), как-то даже неприлично, imho, а уж для Delphi-программ o_O

PPS: ну вот. сам ввязался в спросы и нафлудил. Хотя интересуюсь только ХОРОШИМ ПАРСЕРОМ ;-)

← →
Медвежонок Пятачок © (2009-05-25 16:21) [92]

TXMLDocument - для студентов,школьников и их лабораторных.

наш выбор - IXMLDOMDocument.
если данных на гигабайты - sax парсер от того же MS

проверено, шустрее не бывает чтобы использовать что-то другое.

← →
Sergey Masloff (2009-05-25 16:25) [93]

T&F (25.05.09 16:06) [91]
>И ещё раз - TXMLDocument - класс, супер, лучший вариант для делфи
TXMLDocument это просто обертка над msxml. Никогда его не использовал. Чем он лучший не знаю.

Сам msxml никаких проблем с производительсностью не имеет (последний раз его производительность смущала в версии 2.6 с тех пор все хорошо). Есть и DOM и SAX. Что еще надо?

Какие размеры документов вызывают проблемы?

← →
Sergey Masloff (2009-05-25 16:27) [94]

Медвежонок Пятачок © (25.05.09 16:21) [92]
>если данных на гигабайты - sax парсер от того же MS
+ 1
мегабайт до 100 DOM вполне прилично работает.
Дальше не пробовал - зачем если для SAX размер вообще значения не имеет

← →
sniknik © (2009-05-25 16:38) [95]

> JSON - вещь хорошая, но это именно альтернатива XML, ...
> а уж для Delphi-программ o_O
а чего нет то? во всяком случае парсеры самые свежие прямо на родном сайте для всех языков включая дельфи выложены. и есть все возможности xml. + скорость разбора быстрее TXMLDocument. - многие xml-ные заморочки.
не этого ли тебе желалось?
если выбирать "индивидуально для каждого случая" то ничего у тебя такого нет почему бы он не подошел. или это все таки дань моде на поводке у мифов? (тут однозначно, json отдыхает)

← →
T&F (2009-05-25 16:41) [96]

> Sergey Masloff (25.05.09 16:25) [93]
> T&F (25.05.09 16:06) [91] >И ещё раз - TXMLDocument -
> класс, супер, лучший вариант для делфиTXMLDocument это просто
> обертка над msxml. Никогда его не использовал. Чем он лучший
> не знаю.

Я кажется уже запутался. Похоже уже под TXMLDocument подразуеваю и msxml

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

А как насчёт этого?

← →
Медвежонок Пятачок © (2009-05-25 16:42) [97]

а как насчет поддержки этого джейсона на sql серверах?

← →
sniknik © (2009-05-25 16:49) [98]

> Какие размеры документов вызывают проблемы?
SAX не пробовал, а DOM где то от 500 мг. попросту виснет (для пробы можно открывать в IE, он его тоже через DOM обрабатывает). а на чтобы составить файлик 2гб, людям знаю, пришлось на сервере с 16гб оперативки неделю обработку выполнять...
сколько бы потребовалось чтобы его открыть не знаю, я сразу отказался это делать (и не потому, что думал, что не смогу или подобное, а потому что знал, нужных мне данных там нет, по определению, зная как и формат его составления. (нужен был простой бэкап базы mssql)).

> а как насчет поддержки этого джейсона на sql серверах?
хреново, нет у него поддержки от MS.

← →
Sergey Masloff (2009-05-25 16:54) [99]

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

>А как насчёт этого?
ISAXErrorHandler реализовать например

← →
Sergey Masloff (2009-05-25 16:55) [100]

sniknik © (25.05.09 16:49) [98]
>
>сколько бы потребовалось чтобы его открыть не знаю, я сразу отказался >это делать (и не потому, что думал, что не смогу или подобное, а потому >что знал, нужных мне данных там нет, по определению, зная как и формат >его составления. (нужен был простой бэкап базы mssql)).
Да ты описывал тот случай. Для той задачи это конечно была бредовая идея заказчиков ;-)

← →
T&F (2009-05-25 17:03) [101]

> ISAXErrorHandler реализовать например

Хм.
http://rsdn.ru/forum/xml/292647.flat.aspx
Это видно тоже не панацея

← →
Игорь Шевченко © (2009-05-25 17:04) [102]

sniknik © (25.05.09 16:49) [98]

Можно конечно и видео в XML передавать, дурное дело нехитрое. Только вот беда какая - сам XML тут не причем, как не причем TMemo, применяемое для чтения текстового файла и последующей обработки строк, компрене ву ?

← →
sniknik © (2009-05-25 17:05) [103]

> Для той задачи это конечно была бредовая идея заказчиков ;-)
если бы заказчиков, это наш "гениальный" менеджер договорился, настоял прямо таки, и заказчиков напряг, и нас подставил (я бы с их стороны точно подумал что имею дело с идиотами).

← →
sniknik © (2009-05-25 17:08) [104]

> сам XML тут не причем
я не говорил что он при чем, причем то что его навязывают, причем люди в этом совершенно не соображающие, на поводу у менеджмента.

← →
makvell (2009-05-25 17:16) [105]

а какой топик был... :)

← →
Sergey Masloff (2009-05-25 17:23) [106]

T&F (25.05.09 17:03) [101]
>http://rsdn.ru/forum/xml/292647.flat.aspx
Вы всегда форумы вместо документации читаете? Плохая привычка.
Чтобы обрабатывать результат возвращаемый методами ISAXErrorHandler вообще-то нужно свойства ридера настроить.
Естественно если это FatalError парсинг остановится в любом случае. Для просто error останавливается ПО УМОЛЧАНИЮ также вне зависимости от возвращаемого результата. Это можно изменить.

← →
Sergey Masloff (2009-05-25 17:28) [107]

Игорь Шевченко © (25.05.09 17:04) [102]
>Можно конечно и видео в XML передавать, дурное дело нехитрое.
А почему дурное? Иногда и видео передают. Если это видео привязано к другим данным иногда довольно удобно в одном флаконе иметь. Я делал интерфейс к одной системе в которой хранятся результаты испытаний. Они как раз отдают все одним xml файлом - там условия проведения, видеосъемка опыта и фото результатов. А дальше обрабатывай как хочешь. Не скажу что однозначно лучшее решение но вобщем-то и не самое плохое.

← →
Игорь Шевченко © (2009-05-25 17:45) [108]

Sergey Masloff (25.05.09 17:28) [107]

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

← →
T&F (2009-05-25 18:10) [109]

> Вы всегда форумы вместо документации читаете? Плохая привычка.

Нет, форумы - для быстрой оценки возможных проблем, почитать отзывы и всё такое прочее

Вообще-то вообще не хотел кидать ссылку эту, самому показалась проблема слишком искуственной.

> [104] sniknik © (25.05.09 17:08)

В качестве примера, экспорт/импорт данных в 1С, пробовал варианты: OLE, dbf, XML.
Ole - просто, но очень медленно.
dbf - приходится создавать кучу таблиц под разные справочники, деревья.
xml - скорость на 10-20 тыс. записей сопоставима с dbf, но проще и удобней,
ничего не нужно придумывать, структура древовидного справочника, мастер/деталь
переносится 1-1.
У меня в программе в XML храняться все настройки интерфейса, меню/тулбары/позиции и настройки окон,
с трудом представляю более удобный формат хранения.

xml - скорость на 10-20 тыс. записей сопоставима с dbf, но проще и удобней
А чем проще? Отнюдь не проще, особенно при последующем его использовании и скорость будет не сопоставима

> [111] blackman © (25.05.09 22:04)
> А чем проще? Отнюдь не проще

Проще тем, что например, нужно выгрузить документы и связанные с ними 2-5 справочников.
Придется создавать под каждого справочника таблицу, для документов по несколько таблиц.
Все это делать в динамике. Т.к справочники древовидные, то нужно выгружать дерево
например ID <-> PARENT_ID.
Соответственно при загрузке, необходимо грузить дерево от корня, и если для SQL я могу получить
упорядоченное дерево 1 запросом, то тут ручками.
А в XML дерево выгружается/загружается "нативно".
В общем все это пробовали, для XML кода в 2-3 раза меньше.

> Отнюдь не проще, особенно при последующем его использовании
> и скорость будет не сопоставима

А чего ей сильно отличаться? Скорость выгрузки одинаковая, что dbf, что xml по сути текстовые файлы.
Скорость загрузки зависит от того как разбирать деревья в dbf, но на глаз примерно как и XML.
Ну и размер файла выгрузки у XML меньше. Несмотря на теги.

А я заюзал libxml. Написал пару классов-оберток и живу не тужу :)

Хранить конфиги в XML — МОВЕТОН.

Иерархические структуры записей лучше хранить в виде:
кагория.подкатегория.параметр="значение"
Никакого парсера не нужно — достаточно лишь вызвать properties-ридер и загнать значения в хэш-таблицу.

> кагория.подкатегория.параметр="значение"

+1
Такое мне нравится.

Все зависит от ситуации. Нет идеальных решений )

> Иерархические структуры записей лучше хранить в виде:
> кагория.подкатегория.параметр="значение"

неудобно

Структура DFM, кстати, напоминает XML :)

> Иерархические структуры записей лучше хранить в виде:

Я еще видел вариант, когда иерархия записывается примерно так:

[Delphi/Compiler] APPTYPE=CONSOLE IMAGEBASE=$04000000 [Delphi/Directories] SearchPath=...

Парсер XML Найти похожие ветки