OberonCore

Дерево XML-документа целиком присутствует в памяти. Если так, такая реализация не сгодится для гигантских файлов размер которых исчисляется в Гб (как я понял в Седне именно такие размеры). Нужна специальная. Но она есть - сама Седна с ее АПИ.

Если говорить о файлах в несколько мегабайт, то можно попробовать такой вариант:
- файл целиком вгружается в память;
- при построении дерева никаких дин. строк не делается, используются ссылки типа (pos, len) на содержимое файла;
- когда дерево построено и все (pos, len) зафиксированы - сделать их копии в виде обычных строк POINTER TO ARRAY OF CHAR, а файл выгрузить.

Это получается парсинг в два прохода... Сначала создаём DOM дерево с пустыми строками, и запоминем "координаты" строк в исходном тексте, потом проходим по списку "строка<=>координата" и заполняем строки... Здесь и пригодится скрытие реализации парсера, так как такой механизм не всегда будет нужен, например при работе с файлами малых размеров(много меньше мегабайта) выйгрыш в скорости по сравнению с теперешним механизмом будет минимальный.

Ну я сильно сомневаюсь, что Седна внутри работает с целыми деревьями XML... А размеры там действительно могут быть большие - недавно авторы засунули содержимое английской части Википедии (21 Гб) в Седну (см. http://xmlhack.ru/ и http://wikixmldb.dyndns.org/).

Кстати, наш 4-х метровый файл рендерер SVG входящий, в качестве примера, в AGG (http://antigrain.com/) так и не отобразил.

Я имел ввиду нами обсуждаемый парсер (внутри не смотрел, каюсь, поэтому высказал как предположение). И то, что для гигантских файлов целиком дерево хранить в памяти не прокатит, нужен спец подход. Который уже есть в Седне.

на всякий случай...

Google предложил заменитель XML

Google 7 июля предложил всем желающим использовать язык Protocol Buffers, позволяющий описывать данные эффективнее, чем XML

Файл с данными в Protocol Buffers меньше XML-файла в 3-10 раз.

разбор этих данных .. быстрее в 20-100 раз.

В отличие от XML, Protocol Buffer не предназначен для чтения пользователем.
+ необходим отдельный .proto-файл, в котором определяется формат сообщения.

Protocol Buffers разработан в 2001 и используется самим Google практически везде, где требуется хранение структурированной информации.

2008-07-09

Спасибо, это важно (правда для другого). Источник: http://lenta.ru/news/2008/07/08/google/

Ещё сюда: http://code.google.com/apis/protocolbuf ... rview.html

Неплохой формат для сообщений - перманентности простых данных...
(НЕ для замены XML в информационных системах с серьёзными схемами данных).

Проще говоря, некоторый аналог BlackBox Stores.
Для передачи сообщений делали мы и свой подобный протокол в BlackBox...

Гуглы активны в продвижении формата, сразу дают библиотеки для работы(Java, Python, C++) с форматом. "Берите, пользуйте готовое, привязывайтесь к формату Google..." Правильный подход.

Это несомненно. Политика партии.

Однако, это дело всё равно о интересно. И знать о нём нужно.

OFFTOP
Есть и еще интересный подход к описанию сложних структур данних и обработке этих самих данных - http://www.lua.org/pil/10.1.html
Похожий подход наверное можно реализовать и в ББ используя Meta

Ничего особенного (для Луа) - это лисповые списки - S-выражения, как они называются в Scheme.
Специально под них есть стандарт SXML, где XML Information Set отображается не в <>-теги, а в S-выражения.

СУБД Седна, кстати, может отдавать результат запросов как в том, так и в другом виде (если не ошибаюсь, то и ввели впервые эту штуку ребята из ИСП-РАНа - Дмитрий Лизоркин..).

http://en.wikipedia.org/wiki/SXML

У меня вот есть реализация S-выражений под ББ (правда, я брал за образец не Лисп, а Рефал, но это полностью изоморфно) - и собираюсь их использовать для работы с XML/XQuery.

Прикреплено к существующей теме

от неё требуется
хранение этого в читаемом файле
произвольный доступ к любому элементу (нечто вроде Xpath)
НЕ смертоносные требования к памяти

Помогите, плиз!

Создал ветку 1.6/Xmlcore

У меня такой вопрос: можно ли использовать компонент Xmlcore в виде скомпилированной библиотеки?

Если да, то

1. Сколько будет она "весить" (PE/ELF)?
2. Есть ли внешние зависимости?

А ЗАЧЕМ?

Xmlcore для среды BlackBox. Если xml нужен отдельно от ББ - таких библиотек навалом.

По сути, мне нужно даже подмножество XML для хранения настроек программы и поэтому требуется компонент для Оберон-2 или библиотека малых размеров с описанием интерфейса на Обероне-2/КП. Библиотеки С/С++/Java нудно переводить, желательно готовые компоненты.

Что можешь посоветовать?