Выявление полезной XML-структуры: Запись адреса в формате XML

Содержание

В статье рассматривается типичный информационный набор – запись адреса – и излагаются возможные требования к кодированию информационного набора, а также способы удовлетворения этих требований с помощью соответствующей схемы разметки. Сформулированы три главных вопроса информационного анализа и показано, как применять эти идеи к разбору типичной записи, содержащей имя и адрес.

XML стал вездесущим инструментом обработки информации, проникая во все от традиционных публикаций до бизнес-транзакций и твиттера. Стереотип "XML – это просто!" нередко приводит к тому, что набор тегов, выбранных для XML-приложения, может оказаться неоптимальным при использовании информационного набора в реальной жизни. Плохая организация информации может осложнить кодирование, необходимое для манипулирования информационным набором и его представления. К счастью, немного дополнительной работы в начале может упростить дальнейшее движение по пути разработки.

Проектирование информационной структуры сводится к решению трех главных вопросов:

  • Что представляют собой полезные элементы информационного набора?
  • Каковы отношения между этими элементами?
  • Нужно ли знать об этих элементах что-то еще?

Рассмотрим типичный информационный набор и возможные XML-структуры, которые можно использовать при обработке данных.

Анализ записи адреса

Запись адреса появляется в самых разнообразных формах и контекстах: она может оказаться в центре другого информационного набора или в составе коллекции, хранящейся в базе данных, и служить для формирования запросов или распечатки в виде этикеток. Типичная запись адреса может выглядеть примерно так, как в листинге 1.

Листинг 1. Запись имени и адреса

John Q. Public
1234 Main Street
Anytown, Anystate 54321-6789

С точки зрения XML ее структура может быть простейшей, как в листинге 2.

Листинг 2. Запись имени и адреса с простой разметкой

<address_rec>
  <line>John Q. Public</line>
  <line>1234 Main Street</line>
  <line>Anytown, Anystate 54321-6789</line>
</address_rec>

Или же она может быть сложной, как в листинге 3.

Листинг 3. Запись имени и адреса со сложной разметкой

<address_rec>
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
</address_rec>

Эту структуру можно разложить еще дальше, маркируя знаки пунктуации (точку, запятую и дефис) или разбив почтовый индекс на две части. Кроме того, можно добавить такую информацию, как номер телефона, номер факса, адрес электронной почты или Web-сайт.

Определение требований, предъявляемых к записи адреса

Однако прервемся на минуту и вспомним приведенные выше главные вопросы. Что представляют собой полезные элементы? Для их определения сначала нужно решить, каковы ваши требования и намерения в отношении этих данных. Будете ли вы:

  • распечатывать этикетки;
  • сортировать записи по фамилии или почтовому индексу;
  • производить поиск имен, городов или штатов?

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

В целом требования, предъявляемые к информационному набору, можно разделить на три категории:

  • Обязательные. Если эти требования не выполнены, проект явно не удался.
  • Желательные. Если эти требования удастся выполнить, пользователи получат дополнительные выгоды.
  • Если бы ресурсы были неограниченными (варианты типа "журавль в небе"). Это "мечты", которые, скорее всего, выходят за рамки данного проекта.

При сегодняшних бюджетах и сроках – выполнить бы обязательные требования и, возможно, захватить несколько желательных. Тем не менее, будет полезно записать все требования – даже "журавлиные". То, что группа рассматривает как требование "журавля в небе", может оказаться побочным продуктом одного из обязательных требований.

Определение и уточнение модели записи адреса

Структура XML, как правило, состоит из элементов и атрибутов: на самом базовом уровне элементы – это контейнеры для данных, а атрибуты – ярлыки контейнеров с данными. При первоначальном построении XML-модели информационного набора часто бывает полезно определить информационный набор как совокупность элементов и уточнить структуру элементов с помощью атрибутов.

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

Рассмотрим более сложный пример из листинга 3. Сложный пример, казалось бы, удовлетворяет всем высказанным до сих пор требованиям:

  • записи можно распечатать. В самом деле, каждую запись можно распечатать в форме со строкой для составляющих имени, строкой для улицы и строкой для города, штата и почтового индекса;
  • фамилию и почтовый индекс мы уже определили, так что компоненты address_rec можно отсортировать по содержанию этих элементов;
  • мы определили имена и их компоненты вместе с городом и штатом, так что можно искать строки символов и выходить на эти элементы.

Похоже, что мы выполнили все исходные требования. Хотя структуру можно было бы усовершенствовать для удовлетворения будущих требований, на данный момент можно объявить, что работа выполнена. Помните старую пословицу: можно не означает должно?

Как можно было бы усовершенствовать эту структуру? Базы данных любят ключи, так добавим к каждому компоненту address_rec запись ключа, как в листинге 4.

Листинг 4. Запись имени и адреса с атрибутом ключа

<address_rec key="1234">
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
</address_rec>

Если записи извлекаются из базы данных для создания XML-документов, ключ базы данных можно перенести непосредственно в атрибут key элемента address_rec. С функциональной точки зрения атрибут key соответствует ярлыку на контейнере address_rec, который служит уникальным идентификатором записи.

