OberonCore

Приветствую!
Где то с год назад был разговор на форуме про создание подсистемы по работе с XML. Спор разгорелся на концептуальном уровне... и затих.
Совсем недавно производственная необходимость заставила вернуться к теме XML. Были изучены стандарты организации w3c http://www.w3c.org Document Object Model http://www.w3.org/DOM/ и eXtensible Markup Language http://www.w3.org/XML/.

DOM представляет собой интерфейсное описание структуры для хранения данных документа (изначально HTML). В основе лежит класс Узел дерева, который посредством расширения приобретает ту или иную функциональность для описания различных по содержанию и назначению фрагментов документа. Был реализован только начальный, самый первый уровень спецификации DOM, т.н. Level 1. Сейчас существует уже Level 3 со значительно расширенными возможностями.

XML представляет собой указания по разметке текста документа тегами, группы которых могут интерпретироваться специальными программами-процессорами(XML Processor) особым образом. Была реализована (не полностью) версия 1.0 редакция 4 данного стандарта. Из-за того, что название подсистемы "Xml" уже значится в списке занятых на сайте Ominc., подсистема была названа Xmlcore.(здесь была бы уместна идея пространства имён подсистем, например Ominc.Xml, Yaroslavl.Xml и т.д. - мысли вслух ). В качестве основы для XML парсера(обработчика текста xml-документа) был взят парсер, включёный в состав WinAOS. Нереализованными остались обработка Нотаций(Notation), Деклараций разметки(Markup declaration), Сущностей(Entities) и Ссылок на сущности(Entity reference)(обратитесь к описанию XML для подробной информации).

Итог работы: Dom level 1 реализован. Xml 1.0 частично реализован. Формат выходного и входного файлов: текст с кодировкой UTF-8. Используется подсистема Basics для работы с динамическими строками. Есть демонстрационные программы для обеих подсистем. Документации пока нет.

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

(модератор) 09.12.2010 размещено в коллекции: http://oberoncore.ru/bbcc/subs/xmlcore/

XML — это не только DOM, но ещё и SAX.

SAX, DOM - это всего лишь "углы взгляда" на документ в формате XML. Программные интерфейсы (API).

http://www.ibm.com/developerworks/ru/ed ... tion5.html

Стандарт SAX (http://www.saxproject.org) не является стандартом W3C. С помощью SAX можно только прочитать данные из XML-документа. Создавать и изменять XML-документы с его помощью невозможно.

DOM – стандарт W3C. Позволяет производить любые операции с XML-данными в достаточно удобной форме – представляя XML-документ как дерево объектов. Главный недостаток DOM - необходимо построить дерево документа сразу, загрузив документ в память целиком. На больших файлах начнутся тормоза и съедание памяти.

XML - это XML. SAX это отдельная песня. Хотя если есть желание - реализуйте, лишним не будет...

Его можно преодолеть, реализовав модуль загрузки файла по частям, для этого можно использовать особый тип интерфейса DOM - DocumentFragment.

По идее, фрагментирование DOM должно быть абсолютно прозрачно. Я работаю чисто с DOM, а как конкретная реализация подгружает части XML-документа, знать не должен.

Сейчас, Dom не связан с Xmlcore. Он сам по себе. Xmlcore импортирует Dom и производит с ним различные операции. Если потребуется обеспечить обратную связь, то придётся вводить некий управляющий слой, с которым вы будете работать, и который будет обеспечивать подгрузку данных из файла и изменение основной Dom-струкутры, с которой вы уже НЕ будете работать напрямую. Тогда самый удобный вариант для вас - получать по запросу фрагменты документа и обрабатывать их, затем отправлять обратно(если потребуется)

Интересно, а как оно там в XML СУБД делается... Типа "Седны" ИСП РАН-овской... Какие там интерфейсы...

Почитал про Седну, очень интересно. Как я понял, у них полностью свой движок. Такая XML-СУБД может работать прослойкой между интерфейсом DOM и XML-документом.

http://www.citforum.ru/database/article ... va06.shtml

Хм... от XML не далеко до реализации SVG...

А это насущный вопрос? SVG - тот ещё формат. Я недавно в википедии рылся, картинка в jpeg занимает 400 кб, та же самая картинка в svg - 1,5 мб и вешает Оперу

Это полезный формат... это векторный формат, к тому же стандартный.

Тем более с учётом уже упоминавшегося здесь где-то AGG (http://antigrain.com/).

Более того, векторная рисовалка InkScape, коей лично я пользуюсь заместо Корела - как раз хранит картинки в формате SVG.
И этот формат, он не только стандартный, а ещё и открытый.

Да будь он трижды стандартный и одиннадцатижды открытый, формат - говно.

Личностное неприятие?

Вести с полей

Сделал DOM Level 2 и прикрутил к Xmlcore поддержку XML Namespaces http://www.w3.org/TR/2006/REC-xml-names-20060816.
Ещё приделал трансляцию символов разметки в коды(как в HTML: & = "&amp;" ну и т.д.). Судя по всему, это и зовётся Entities. Для XML стандартные только: $ > < " ' остальные нужно описывать в Document Type Declaration. С ним ещё есть непонятки, если кто разбирается, подскажите, где всё это добро должно храниться, у DOM.DocumentType есть только два списка, entities и notations, не пойму, как в них уложить всё, что в спецификации по DTD?
Подсистемы прикрепил, но там немного всё сумбурно, демки дикие


Нууу, у меня Опера нормально показала тестовую картинку из Википедии. Значит, получается: формат - НЕ говно.

Как на счёт того, чтобы поставить этот проект под управление SVN?

Ммм. Было бы неплохо. Ну тогда сообщите пожалуйста параметры SVN репозитория.

Оперу запросто мог повесить Flash баннер на какой-то из закладок. То-ли баннеры кривые попадаются, то-ли плагин глючный. Вообще за Flash баннеры вбывав-бы

Flash - говно похлеще ИМХО.