Здравствуйте. Стоит задача: написать парсер XML(именно с нуля, т. к. является итоговым проектом в институте). В результате парсинга нужно преобразовать xml->html и показать иерархическую структуру исходного документа(xml). С выводом результата определился, html, а точнее xhtml получим, собрав программно к нему xsl, вывод структуры буду осуществлять опять же в html посредством списка:



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

За последнюю неделю перечитал много информации в интернет, накачал книжек. Так вот хочется узнать все же особенности данного метода анализа документа, т. е. то каким должен быть "настоящий" парсер. Нужно ли обрабатывать DTD-определения, 
анализировать область CDATA и инструкции или же пропускать, проверять соответствии спецификации. Хочется все же узнать те моменты которые все же нужно воплотить в программе. Конечно я понимаю что все зависит от поставленной задачи, но... Дело в том что нужно написать качественную программу, от ее защиты многое зависит.

Спасибо.

Уточните, что Вы подразумеваете под 

Подразумеваете свою реализацию указанного API или использование готовой реализации SAX парсера? По фразе вроде бы второй вариант,  но тогда не согласуется с 

Если использовать готовую реализацию, то она сама и CDATA проанализирует и DTD и валидацию проведет если нужно.
Если же речь идет о собственной реализации. CDATA нужно анализировать  в любом случае, поскольку внутри секции могут встречаться угловые скобки и нужно их отличать от начала тега. DTD нужно обрабатывать, если реализация претендует на более-менее универсальность, поскольку в DTD могут описываться сущности  (entity), ссылки на которые потом будут в документе, соответственно невозможно раскрыть ссылки не проанализировав DTD. Что касается валидации, зависит от задачи.

 Извиняюсь, не корректно выразился. Конечно же за основу взять алгоритм SAX-анализатора(For example, endDocument(),  startElement...), а иначе смысл в моей работе)), что касается CDATA, то если судить по книгам это область документа, которая "не инициализируется процессором", т. е. нужно нам анализировать содержимое и как-то его интерпретировать или же просто игнорировать последовательность символов между "<! [CDATA[" и "]]>"? Теперь про DTD,  его нужно анализировать только на сущности, или же есть еще что-то, о чем я пока не знаю, что, кровь из носу, надо проанализировать и обработать. Поскольку в задании не сказано о проверке, то я не собираюсь проверять соответствие документа схемам либо определениям, а проверить лишь "правописание".

Извиняюсь, валидность документа - это соответствие спецификации, так сказать правильно с точки зрения грамматики, а не соответствие схеме либо DTD, я ничего не путаю?   

спасибо за ответ

CDATA - область которая не анализируется парсером на наличие спецсимволов. Если мне нужно будет написать фрагмент кода в xml, то я могу написать 

без CDATA это должно выглядеть вот так: 

что касается валидности. в англ. языке есть два термина, применимых к xml
wellformed - документ являющийся синтаксически корректным (соответствует спецификации)
valid - документ являющийся структурно корректным, т.е. соответствует спецификации и описанию структуры документа (DTD, XML-schema, RELAX NG и т.д.)

Приветствую. Какая структура у тега? Поправьте если что не так  

Общий вид:


В в некоторых исходниках sax-парсера в функции startElement(...char* qName...); после параметра nameElement иногда указывается параметр qName. Не знаете для чего он, для каких целей в этой же функции сохранять информацию о длине имени и атрибутов? 
 

 

Структура у тега такая как я описал или что-то не учел? Прошу ответить.

Это qualified name.

А чем полное имя отличается от пространства имен?

Пространство имен это всего лишь часть qualified name. Вернее qualified name состоит из префикса пространства имен и локального имени.
Т.е. в твоем примере:
NameSpace1 - это префикс пространства имен (не само пространство, а именно его префикс, префикс обязательно должен быть предварительно сопоставлен с неким пространством имен)
NameElement - локальное имя элемента

Все понятно. Спасибо. Еще одна тайна XML раскрыта