Хотя вам вряд ли придется печатать на своих гипотетических этикетках телефонные номера, можно собрать другую контактную информацию, которая будет передаваться в XML-документы address_rec. Номера телефонов и другие виды электронной контактной информации можно включить в структуру, как показано в листинге 5.

Листинг 5. Запись имени и адреса с дополнительной контактной информацией

<address_rec key="1234">
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
  <phone>316-555-1234</phone>
  <email>[email protected]</email>
  <web>http://www.mydomain.com/john</web>
</address_rec>

Если наш мифический John Q. Public проводит столько же времени за компьютером, сколько я, он, вероятно, имеет несколько точек контакта. Можно создать отдельный элемент для каждого из них или использовать один повторяющийся элемент с подходящим атрибутом для идентификации каждого из его адресов. Давайте попробуем это сделать. Можно также позволить указывать несколько телефонных номеров, как в листинге 6.

Листинг 6. Запись имени и адреса с еще более подробной контактной информацией

<address_rec key="1234">
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
  <phone type="home">316-555-1234</phone>
  <phone type="fax">316-555-1235</phone>
  <phone type="mobile">316-555-1236</phone>
  <web type="email">[email protected]</web>
  <web type="email">[email protected]</web>
  <web type="homepage">http://www.mydomain.com/john</web>
  <web type="twitter">johnqpublic</web>
</address_rec>

Выбор элементов и атрибутов имен произволен (если вы не адаптируете чью-то структуру), равно как и значения атрибутов типа. Но этот выбор может быть и обусловлен требованиями, определенными для приложения или системы.

Самая важная часть процесса – удовлетворение требований: если то, что вы намеревались сделать, возможно, то задача уже практически решена.

Схемы и проверка: обязательно или желательно?

Определив полезные элементы информационного набора и составив, а затем уточнив модель, впору задать вопрос: "И это все?" Для некоторых приложений XML действительно достаточно пометить полезные элементы информации и использовать их для последующей обработки.

То, что мы создали до сих пор, представляет собой "добротно сформированные" XML-документы: они следуют очень небольшому числу правил и подходят для многих различных видов обработки. Для многих приложений добротно сформированные XML-документы – именно то, что нужно.

Но что, если требуется соблюдать более строгие правила? XML-документы можно валидировать, т. е. проверить с помощью программы на соответствие определенному набору правил и отношений, и можно написать среду валидации, пользуясь одним или несколькими формальными языками валидации. Вот общепринятые языки валидации:

  • Document Type Definition (DTD). DTD – это самые старые языки валидации, восходящие к SGML (ISO 8879, "Стандартный обобщенный язык разметки"), которые входят в "Рекомендации W3C по XML".
  • W3C XML Schema. Разработанный W3C и получивший широкое распространение, этот язык включает в себя контроль типов данных и записывается в виде XML-документа.
  • RELAX NG. Разработанный в Организации по улучшению стандартов структурированной информации (OASIS), а затем вошедший в состав стандарта ISO – ISO/IEC 19757-2:2008, – RELAX NG имеет как форму XML-документа, так и компактную не-XML форму.

Дополнительные правила, не предусмотренные указанными языками схемы, можно выразить на Schematron, языке валидации на базе XSLT, который используется для проверки содержания документов и их структуры.

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

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

Нужна ли схема? Создание схемы требует знаний, времени и усилий: если это не полезная часть разрабатываемого приложения или системы, она легко может оказаться пустой тратой ресурсов. Примите к сведению следующие рекомендации:

  • Ваша информация сгенерирована машиной или подготовлена человеком? Схемы – удобный способ передачи требований, предъявляемых к структуре и содержанию информационного набора, особенно для средств разработки.
  • Используется ли информация, полученная из неподконтрольных вам источников? В этом случае схема – способ убедиться в том, что внешний источник информации поставляет XML-документы с соблюдением структуры, которую вы ожидаете получить.
  • Требуется ли от вас валидация? Система или клиент могут требовать валидации в рамках системы, а формальная валидация потребует схемы в той или иной форме.
  • Требуют ли схему инструменты, входящие в технологическую цепочку? Инструменты для работы с готовыми XML-документами, вероятно, не потребуют схему, но средства разработки, скорее всего, потребуют.

Помните, что и здесь работает старая поговорка: можно не означает должно. В некоторых случаях разработка схемы для определенного информационного набора не требуется, не будет полезна или даже может оказаться невозможной из-за чрезмерного объема работы. Полезные схемы тяготеют к приложениям, в которых данные носят относительно предсказуемый характер – чем более изменчив набор данных, тем сложнее схемы.

Заключение. Информационный анализ в двух словах

Процесс выявления полезных элементов информационного набора XML теперь должен быть достаточно ясен:

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

Создание прочной основы для XML-приложения может снизить потребность в сложном кодировании в процессе дальнейшей разработки.



10 ноября 2010 г.
Майкл Р. Хан
http://www.ibm.com/developerworks/ru/library/x-divining/index.html