Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > XML, XSL > Особенности парсеров xml.

Автор: DubrovinAV 13.10.2007, 15:34

Здравствуйте. Стоит задача: написать парсер XML(именно с нуля, т. к. является итоговым проектом в институте). В результате парсинга нужно преобразовать xml->html и показать иерархическую структуру исходного документа(xml). С выводом результата определился, html, а точнее xhtml получим, собрав программно к нему xsl, вывод структуры буду осуществлять опять же в html посредством списка: Код <ul>     <li>ИмяЭлемента</li> </ul> Решать задачу "в лоб" не хочется(поймете чуть ниже). Я считаю лучше использовать уже готовое решение - SAX анализатор(DOM все же для такой задачи не обоснован)). Дело в том что нужно написать в первую очередь, как я понимаю это задание, парсер. Используя метод SAX в результате получим универсальный код, который можно использовать не только для представления xml->xhtml, но и для поиска и получения интересующих данных. За последнюю неделю перечитал много информации в интернет, накачал книжек. Так вот хочется узнать все же особенности данного метода анализа документа, т. е. то каким должен быть "настоящий" парсер. Нужно ли обрабатывать DTD-определения,  анализировать область CDATA и инструкции или же пропускать, проверять соответствии спецификации. Хочется все же узнать те моменты которые все же нужно воплотить в программе. Конечно я понимаю что все зависит от поставленной задачи, но... Дело в том что нужно написать качественную программу, от ее защиты многое зависит. Спасибо.

Автор: Shedar 13.10.2007, 17:57

Уточните, что Вы подразумеваете под  Цитата(DubrovinAV @  13.10.2007,  15:34 ) Я считаю лучше использовать уже готовое решение - SAX анализато Подразумеваете свою реализацию указанного API или использование готовой реализации SAX парсера? По фразе вроде бы второй вариант,  но тогда не согласуется с  Цитата(DubrovinAV @  13.10.2007,  15:34 ) написать парсер XML(именно с нуля Если использовать готовую реализацию, то она сама и CDATA проанализирует и DTD и валидацию проведет если нужно. Если же речь идет о собственной реализации. CDATA нужно анализировать  в любом случае, поскольку внутри секции могут встречаться угловые скобки и нужно их отличать от начала тега. DTD нужно обрабатывать, если реализация претендует на более-менее универсальность, поскольку в DTD могут описываться сущности  (entity), ссылки на которые потом будут в документе, соответственно невозможно раскрыть ссылки не проанализировав DTD. Что касается валидации, зависит от задачи.

Автор: DubrovinAV 13.10.2007, 19:24

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

Автор: Shedar 13.10.2007, 21:37

CDATA - область которая не анализируется парсером на наличие спецсимволов. Если мне нужно будет написать фрагмент кода в xml, то я могу написать  Код <![CDATA[ If(a < b && b>c && c<d) ]]>  без CDATA это должно выглядеть вот так:  Код if(a &lt; b &amp;&amp; b &gt; с &amp;&amp; c &lt d)) что касается валидности. в англ. языке есть два термина, применимых к xml wellformed - документ являющийся синтаксически корректным (соответствует спецификации) valid - документ являющийся структурно корректным, т.е. соответствует спецификации и описанию структуры документа (DTD, XML-schema, RELAX NG и т.д.)

Автор: DubrovinAV 20.10.2007, 16:37

Приветствую. Какая структура у тега? Поправьте если что не так   Общий вид: Код <NameSpace1:NameElement NameSpace2:NameAttribut1="Value1" NameSpace3:NameAttribut2="Value2" ...> ... </NameSpace1:NameElement> В в некоторых исходниках sax-парсера в функции startElement(...char* qName...); после параметра nameElement иногда указывается параметр qName. Не знаете для чего он, для каких целей в этой же функции сохранять информацию о длине имени и атрибутов?

Автор: DubrovinAV 23.10.2007, 16:15

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

Автор: LSD 23.10.2007, 20:26

Цитата(DubrovinAV @  20.10.2007,  17:37 ) Не знаете для чего он, для каких целей в этой же функции сохранять информацию о длине имени и атрибутов? Это http://www.w3.org/TR/REC-xml-names/#ns-qualnames.

Автор: DubrovinAV 24.10.2007, 08:15

Цитата Это qualified name. А чем полное имя отличается от пространства имен?

Автор: LSD 24.10.2007, 14:58

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

Автор: DubrovinAV 24.10.2007, 15:23

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)