Подсказки по проверке и методы
Проверка является процедурой, гарантирующей, что XML-документ соответствует правилам, управляющим его логической структурой, столь же указанной в схеме языка, таким как DTD (Определение типа документа). XML-документ мог бы быть правильно построен — т.е. он соблюдает синтаксические правила XML — и одновременно быть недопустимым. Например, элемент мог бы включать дочерний элемент, когда он, как предполагается, имеет только текстовое содержание, или требуемый атрибут элемента мог бы отсутствовать.
Для выполнения проверки, это помогает создать дерево схемы XML-документа, которая параллельна древовидной структуре, представляющей фактическое содержание документа (см. древовидные структуры XML Построения). Дерево схемы представляет простое абстрактное представление того, как должен быть структурирован документ. Вместо узлов объектов, представляющих фактические элементы и текст документа, дерево схемы содержит узлы, выражающие правила, по которым могут быть объединены части документа. Проверка тестирует фактические элементы, атрибуты и другие части документа против правил схемы видеть, соответствует ли документ. Если Ваше приложение находит какое-либо нарушение соответствия, это может уведомить пользователя и возможно потребовать, чтобы пользователь фиксировал ошибку. Можно проверить XML-документ, когда он сначала читается и обрабатывается и позже когда пользователи пытаются внести любые изменения в него.
Поскольку программируемый интерфейс NSXMLParser разработан для создания отчетов только о конструкциях XML и объявлениях DTD, эта статья внимание на ту схему языка. Однако при использовании основанной на XML схемы языка, такой как RELAX NG, тогда NSXMLParser может обработать схему просто, это было бы как любой XML-файл, сообщая, что это находит его делегату. Можно использовать данные, которые Вы, таким образом, получаете для проверки.
Разделы по построению правил фокусируются прежде всего на объявлениях элемента и объявлениях атрибута, потому что это безусловно наиболее распространенный и самый важный тип объявления. Обработка Других Объявлений кратко обсуждает, что сделать с другими видами объявлений, такими как те для объектов и нотаций.
Используя NSXMLParser для обработки объявлений DTD
Класс NSXMLParser сообщает его делегату об объявлениях DTD, с которыми он встречается в документе (предполагающий, что делегат реализует необходимые методы). Если схемой языка, которую Вы используете, является DTD, NSXMLParser помогает Вам получить данные, в которых Вы нуждаетесь или для проверки или для других целей, таких как осуществление правильности при динамичном построении объектов (например, шаблон меню).
Методы делегации DTD
Класс NSXMLParser определяет полдюжину методов делегации, которые вызывает синтаксический анализатор, когда синтаксический анализатор встречается с объявлением DTD во внутреннем или внешнем источнике. Эти методы имеют форму:
parser:foundВвестиDeclarationWithName:...
Третий параметр и любые последующие параметры зависят от типа объявления. Следующий список кратко описывает методы делегации NSXMLParser, связанные с объявлениями DTD.
Пример:
<!ELEMENT dictionary (documentation?, suite+)>Пример:
<!ATTLIST dictionary title CDATA #IMPLIED >Пример:
<!ENTITY % OSType "CDATA">Пример:
<!ENTITY name SYSTEM “name.xml”>Пример:
<!NOTATION img PUBLIC “urn:mime:image/jpeg”>Пример:
<!ENTITY corplogo SYSTEM “logo.jpg” NDATA img>
- parser:foundElementDeclarationWithName:model:- parser:foundAttributeDeclarationWithName:forElement:type:defaultValue:- parser:foundInternalEntityDeclarationWithName:value:- parser:foundExternalEntityDeclarationWithName:publicID:systemID:- parser:foundNotationDeclarationWithName:publicID:systemID:- parser:foundUnparsedEntityDeclarationWithName:publicID:systemID: notationName:Разрешение внешних объектов DTD
XML-документ, в DOCTYPE объявление, происходящее около его начала, часто идентифицирует внешний файл DTD, объявления которого предписывают его логическую структуру. Например, следующий DOCTYPE объявление говорит, что DTD, связанный с корневым элементом «адреса», может быть расположен системным идентификатором «addresses.dtd».
<!DOCTYPE addresses SYSTEM "addresses.dtd"> |
Часто системный идентификатор принимает стандартное расположение файловой системы для DTDs — например, /System/Library/DTDs. В начале обработки делегату NSXMLParser дают возможность разрешить этот внешний объект и дать синтаксическому анализатору список объявлений DTD для парсинга.
При подготовке экземпляра NSXMLParser отправьте его
setShouldResolveExternalEntities:с параметромYES.Реализуйте метод делегации
parser:resolveExternalEntityName:systemID:возвратить объявления во внешнем файле DTD как объект NSData.
Если объявления DTD будут внутренними к XML-документу, то делегат получит сообщения объявления DTD автоматически (предположение, конечно, что он реализует связанные методы).
Построение правил для элементов
Так же, как элементы обычно являются наиболее распространенным видом конструкции в XML-документе, объявления элемента являются наиболее распространенным видом объявления в DTD. Они выражают правила для состава элементов от дочерних элементов, текста и других составляющих.
Объявление элемента имеет три части: !ELEMENT ключевое слово, имя элемента и модель содержания. Модель содержания - все после имени до завершающейся угловой скобки. Рассмотрите следующие примеры:
<!ELEMENT cocoa EMPTY> |
<!ELEMENT keyboard (layouts+, modifierMap+, keyMapSet+, actions*, terminators*)> |
<!ELEMENT dict (key, %plistObject;)*> |
<!ELEMENT string (#PCDATA)> |
Модель содержания не может указать содержание (EMPTY), любое содержание (ANY, который редок), текстовое содержание (#PCDATA), и дочерние элементы. Это может идентифицировать дочерние элементы по имени или ссылкой на сущность (такой как %plistObject; в третьем примере выше). Модель может также указать смешанное содержание — т.е. элемент может содержать текст и дочерние элементы в любом порядке. Через модификаторы возникновения (*, +, ?) и другие синтаксические соглашения, модель содержания может также указать порядок дочерних элементов, требуется ли элемент или дополнительный, сколько раз элемент может произойти, и приемлемый выбор между элементами. Модификаторы возникновения могут быть применены к группам элементов (в круглых скобках), а также отдельные элементы.
Задание, требуемое для проверки, должно исследовать модель содержания объявления элемента и получить правила для состава того элемента. Как один подход, Вы могли бы разработать классы для каждого типа правила, а также для объема правила (отдельный элемент или группа элементов). Вы могли тогда связать экземпляры того класса правила с элементом через имя элемента. Во время проверки экземпляры запрашиваются относительно текущего или потенциального элемента элемента.
Таблица 1 перечисляет самые важные правила, получаемые от модели содержания объявления элемента.
Построение правил для атрибутов
Элементы часто имеют атрибуты, связанные с ними, и со следовательно объявлениями списка атрибутов часто встречаются в DTDs. Объявления списка атрибутов указывают правила для атрибутов с помощью синтаксиса, отличающегося от объявлений элемента. Они указывают, в порядке, связанном элементе, имени атрибута, типе атрибута и значении по умолчанию. Например, объявление
<!ATTLIST modifierMap defaultIndex NMTOKEN #REQUIRED > |
состояния, что defaultIndex атрибут, связанный с modifierMap элемент, имеет тип NMTOKEN (подразумевать, что это должно быть допустимое имя XML); #REQUIRED ключевое слово, данное как значение по умолчанию, означает, что должно быть предоставлено значение для атрибута.
Когда экземпляр NSXMLParser встречается с объявлением списка атрибутов, он отправляет parser:foundAttributeDeclarationWithName:forElement:type:defaultValue: его делегату. Переданный в, поскольку параметры являются названием атрибута, связанным элементом, типом атрибута и его значением по умолчанию. Правила для атрибутов происходят из комбинаций последних двух параметров (тип и значение по умолчанию). Таблица 2 перечисляет некоторых возможные правила, что можно создать из объявлений списка атрибутов.
Обработка других объявлений
Другие объявления DTD, такие как те для объектов и нотаций менее распространены, чем объявления элемента и объявления списка атрибутов. Можно легко получить конструкции правила для этих других объявлений после рассмотрения некоторой документации DTD. Однако существует несколько вещей иметь в виду:
Необходимо записать объявления сущности в случае, если они используются в качестве части модели содержания для объявления элемента.
Поскольку нотации могут быть сделаны типом атрибута, необходимо также отслеживать их.