В общем, я для себя уже давно определился в пользу SAX, т.к. при этом не обязательно полностью загружать весь поток данных, а обрабатывать их по мере поступления => совмещения цикла чтения и цикла обработки данных, снимает опасность переполнения буфера или свопа. Это конечно определяющее. В добавок для меня это наиболее понятная технология. DOM как дремучий лес, т.е. я его, при необходимости, осваиваю, пишу код и на следущий день ну ни чего не помню.
Только вот ведь не задача, везде встречаются примеры DOM парсеров, а SAX подаётся как своё отжившая технология.
Суть поста следующая:
Кто на нас с SAX?
И кто за нас?)))

Эээ... Ну во-первых это просто разные подходы. SAX менее требователен к памяти (читай - не требователен к памяти). Это просто парсер. А DOM - это модель всего документа.

ЗЫ Есть ещё куча походов к разбору XML-документа. А вообще XML Schema + xsd-транслятор рулят в готовый класс (также есть два варианта: SAX-style vs DOM-style)  

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

У тебя есть xml небольшого размера, тебе нужно получить одно какое-нибудь поле.
Что легче - загнать в память и быстро его вытянуть или написать Сакс-Хендлер? А таких примеров еще куча можна придумать. Для разных задач  - разные решения.

Не совсем так. Ты предполагаешь, что у тебя не большой xml =). А так предполагать можно не в промышленных масштабах.

 
Ты думаешь в "промышленных масштабах" только мега-большие хмлки?   
 Ну тут я уже ничем не могу помочь, каждый остается при своем   

Нет, я думаю, что нельзя делать предположения о входных данных. Если прога берёт поток из внешнего источника, то должна работать при любом количестве входных данных (и их корректности). А если прога использует свой внутренний поток, то тогда на кой xml?

1. Модифицировать дерево и сохранить его обратно.
2. Многократные, непоследовательные запросы к различным узлам дерева.



А проверить входные данные на длину задача не реализуемая? 


Да и вообще это уже какая-то параноя начинается. Одно дело от защищаться от вторжения извне, другое дело обмен данными внутри одной организации.

А внутри этой организации у всех прямые руки?


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



Вот для этого я дом обычно и юзаю.


Ну смотря сколько этих запросов и какой объём данных, порой бывает проще загнать документ в БД, и в неё непоследовательные запросы пихать (обычно это быстрее, чем xml), можно также сначало выслушать запросы, а потом формировать поведение парсера. Тут надо смотреть по ситуации, если перечисленное не возможно или нерационально - ДОМ рулит!

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

Ошибки бывают всегда и не всегда это связанно с кривизной рук, главное что ошибка исправима.



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



К БД нельзя выполнить XQuery запросы.


А вообще Любитель, правильно расписал, что такое DOM и что такое SAX.

Прав, но всегда ли нужна вот эта байда для работы приложения?

Мой не большой опыт подсказывает, что как правило не нужна. Если ещё честнее, то тот же опыт подсказывает, что формат xml для многих задач (которые всё таки им решаются) избыточен, но это оставим за кадром.
Ещё, если можно, такой вопрос: Вы всегда при работе с xml только DOM-объектами пользуетесь, или всё же  приводите их к строковым и целочисленным (ну или из ряда BigInteger, BigDecimal) значениям?
Просто если второе, то получается дублирование одних и тех же данных, что не так плохо, если такое дублирование не в большом количестве и оч. хорошо контролируется, а то опять прейдётся стонать про утечку памяти.
P.S. Я, наверно, уже кажусь религиозным проповедником, просто возмущает, когда приходит код для сервера с "предположением", что своп окажется больше, чем файл =).

Это сообщение отредактировал(а) Aikus - 15.4.2008, 13:56

Я уже писал:

Как _конкретно_ он работает - меня не особо волнует (хорошая реализация рабоает хорошо  ).

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

Взять хоть тот же XHTML из JavaScript`а - в браузерах SAX не реализован в принципе, да и что бы это было? В современном Web-интерфейсе нужно постоянно лазать по документу, изменяя его в соответствии с действиями пользователя и подгружаемыми данными с сервера в асинхронном режиме, и документ уже находится в памяти браузера, потому что его надо отображать.

Иногда нужна, иногда нет. Нельзя же не зная задачи, сказать что лучше применять.

Мне например очень нравится JAXB, работать намного приятней и удобней чем с SAX или DOM. А по сути это ускоспециализированный DOM.

У меня был случай: была система, в ней хранилось дерево объектов. Причем дерево само по себе очень нетривиальное, у каждого объекта есть список свойств (произвольной длинны), список методов (тоже произвольный), список событий и список состояний. Т.е. фактически это был универсальный описатель системы. Было одно дерево которое хранилось в БД и другое которое приходило в виде XML. Эти два дерева надо было сравнить, если они совпали то все ОК, если не совпали новое записать в БД, а старое пометить как невалидное. Если бы я это делал с помощью SAX, я бы наверное повесился. А с помощью JAXB+Hibernate все прошло легко и гладко, просто рекурсивное сравнение двух деревьев объектов по полям.