Как работает анализатор?
XML в воздухе не висит.
Чтобы работать с XML существует программные анализаторы, т.е. синтаксические разборщики XML.
Программа, которой дали файл, он его прочитал и что-то с ним сделал.
Анализатор - парсер (разборщик). Их очень много. Почти во все программные средства парсер входит: в PHP несколько парсеров, в винде (msxml), java, flash, java script.
2 подхода у XML по сбору:
SAX - Simple API of XML - простой программный интерфейс по работе с доступа к XML-файлов. Старый, быстрой, мало юзается.
DOM - document object model. Задача анализатора прочитать такой файл (документ с данными) для того, чтобы как-то его представить, например, занести документ в базу данных или чтобы мы могли его модифицировать, обработать.
Он воспринимает так: то, что мы написали - это текст. Когда анализатор его прочитает, он его прдставляет в виде дерева объектов. С этим деревом все и работает.
ДОМ - это целая спецификация, причем не одна.
Идея представления в виде дерева.
Фактически вся обработка XML делается в виде дерева. Смысл очень простой. Куда ни плюнь в XML - это объект.
Когда документ в виде текста - это набор строчек.
Как только загружается машиной, он становится набором объектов, которое представляет собой дерево, от некоего родоначального корневого, главного узла подвложенные и прочее. Что является объектом XML? Все.
Тег, элемент - дерево.
Текст - узел дерева.
Атрибут - узел дерева.
Коммент - узел дерева.
Процессинговая инструкция - узел дерева.
ВСЕ является узлом дерева.
Мы смотрим на XML, представляем дерево.
Например, файлик (аттач ниже). Есть сам документ - это объект. У него есть дочерние узлы. Это процессинговая инструкция, корневой элемент, вложенный в корень узел, в общем, все, включая сам текст.
Все, кроме декларации. Хоть она и записывается как инструкция по обработке, на самом деле это просто указание парсеру как открыть документ. И он, когда открывает документ, не делает это отдельным узлом. Это просто указание анализатору, что, мол, используй такую кодировку. Все остальное полностью дерево.
Машина, грубо говоря, уже работает не с текстом, а с этим голубеньким.
Когда мы работаем с XML к нам могут приходить в парсер совершенно разные документы. Если они не нарушают синтаксиса, т.е. well-formed, парсер честно строит деревья. Но это дерево узлов, документ, может быть не для нас. И просто огульно его обработать бывает не совсем правильно. Ведь документ может быть неполным, не все указано, не та структура, данные некорректные. Чтобы мы могли это отсеять (а это называется валидация, проверка) буквально на этапе его обработки, эта задача стоит в 9 из 10 случаев.
В XML необходимо иметь способ однозначно определить кому машине, не человеку, как эта структура, в каком виде документ вообще должен существовать. Т.е. по-другому - определить грамматику.
Грамматики нет, она у меня в голове, но я хочу, чтобы она была у программы, парсера.
Конечно, можно написать прогу, которая будет по этому дереву пробегаться и смотреть, все ли там в порядке, но это долго и некультурно, ибо для одной проги будет нужна одна структура, для другой - другая и т.д. Поэтому разработчики пошли по принципу декларативности. Они говорят так: пускай сам парсер все проверяет. Нужен декларативный стандарт, т.е. набор правил, описанный ему один раз без всякого программировавния, без ничего, как должно быть. А он уже должен проверять, насколько это подходит к этому "как должно быть".
И этот способ описания структуры и есть. Их два:
DTD - Document Type Definition - очень древний способ. Это определение типов документов.
ДТД - набор сокращений, т.е. целый язык как XML, язык описания, который позволяет указать нам, какие теги мы ждем, т.е. какие элементы в нашем документе должны быть, насколько они имеют право повторяться, какие атрибуты есть, какие из них обязательны, какие сущности могут использоваться.
XML в воздухе не висит.
Чтобы работать с XML существует программные анализаторы, т.е. синтаксические разборщики XML.
Программа, которой дали файл, он его прочитал и что-то с ним сделал.
Анализатор - парсер (разборщик). Их очень много. Почти во все программные средства парсер входит: в PHP несколько парсеров, в винде (msxml), java, flash, java script.
2 подхода у XML по сбору:
SAX - Simple API of XML - простой программный интерфейс по работе с доступа к XML-файлов. Старый, быстрой, мало юзается.
DOM - document object model. Задача анализатора прочитать такой файл (документ с данными) для того, чтобы как-то его представить, например, занести документ в базу данных или чтобы мы могли его модифицировать, обработать.
Он воспринимает так: то, что мы написали - это текст. Когда анализатор его прочитает, он его прдставляет в виде дерева объектов. С этим деревом все и работает.
ДОМ - это целая спецификация, причем не одна.
Идея представления в виде дерева.
Фактически вся обработка XML делается в виде дерева. Смысл очень простой. Куда ни плюнь в XML - это объект.
Когда документ в виде текста - это набор строчек.
Как только загружается машиной, он становится набором объектов, которое представляет собой дерево, от некоего родоначального корневого, главного узла подвложенные и прочее. Что является объектом XML? Все.
Тег, элемент - дерево.
Текст - узел дерева.
Атрибут - узел дерева.
Коммент - узел дерева.
Процессинговая инструкция - узел дерева.
ВСЕ является узлом дерева.
Мы смотрим на XML, представляем дерево.
Например, файлик (аттач ниже). Есть сам документ - это объект. У него есть дочерние узлы. Это процессинговая инструкция, корневой элемент, вложенный в корень узел, в общем, все, включая сам текст.
Все, кроме декларации. Хоть она и записывается как инструкция по обработке, на самом деле это просто указание парсеру как открыть документ. И он, когда открывает документ, не делает это отдельным узлом. Это просто указание анализатору, что, мол, используй такую кодировку. Все остальное полностью дерево.
Машина, грубо говоря, уже работает не с текстом, а с этим голубеньким.
Когда мы работаем с XML к нам могут приходить в парсер совершенно разные документы. Если они не нарушают синтаксиса, т.е. well-formed, парсер честно строит деревья. Но это дерево узлов, документ, может быть не для нас. И просто огульно его обработать бывает не совсем правильно. Ведь документ может быть неполным, не все указано, не та структура, данные некорректные. Чтобы мы могли это отсеять (а это называется валидация, проверка) буквально на этапе его обработки, эта задача стоит в 9 из 10 случаев.
В XML необходимо иметь способ однозначно определить кому машине, не человеку, как эта структура, в каком виде документ вообще должен существовать. Т.е. по-другому - определить грамматику.
Грамматики нет, она у меня в голове, но я хочу, чтобы она была у программы, парсера.
Конечно, можно написать прогу, которая будет по этому дереву пробегаться и смотреть, все ли там в порядке, но это долго и некультурно, ибо для одной проги будет нужна одна структура, для другой - другая и т.д. Поэтому разработчики пошли по принципу декларативности. Они говорят так: пускай сам парсер все проверяет. Нужен декларативный стандарт, т.е. набор правил, описанный ему один раз без всякого программировавния, без ничего, как должно быть. А он уже должен проверять, насколько это подходит к этому "как должно быть".
И этот способ описания структуры и есть. Их два:
DTD - Document Type Definition - очень древний способ. Это определение типов документов.
ДТД - набор сокращений, т.е. целый язык как XML, язык описания, который позволяет указать нам, какие теги мы ждем, т.е. какие элементы в нашем документе должны быть, насколько они имеют право повторяться, какие атрибуты есть, какие из них обязательны, какие сущности могут использоваться.
Комментариев нет:
Отправить комментарий