XML - статьи
         

Использование RDF


Выше были введены базовые понятия RDF и объяснено устройство модели данных. Фактически, содержательная часть технологии этим и исчерпывается, поскольку в задачу RDF входило лишь предоставление простой базовой модели для описания отношения ресурсов в терминах именованных свойств и их значений, а также некоторого синтаксиса, который мог бы использоваться различными сторонами для обмена данными. В рекомендации ничего не говорится о том, какие свойства могут быть у конкретных объектов и каковы их допустимые значения, подобно тому, как в спецификации XML определяются лишь правила разметки данных, но не конкретный язык для выделенной предметной области. Исключением здесь являются лишь несколько универсальных характеристик, таких как упомянутое выше свойство “type”, принадлежащих непосредственно пространству имен RDF.

Модель данных сама по себе всего лишь скелет. Для того чтобы описание обрело некий смысл, необходимо воспользоваться словарями, которые задаются при помощи дополнительной технологии – RDF Schema, играющей для RDF такую же роль, что и схема для XML (причем выражения схемы RDF также являются корректными выражениями RDF, как и выражения схемы XML – корректные выражения XML).

Под словарем следует понимать совокупность ресурсов, использующихся для описания свойств других ресурсов; классов ресурсов, которые могут быть описаны при помощи заданных свойств; и ограничения, налагаемые на их значения или наборы допустимых значений. При этом классы могут состоять в отношении “подкласс” и аналогично свойства могут быть связаны отношением “подсвойство” [2, 8].

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


Реальное значение RDF невозможно оценить, пока он используется для внутренних целей отдельно взятого приложения. Польза от внедрения RDF будет тогда, когда он станет средством межпрограммного взаимодействия, обмена данными, когда машины получат способность комбинировать информацию, полученную из различных источников, тем самым, получая какую-то новую информацию. Чем больше приложений в Интернете смогут работать с данными, тем выше станет их ценность [1, 7].

Одним из наиболее ярких примеров существующего общеизвестного словаря является Dublin Core – набор атрибутов для метаописания ресурсов с целью каталогизации. Dublin Core предоставляет пятнадцать характеристик, семантика которых была согласована интернациональной междисциплинарной группой, состоящей из специалистов в области библиотечного дела, информатики, представителей музейного сообщества и других сторон [9].

Эти характеристики, описывающие содержимое документов (или других объектов, например, рисунков), версию, формат, язык и так далее, а также права на интеллектуальную собственность, были разработаны независимо от RDF. Тем не менее, одной из целей создания технологии описания ресурсов было получение средства для указания метаданных, и информационная модель RDF прекрасно подходит для описания ресурсов при помощи атрибутов Dublin Core. Более того, авторы ряда статей рассматривают RDF исключительно в этом качестве, даже не упоминая о других возможностях применения данной технологии.

В то же время RDF прекрасно подходит и для представления самих данных, их структуры и связей. Таким образом, при применении специально разработанных RDF-схем (в качестве средства описания онтологии предметной области) технология может быть использована для выражения информации, относящейся к некоторым разделам знаний, понятным для различных приложений Интернета образом.






Литература


Tim Berners-Lee – "Semantic Web Road map", Сентябрь 1998;

Стин Декер, Сергей Мельник, Франк ван Хермелен, и др. – "Semantic Web: роли XML и RDF", "Открытые системы", Сентябрь 2001;

Edd Dumbill – "The role played by XML in the next-generation Web", Сентябрь 2000;

Tim Bray – "What is RDF?", Январь 2001;

Edd Dumbill – "Putting RDF to Work", Август 2000;

Ora Lassila, Ralph Swick – "Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation, Февраль 1999;

Graham Klyne, Jeremy Carroll – "Resource Description Framework (RDF): Concepts and Abstract Data Model", W3C Working Draft, Август 2002;

Dan Brickley, R.V. Guha – "RDF Vocabulary Description Language 1.0: RDF Schema", W3C Working Draft, Ноябрь 2002;

Diane Hillmann – "Using Dublin Core", Апрель 2001;



Модель данных RDF и вопросы сериализации


Основополагающим для RDF является понятие модели данных. Это есть набор фактов и семантических связей между ними, задаваемый конкретным RDF-документом.

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

После того как программа-парсер прочитала RDF-описание и построила по нему внутренне представление, до определенной степени напоминающее объектную модель документа для XML, вся дальнейшая программная работа с описанием ведется на уровне модели данных и абсолютно не зависит от изначально используемого языка сериализации. Два документа считаются эквивалентными, если совпадают их представления в виде модели, поэтому в случае использования RDF не может возникнуть проблема неоднозначного описания одного и того же факта, как это могло случиться при работе с XML [6, 7].

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



Принципы построения модели


Базовый строительный блок модели данных – утверждение, представляющее собой тройку: ресурс, именованное свойство и его значение. В терминологии RDF эти три части утверждения называются соответственно: субъект, предикат и объект [6].

Ресурсом называют все, что описывается средствами RDF. Это может быть обыкновенная Web-страница или какая-то ее часть, например, отдельный элемент HTML или XML разметки, являющийся частью описываемого документа. Также ресурсом может быть целая коллекция страниц, такая как отдельно взятый Web-сайт. И, наконец, в качестве ресурса может выступать нечто, не являющееся доступным непосредственно через Интернет, например, произвольный предмет из мира вещей. Одним словом, все, чему можно приписать некоторый URI (универсальный идентификатор) или URI с добавлением внутреннего имени объекта (имени якоря в HTML) может стать ресурсом и быть описано при помощи RDF.

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

Для обеспечения уникальности имен свойства подобно названиям элементов в XML придерживаются концепции пространства имен. Это означает, что не существует атрибута “цвет” как такового, а существует “цвет” в каком-то уникальном пространстве. В другом пространстве может существовать свое одноименное свойство. Таким образом, имя характеристики представляет собой URI, что делает ее потенциальным объектом для описания при помощи RDF отдельно от характеризуемого ресурса и имеющегося значения. То есть каждое свойство в RDF само является ресурсом и может иметь свои собственные атрибуты.

Одним из общезначимых свойств является “type”, относящееся к пространству имен, задаваемому непосредственно спецификацией RDF. Оно позволяет указать класс описываемого ресурса. Это может быть автомобиль, человек, книга и так далее, а может быть некоторая последовательность объектов (для выражения данного факта существует специальное значение “Seq”, также принадлежащее к пространству имен RDF).


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

Тот факт, что значением свойства может быть некоторый ресурс, превращает модель данных из дерева, которым является XML-разметка, в ориентированный граф. Вершинами этого графа являются субъекты и объекты, а дугами – именованные свойства. Поскольку свойство в свою очередь может быть субъектом некоторого утверждения, графы могут быть как линейными, так и вложенными, например, мы можем выражать сомнение или согласие с каким-либо утверждением или указывать источник получения сведений [2, 6].

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

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dat="http://description.org/dates#" xmlns:foo="http://foo.org/car-park#"> <rdf:Description rdf:about="http://foo.org/car-park"> <foo:car rdf:resource="http://foo.org/car-park/01" rdf:type="http://description.org/vehicles#car" dat:year="1999"/> <foo:car rdf:resource="http://foo.org/car-park/02" rdf:type="http://description.org/vehicles#car" dat:year="2001"/> </rdf:Description> </rdf:RDF>

Этому описанию соответствует модель данных, которая представляется следующим графом (при графическом изображении RDF ресурсы принято рисовать овалами, а литералы – прямоугольниками):


Проблема описания семантики и границы XML


Несколько лет назад World Wide Web Консорциумом был разработан язык XML, предоставляющий стандарт структурирования и разметки произвольной информации. По мнению многих специалистов появление XML стало своего рода революцией в сфере Web-программирования. Разработчики получили простое средство для хранения данных в понятном для человека и легко читаемом формате, где разметка говорит сама за себя. Появилась возможность отделить информационное наполнение Интернет-страниц от их визуального представления.

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

Универсальный синтаксис открыл дорогу появлению ряда важных сопутствующих XML технологий. Это языки XSL и XPath, предназначенные для работы с древовидной структурой документов; XML Schema – стандарт описания конкретных языков разметки, использующий синтаксис XML; XLink и XPointer – средства связи распределенных блоков информации в один общий документ; XQuery – язык запросов к размеченным данным и другие технологии.

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

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

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


Данное утверждение требует более детального объяснения.

Практически параллельно с работами по стандартизации XML основатель WWW Консорциума Тим Бернерс-Ли сформулировал новое понятие – Semantic Web – то, каким он видит будущее глобальной сети, и инициировал исследования в этом направлении. В основе предполагаемого им будущего лежит способность машин не только читать, но и понимать содержание Интернет-ресурсов, причем достигнуть этого, по мнению Бернерса-Ли, мы должны не через создание программ искусственного интеллекта, моделирующих деятельность человека, а через использование средств выражения семантики данных и их связей [1].

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

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

Итак, если синтаксическая интероперабельность неразрывно связана с синтаксическим анализом данных, то семантическая требует анализа самой информации, связи ее с мировым информационным полем, установления соответствия терминов и словарей одной предметной области элементам другой [2].

XML не может стать средством, обеспечивающим связь различных данных по ряду причин.



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

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

<car color="red"/> <car><color>red</color></car> <car color="#cc"/><color id="cc" shade="red"/>

Данный факт может быть выражен и другими способами, а в том случае, когда имеется уже несколько упорядоченных отношений, вариантов кодирования еще больше [3].

С указанной проблемой можно было бы попытаться справиться одним из двух способов: либо всем заинтересованным сторонам договориться об используемом формате описания, либо прибегать к преобразованию одной грамматики в другую [2]. Однако, очевидно, что первый из этих способов не реален, поскольку заинтересованных сторон, как правило, много и состав их регулярно меняется, а второй способ крайне громоздок, и оба они по-прежнему не решают проблему выделения семантической единицы предметной области. Поэтому приходится признавать, что для эффективного представления фактов необходимо вводить некие ограничения на уровне самого языка.

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

И последняя причина заключается в том, что разметка, допускающая смесь из текста и вложенных элементов, сложна для вычленения данных и установления связи между ними. Эта сложность возникает, если необходимо отразить, что объект имеет некоторое свойство, а его значение в свою очередь представлено не значением простого типа и не вложенным поддеревом, а смешанной разметкой (“mixed content” в терминологии XML Schema) [4].

Подводя итог сказанному, следует отметить, что для Интернета будущего, в котором программы смогут автоматически анализировать содержание ресурсов, необходимо новое средство выражения семантики данных, а не только их записи.






Resource Description Framework


Технология описания ресурсов – Resource Description Framework (RDF) – является тем самым средством, на которое WWW Консорциум возлагает надежды на решение указанных задач, связанных с описанием семантики.

Несмотря на то, что RDF получил статус рекомендации еще в феврале 1999 года, он по-прежнему не обрел широкого распространения. Причин этому несколько. С одной стороны в отличие от языка XML RDF не сразу получил широкую программную поддержку. С другой – RDF не имел такой первоочередной нацеленности на электронную коммерцию и до сих пор остается преимущественно в области интересов исследователей. Третья причина видится в том, что текущий синтаксис RDF вызывает многочисленные споры и нарекания со стороны потенциальных пользователей данной технологии. По их мнению предложенные формы записи сложны и громозди, что делает описание ресурсов не слишком удобным для применения [3, 5].

Тем не менее, RDF представляется весьма интересной технологией и является важным шагом к созданию Semantic Web. Он продолжает привлекать внимание исследователей и, по мнению многих из них, несет в себе большой потенциал. Можно сказать, что это средство еще не известно широким массам разработчиков или только осознается ими, и есть надежда, что в будущем RDF займет предназначенное ему место.



Выражение семантики данныхRDF против XML


Владимир Шрайбман,

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



Что такое RSS?


Mark Pilgrim, сайт www.xml.com
Оригинал: What is RSS? (2002 г.)
Перевод: , сайт Webmascon (2003 г.)

RSS это формат, предназначенный для публикации новостей на новостных и подобных им сайтах, начиная от таких ведущих новостных сайтов, как Wired, Slashdot, и кончая личными сетевыми дневниками (weblog-ами). Но по сути, публиковать можно не только новости. Практически любой материал, который можно разделить на отдельные части, можно публиковать с помощью RSS: например, объявления о последних публикациях в "wiki", информация об обновлениях в CVS, история изменений, внесенных в книгу. После того, как информация преобразована в формат RSS, программа, понимающая этот формат, может вытягивать сведения о внесенных изменениях и в зависимости от результата, например, автоматически предпринимать какие-либо действия.

Программы, умеющие работать с RSS, называются агрегаторами, и они очень популярны среди людей, ведущих сетевые дневники (weblog-и). Некоторые программы-дневники даже позволяют другим делать комментарии к записям. И многие дневники умеют публиковать записи в формате RSS. Программа-агрегатор позволяет вам собирать все эти публикации вместе, и вы получаете возможность одновременно следить за появлением новых новостей на всех сайтах сразу и читать их краткое содержание, не посещая каждый сайт в отдельности.



Как выглядит RSS?


Скажем, вы захотели написать программу, которая считывает новости в формате RSS, чтобы, например, публиковать заголовки новостей на своем сайте, или чтобы создать портал новостей и так далее. Как выглядит RSS-файл? Все зависит от того, о какой версии RSS идет речь. Вот пример файла в формате RSS 0.91 (урезанная версия новостей с http://www.xml.com/):

<rss version="0.91">
  <channel>
    <title>XML.com</title>
    <link>http://www.xml.com/</link>
    <description>XML.com features a rich mix of information and services for the XML community.</description>
    <language>en-us</language>
    <item>
      <title>Normalizing XML, Part 2</title>
      <link>http://www.xml.com/pub/a/2002/12/04/normalizing.html</link>
      <description>In this second and final look at applying relational normalization techniques to W3C XML Schema data modeling, Will Provost discusses when not to normalize, the scope of uniqueness and the fourth and fifth normal forms.</description>
    </item>
    <item>
      <title>The .NET Schema Object Model</title>
      <link>http://www.xml.com/pub/a/2002/12/04/som.html</link>
      <description>Priya Lakshminarayanan describes in detail the use of the .NET Schema Object Model for programmatic manipulation of W3C XML Schemas.</description>
    </item>
    <item>
      <title>SVG's Past and Promising Future</title>
      <link>http://www.xml.com/pub/a/2002/12/04/svg.html</link>
      <description>In this month's SVG column, Antoine Quint looks back at SVG's journey through 2002 and looks forward to 2003.</description>
    </item>
  </channel>
</rss>


Все просто, правда? Блок новостей (channel) состоит из заголовка, ссылки, данных о языке новостей и описания. После этого идет список самих новостей, где в каждом пункте указывается заголовок, ссылка и краткое описание новости.

Теперь давайте взглянем, как та же самая информация выглядит в формате RSS 1.0:

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
>
  <channel rdf:about="http://www.xml.com/cs/xml/query/q/19">
    <title>XML.com</title>
    <link>http://www.xml.com/</link>
    <description>XML.com features a rich mix of information and services for the XML community.</description>
    <language>en-us</language>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://www.xml.com/pub/a/2002/12/04/normalizing.html"/>
        <rdf:li rdf:resource="http://www.xml.com/pub/a/2002/12/04/som.html"/>
        <rdf:li rdf:resource="http://www.xml.com/pub/a/2002/12/04/svg.html"/>
      </rdf:Seq>
    </items>
  </channel>
  <item rdf:about="http://www.xml.com/pub/a/2002/12/04/normalizing.html">
    <title>Normalizing XML, Part 2</title>
    <link>http://www.xml.com/pub/a/2002/12/04/normalizing.html</link>
    <description>In this second and final look at applying relational normalization techniques to W3C XML Schema data modeling, Will Provost discusses when not to normalize, the scope of uniqueness and the fourth and fifth normal forms.</description>
    <dc:creator>Will Provost</dc:creator>
    <dc:date>2002-12-04</dc:date>    
  </item>
  <item rdf:about="http://www.xml.com/pub/a/2002/12/04/som.html">
    <title>The .NET Schema Object Model</title>
    <link>http://www.xml.com/pub/a/2002/12/04/som.html</link>
    <description>Priya Lakshminarayanan describes in detail the use of the .NET Schema Object Model for programmatic manipulation of W3C XML Schemas.</description>
    <dc:creator>Priya Lakshminarayanan</dc:creator>
    <dc:date>2002-12-04</dc:date>    
  </item>
  <item rdf:about="http://www.xml.com/pub/a/2002/12/04/svg.html">
    <title>SVG's Past and Promising Future</title>
    <link>http://www.xml.com/pub/a/2002/12/04/svg.html</link>
    <description>In this month's SVG column, Antoine Quint looks back at SVG's journey through 2002 and looks forward to 2003.</description>
    <dc:creator>Antoine Quint</dc:creator>
    <dc:date>2002-12-04</dc:date>    
  </item>
</rdf:RDF>



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

Несмотря на то, что RSS 1.0 является смесью RDF и XML, структурно он схож с предыдущими версиями RSS - схож достаточно, чтобы мы рассматривали его как обычный XML-файл. Следовательно мы можем написать одну программу, которая умеет извлекать информацию из обоих форматов: и из RSS 0.91 и из RSS 1.0. Однако есть все-таки некоторые различия, о которых ваша программа должна знать:

Корневым элементом в RSS 1.0 является rdf:RDF, а не rss. Вам либо придется явно обрабатывать оба этих элемента, либо просто игнорировать их и слепо извлекать только ту информацию, которая вам нужна.

В RSS 1.0 используются пространства имен (namespaces). Пространство имен для RSS 1.0 выглядит так http://purl.org/rss/1.0/. И это пространство имен принимается по умолчанию. Кроме того в файле используются пространства имен http://www.w3.org/1999/02/22-rdf-syntax-ns# для элементов, специфичных для RDF (мы их тоже можем игнорировать), и http://purl.org/dc/elements/1.1/ (Dublin Core) для дополнительных метаданных об авторах статей и датах публикаций.

Вы можете пойти двумя путями: если ваш XML-парсер не понимает пространства имен, вы можете просто считать, что в файле используются элементы с префиксами и слепо искать в них элементы items и dc:creator. Такой способ сработает в большинстве случаев, так как в новостях формата RSS 1.0 чаще всего используется только пространство имен, принятое по умолчанию, и пространство имён Dublin Core. Конечно, данный способ - не элегантен, ведь нет никаких гарантий, что в каких-нибудь новостях не будет использовано какое-либо другое пространство имен (что вполне легально с точки зрения RDF и XML). И ваш парсер пропустит все новости.



Если же ваш XML- парсер понимает пространства имен, вы можете построить более изящное решение, которое сумеет разобрать новости и формате 0.91 и в формате 1.0.

Менее очевидный, но важный факт состоит в том, что в RSS 1.0 элементы item находятся вне элемента channel. В RSS 0.91 элементы item расположены внутри channel. В 0.90 они были снаружи. В 2.0 - они внутри. Во-как! Не запутайтесь с тем, в каком элементе надо искать новости. Наконец, вы заметите, что в элементе channel есть один элемент items. Он нужен только для RDF-парсеров (задает порядок новостей). Вы можете его игнорировать и считать, что все новости идут в том порядке, в каком расположены элементы item.

А как выглядит формат RSS 2.0? К счастью, для программ, понимающих форматы RSS 0.91 и 1.0, формат RSS 2.0 будет проще пареной репы.

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>XML.com</title>
    <link>http://www.xml.com/</link>
    <description>XML.com features a rich mix of information and services for the XML community.</description>
    <language>en-us</language>
    <item>
      <title>Normalizing XML, Part 2</title>
      <link>http://www.xml.com/pub/a/2002/12/04/normalizing.html</link>
      <description>In this second and final look at applying relational normalization techniques to W3C XML Schema data modeling, Will Provost discusses when not to normalize, the scope of uniqueness and the fourth and fifth normal forms.</description>
      <dc:creator>Will Provost</dc:creator>
      <dc:date>2002-12-04</dc:date>    
    </item>
    <item>
      <title>The .NET Schema Object Model</title>
      <link>http://www.xml.com/pub/a/2002/12/04/som.html</link>
      <description>Priya Lakshminarayanan describes in detail the use of the .NET Schema Object Model for programmatic manipulation of W3C XML Schemas.</description>
      <dc:creator>Priya Lakshminarayanan</dc:creator>
      <dc:date>2002-12-04</dc:date>    
    </item>
    <item>
      <title>SVG's Past and Promising Future</title>
      <link>http://www.xml.com/pub/a/2002/12/04/svg.html</link>
      <description>In this month's SVG column, Antoine Quint looks back at SVG's journey through 2002 and looks forward to 2003.</description>
      <dc:creator>Antoine Quint</dc:creator>
      <dc:date>2002-12-04</dc:date>    
    </item>
  </channel>
</rss>



Как показывает данный пример, в RSS 2. 0 тоже используются пространства имен, как и в RSS 1.0. Но это не RDF. Как и в RSS 0.91, нет пространства имен, принятого по умолчанию, а новости (в элементах item) размещены опять в элементе channel.

document.write('');

Новости мира IT:

02.08 - 02.08 - 02.08 - 02.08 - 02.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 31.07 - 31.07 - 31.07 - 31.07 - 31.07 -

Архив новостей

Последние комментарии:

 (66)

2 Август, 17:53

 (19)

2 Август, 17:51

 (34)

2 Август, 15:40

 (42)

2 Август, 15:35

 (1)

2 Август, 14:54

 (3)

2 Август, 14:34

 (3)

2 Август, 14:15

 (2)

2 Август, 13:34

 (7)

2 Август, 13:04

 (3)

2 Август, 12:28



BrainBoard.ru

Море работы для программистов, сисадминов, вебмастеров.

Иди и выбирай!

Loading

google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true);

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
PR-акции, размещение рекламы — ,
тел. +7 495 6608306, ICQ 232284597

Пресс-релизы —

 This Web server launched on February 24, 1997

Copyright © 1997-2000 CIT, © 2001-2009
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.
Советуем обратить внимание: доступная.


Краткая история


Программисты, будьте бдительны! Под термином "RSS" скрывается формат, который распался на несколько различных версий как минимум двух различных (но существующих одновременно) форматов. Исходный RSS, версию 0.90, разработали в компании Netscape. Это был формат, предназначенный для создания новостных порталов ведущих новостных компаний. Так как многие посчитали его слишком сложным, компания Netscape разработала более простую версию - 0.91, которую, впрочем, забросила, потеряв всякий интерес к бизнесу порталов. Но версия 0.91 была передана на поруки компании UserLand Software, которая собирается использовать этот формат как основу для своих weblog-продуктов и других web-приложений.

Тем временем, третья, уже некоммерческая организация, отколовшись от общего течения, создала новый формат, который, как полагалось, соответствует духу и принципам исходного формата RSS 0.90 (т.е. до того, как он был упрощен до 0.91). Этот формат, основанный на языке RDF, назвали RSS 1.0. К сожалению, компания UserLand не принимала участия в разработке этого нового формата, и как защитник упрощенной версии 0.90 она не была счастлива, когда появился формат RSS 1.0. Вместо принятия этого формата UserLand решила развить ветку 0.9х и создала версии 0.92, потом 0.93, 0.94 и наконец 2.0.

Вот такой винегрет.



Так каким же форматом мне пользоваться?


Итак, существует 7 - только подумайте "7!" - различных форматов, и все они называются RSS. Как программисту, пишущему программу-агрегатор, вам придется сражаться со всеми этими форматами. Ну а какой формат выбрать пользователю, публикующему свои новости в формате RSS?

Версии RSS и рекомендации
Версия Владелец За Статус Советы
0.90 Netscape Отменен версией 1.0 Не пользуйтесь
0.91 UserLand Очень-очень простой Официально отменен выходом версии 2.0. Но все еще популярен Пользуйтесь для простых публикаций. Если вам понадобится большее, вы легко сможете перейти на 2.0
0.92, 0.93, 0.94 UserLand Больше возможностей, чем у 0.91 Отменен с выходом версии 2.0 Пользуйтесь версией 2.0
1.0 RSS-DEV Working Group Основан на языке RDF. Расширяется с помощью модулей. Не зависит от какой-либо одной компании Стабилен. Ведется активная разработка модулей Используйте для приложений, где используется RDF, либо в том случае, если вам нужен какой-то определенный модуль
2.0 UserLand Расширяется с помощью модулей. Прост при миграции с ветки форматов 0.9х Стабилен. Ведется активная разработка модулей Используйте для публикации новостей общего назначения



RSS - новости с доставкой на дом


aka StraNNick

С каждым днём всё больше людей используют RSS для чтения новостей и, соответственно, всё больше сайтов применяют эту технологию для распространения контента. Что же такое RSS? Рассмотрим этот вопрос с точки зрения посетителя и владельца сайта.

Для простоты я приведу пример.

В нашем небольшом городе (Улан-Удэ) шесть кинотеатров. Я люблю кино. Вероятность того, что если я своевременно узнаю о фильме, то схожу на него достаточно велика, благо время и деньги вполне позволяют...

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

Для этого существуют сайты. И они таки есть. Но что толку? Во-первых - мне откровенно лень запоминать их адреса или искать их в поисковике. Я могу это сделать один раз. Я могу забить их в закладки. Но заходить каждый день для того, чтобы взглянуть - не появилось ли чего нового? Увольте, у меня масса более интересных дел.

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

Теперь предположим, что создатели и владельцы сайтов побеспокоились не только о производимом впечатлении (у нас есть офигительно крутой сайт!), но и об удобстве посетителей, а также о том, чтобы сайт выполнял свою непосредственную функцию - вовремя доносил информацию до потенциально заинтересованных клиентов и, тем самым, привлекал их.

Можно завести старую-добрую почтовую рассылку. Но, во-первых, она требует дополнительных действий от посетителя (например, надо подтвердить подписку), а во-вторых эти письма будут теряться среди моря спама, заполонившего почтовые ящики. Теперь рассмотрим RSS. Потенциальный зритель зашел на сайт. Для подписки требуется буквально пара кликов мышкой. После этого, все обновления, произошедшие на сайте, будут доставлены ему автомагически. Причем в удобной для чтения форме. Я надеюсь, понятно, что в данном случае имеет смысл включить в новость такие вещи как название фильма, цену билетов и время сеансов, а также рецензии, либо ссылки на них (что, в рунете нет ни одного сайта, обозревающего фильмы? Не смешите меня...). Но всего этого нет. И я хожу в кино редко, хотя мог бы чаще...


Я привел вполне жизненный пример. На сегодняшний день в 48 сайтов. Представляете, сколько времени занял бы "обход" их всех? Еще один плюс - экономится время и траффик, так как я вижу только свежие статьи.

Итак, как же можно просматривать RSS-ленты?

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

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

В третьих, существует множество удобных программ. Могу посоветовать - вполне приятная кроссплатформенная программа.

Напоследок - пара ссылок, где более подробно рассказывается, что же такое RSS:

Теперь рассмотрим, чем RSS полезен владельцу сайта?

Собственно, всё просто.

Если Ваш сайт раз и навсегда наполнен одним и тем же содержимым, например справочной информацией о Вашей компанией, RSS Вам не нужен.

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

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

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

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



Так вот. Как только окно браузера закрыто - адрес забыт. Проверено (в первую очередь на себе). А захочет ли пользователь снова искать его - это еще большой вопрос.

Другое дело, если пользователь, придя к Вам, обнаруживает кроме искомой статьи, множество других интересных материалов. Возможно он задержится на какое-то время, но в конечном итоге уйдёт. При этом он либо занесёт понравившийся адрес в закладки, либо забьёт в аггрегатор RSS.

В чём разница?

В первом случае, заходить он будет только когда вспомнит (читай - нечасто), а вот во втором, новости к нему будут приходить сразу после публикации. Чувствуете разницу?

Возникает вопрос - как учитывать тех посетителей, которые читают RSS, не заходя на сайт? Первое решение, которое приходит в голову - публиковать через RSS только заголовки в корне неправильное. Оно просто-напросто сводит всю затею на нет, хотя и практикуется. Исходя из личных предпочтений - не рекомендую. Не факт, что пользователь зайдёт. Не жадничайте, публикуйте полный текст.

Для учета RSS-пользователей можно либо считать обращения к RSS-файлу (если Вы используете свой сервер и свой счетчик), либо использовать сервис (именно так я и делаю). Этот сервис позволяет делать feed не зависящий от того, какую версию RSS поддерживает аггрегатор пользователя, ведёт статистику (сколько подписчиков и каким софтом они пользуются), а также делает многое другое.

Следующий вопрос - чем генерировать ленту (RSS-feed)?

Если Вы не используете никакого движка для своего сайта, т.е. просто выкладываете статические странички - наилучшим выходом будет расширение для браузера Firefox - , в случае использования самостоятельно написанного движка лучше всего попросить программиста дописать модуль, отвечающий за RSS (как это делать - не мне ему советовать... Хотя Atom API порекомендую, но это чисто субъективный выбор), в других случаях, когда используются сторонние движки, уточните, в подавляющем большинстве уже есть необходимая функциональность.

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

Спецификации актуальных версий RSS:

Несколько полезных ссылок:


Принципы проектирования XML-схем: нужны ли производные сложные типы


Дата: 14-10-2003

Автор: Фахеем Кан (Faheem Khan)

Перевод: Intersoft Lab

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



Проблемы, возникающие при определении производных сложных типов посредством ограничений


В предыдущей статье "Как избежать запутанности" (Avoiding Complexity) из серии "Принципы проектирования XML-схем" автор объяснил почему необходимо быть осторожным при использовании определения сложных типов посредством ограничения: "Правила определения сложных типов посредством наложения ограничений описаны в Разделах 3.4.6 и 3.9.6 Рекомендации W3C "XML Schema". Большинство багов в реализациях тесно связаны с этой функциональностью, и довольно часто при обсуждении различных нюансов получения таких производных типов разработчики высказывают самое серьезное недовольство. Более того, этот способ определения производных типов не полностью соответствует понятиям ни предметно-ориентированного программирования, ни теории реляционных баз данных, которые являются основными потребителями и создателями XML-данных".

Для того класса пользователей, которым важен контракт, основанный на проверке допустимости, получение производных типов посредством ограничения мало привлекательно, если вообще привлекательно, по сравнению с определением моделей содержания без задания ограничений. Приведенная ниже схема является эквивалентом рассмотренной выше с тем условием, что все, что от нее требуется, это гарантия того, что элемент XML-Deviant (или DareObasanjo) соответствует указанной модели данных.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:complexType name="XML-Deviant"> <xs:sequence> <xs:element name="numPosts" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="signature" type="xs:string" nillable="true" /> <xs:element name="email" type="xs:string" minOccurs="0" maxOccurs="1" /> </xs:sequence> <xs:attribute name="firstSubscribed" type="xs:date" use="optional" /> <xs:attribute name="mailReader" type="xs:string"/> </xs:complexType>


Кажется, что для пользователей, которые хотят использовать XML-схему для проверки XML-документа на соответствие контракту, определение производных сложных типов посредством расширений является отличным способом разложить на компоненты аспекты схемы и повторно воспользоваться ими. Однако, первое впечатление обманчиво - взаимодействие с другими конструкциями XML-схемы W3C, как, например, группами подстановки (substitution groups) и xsi:type, превращает использование определения производных сложных типов посредством расширений в разряд трудно контролируемых задач. Рассмотрим, например, следующее объявление элемента:

<xs:element name="xml-deviant" type="XML-Deviant" />
в котором объявляется элемент xml-deviant, тип которого, XML-Deviant, является сложным типом, описанным в приведенной выше схеме. Оба XML-элемента, приведенные в следующем фрагменте, являются допустимыми в соответствии с этим объявлением элемента xml-deviant:

<xml-deviant firstSubscribed="1999-05-31" > <email>johndoe@example.com</email> </xml-deviant>

<xml-deviant xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="DareObasanjo" firstSubscribed="1999-05-31" mailReader="Microsoft Outlook"> <email>dareo@online.microsoft.com</email> <signature>XML is about data not objects, that is the zen of XML.</signature> </xml-deviant>

Несмотря на то, что в объявлении этого элемента явно указано, что типом элемента xml-deviant является сложный тип XML-Deviant, экземпляр может замещать это объявление в схеме, используя атрибут xsi:type, при условии, что этот новый тип является подтипом первоначального типа. Это означает, что по умолчанию даже если элемент успешно прошел проверку на допустимость, он необязательно соответствует модели содержания, по которой, как полагает получатель, он проверяется. Схожая проблема возникает, когда рассматриваемое объявление элемента назначается заголовком (head) групп подстановок.

Существует два способа обойти эту потенциальную проблему, возникающую при определении производных сложных типов посредством расширений. Первый заключается в блокировании подстановки или определении производного типа посредством размещения атрибута block или final в объявлении элемента или в описании сложного типа. Аналогично, атрибут blockDefault или finalDefault может быть добавлен в элемент xs:schema для указания, какой вид подстановок или определения производных типов неразрешен в этой схеме. Второй способ состоит в использовании поименованных групп моделей (xs:group) и групп атрибутов для разбиения схемы на модули - как альтернатива определению производных сложных типов посредством расширений. Ниже приведена схема, которая была рассмотрена в предыдущем раздела и в которую были добавлены поименованные группы моделей. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">




<xs:complexType name="DareObasanjo"> <xs:sequence> <xs:element name="numPosts" type="xs:integer" minOccurs="1" /> <xs:element name="signature" type="xs:string" nillable="false" /> <xs:element name="email" type="xs:string" maxOccurs="0" /> </xs:sequence> <xs:attribute name="firstSubscribed" type="xs:date" use="required" /> <xs:attribute name="mailReader" type="xs:string" fixed="Microsoft Outlook" /> </xs:complexType>

</xs:schema>

Стоит заметить, что эта схема не обеспечивает отношения между типами XML-Deviant и DareObasanjo. Этот альтернативный подход неудовлетворителен для тех случаев, когда нужно поддерживать отношение подтипов.

Для сценариев использования, в которых схема применяется для создания строго типизированного XML, получение производных типов посредством ограничения чревато возникновением проблем. В реляционной модели и традиционных положениях об определении производных типов в объектно-ориентированных языках программирования отсутствует возможность накладывать ограничения на факультативные элементы и атрибуты. Приведенный выше пример, в котором элемент email является факультативным в базовом типе, а в производном не может появляться, несовместим с нотацией получения производного типа с позиции объектно-ориентированного подхода; его также трудно смоделировать, используя таблицы реляционной базы данных. Аналогично, изменение признака, указывающего, что модель содержания типа является пустой, не является характеристикой, которая соответствует реляционной или объектно-ориентированной моделям. С другой стороны, пример, в котором не используется получение производного типа посредством ограничения, более просто моделировать в виде классов на языке объектно-ориентированного программирования или в виде реляционных таблиц. Это важно, если учесть, что это уменьшает рассогласование, возникающее при попытке отобразить содержание XML-документа в реляционную базу данных или преобразовать его в экземпляр объектно-ориентированного класса.

Несмотря на то, что некоторые аспекты получения производных типов посредством ограничения плохо преобразуются, их все же можно реализовать напрямую, например, генерируя исключение при попытке обратиться к свойству или полю в производном типе, который был удален при наложении ограничения. Однако такое прямое задание ограничений XML-схемы W3C является неестественным для разработчиков, привыкших писать на объектно-ориентированных языках программирования, и маловероятно, чтобы эти правила стали общепринятыми у всех разработчиков инструментов преобразования XML-схемы W3C.



<xs:complexType name="XML-Deviant"> <xs:group ref="XMLDeviantGrp" /> <xs:attributeGroup ref="XMLDeviantAttrGrp" /> </xs:complexType>

<xs:complexType name="DareObasanjo"> <xs:sequence> <xs:group ref="XMLDeviantGrp" /> <xs:element name="signature" type="xs:string" /> </xs:sequence> <xs:attributeGroup ref="XMLDeviantAttrGrp" /> <xs:attribute name="mailReader" type="xs:string" fixed="Microsoft Outlook" /> </xs:complexType>

<xs:group name="XMLDeviantGrp"> <xs:sequence> <xs:element name="numPosts" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="email" type="xs:string" minOccurs="0" maxOccurs="1" /> </xs:sequence> </xs:group>

<xs:attributeGroup name="XMLDeviantAttrGrp"> <xs:attribute name="firstSubscribed" type="xs:date" use="optional" /> <xs:attribute name="lastPostDate" type="xs:date" use="optional" /> </xs:attributeGroup>

</xs:schema>

Для сценариев использования, которые применяют строго типизированные XML-документы, определение производных сложных типов посредством расширений представляет хотя и отличный, но родственный ряд проблем. В случае, если XML-схема используется в качестве основы преобразования между XML и объектно-ориентированной или реляционной моделями, такое определение производных сложных типов не оказывается проблематичным. Однако, при обработки таких строго типизированных XML-документов с помощью языков программирования, поддерживающих схему, как, например, XQuery или XSLT 2.0, возникают определенные сложности. XQuery - это статически типизированный язык, а это значит, что ожидается, что он обнаружит ошибки, связанные с типом, во время компиляции, а не во воремя исполнения. Следующий запрос, заданный к приведенному выше примеру, чреват возникновением проблем:



for $x in //xml-deviant return $x/signature

С одной стороны, это выражение должно привести к статической ошибке, поскольку элемент xml-deviant объявлен как элемент типа XML-Deviant, который не содержит элемент signature. С другой стороны, поскольку у XML-Deviant существует подтип, у которого в модели содержания есть элемент signature и который, следовательно, мог бы быть адресатом директивы xsi:type, это ошибка не должна расцениваться как статическая. Обе позиции являются допустимыми, но независимо от того, что выберет XQuery, всегда найдутся люди, которые будут ожидать противоположенное. Разработчики, знакомые с XPath, могут решить, что этот запрос будет работать, в то время как, те, кто освоился со статически типизированными языками, посчитает его эквивалентом следующего выражения и, таким образом, ошибкой:

foreach(xmldeviant b in list) { yield b.signature; // static type error. }

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


Рассмотрение определения производных сложных типов посредством ограничений


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

замена факультативного атрибута обязательным; изменение количества вхождений элемента, то есть когда новое число вхождений становится подмножеством первоначального (например, с minOccurs="1" и maxOccurs="unbounded" на minOccurs="2" и maxOccurs="4"); изменение значения атрибута, указывающего, что модель содержания элемента является пустой, с true на false; замена типа элемента или атрибута подтипом (например, с xs:integer в описании базового типа на xs:positiveInteger в описании производного);

задание в объявлении элемента или атрибута его фиксированного значения.

Определение производного типа посредством ограничений в основном удобно в сочетании с абстрактными элементами или типами. Так, можно создать абстрактный тип, который содержит все характеристики ряда связанных моделей содержания, а затем ограничить его для создания каждой из требуемых моделей содержания. Этот прием был рассмотрен в сообщении Роджера Костелло (Roger Costello), направленного в адрес XML-DEV, в котором он свел PublicationType к MagazineType.

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

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<!-- базовый тип -->

<xs:complexType name="XML-Deviant"> <xs:sequence> <xs:element name="numPosts" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="signature" type="xs:string" nillable="true" /> <xs:element name="email" type="xs:string" minOccurs="0" maxOccurs="1" /> </xs:sequence> <xs:attribute name="firstSubscribed" type="xs:date" use="optional" /> <xs:attribute name="mailReader" type="xs:string"/> </xs:complexType>


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

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

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<!-- базовый тип -->

<xs:complexType name="XML-Deviant"> <xs:sequence> <xs:element name="numPosts" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="email" type="xs:string" /> </xs:sequence> <xs:attribute name="firstSubscribed" type="xs:date" use="optional" /> <xs:attribute name="lastPostDate" type="xs:date" use="optional" /> </xs:complexType>

<!-- производный тип --> <xs:complexType name="DareObasanjo"> <xs:complexContent> <xs:extension base="XML-Deviant"> <xs:sequence> <xs:element name="signature" type="xs:string" /> </xs:sequence> <xs:attribute name="mailReader" type="xs:string" fixed="Microsoft Outlook" /> </xs:extension> </xs:complexContent> </xs:complexType>

</xs:schema>




<!-- производный тип --> <xs:complexType name="DareObasanjo"> <xs:complexContent> <xs:restriction base="XML-Deviant"> <xs:sequence> <xs:element name="numPosts" type="xs:integer" minOccurs="1" /> <xs:element name="signature" type="xs:string" nillable="false" /> <xs:element name="email" type="xs:string" maxOccurs="0" /> </xs:sequence> <xs:attribute name="firstSubscribed" type="xs:date" use="required" /> <xs:attribute name="mailReader" type="xs:string" fixed="Microsoft Outlook" /> </xs:restriction> </xs:complexContent> </xs:complexType>

</xs:schema>

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


Зачем проверять XML-документы на допустимость


Рекомендация консорциума W3C "XML Schema" - это всего лишь одна из множества спецификаций языков XML-схем: DTD, RELAX NG и XML Data-Reduced. Для описания структуры XML-документа в XML-схеме определяются допустимые элементы, которые могут находится в документе, порядок их следования, а также ограничения, накладываемые на определенные характеристики этих элементов. Все более широкое распространение языка XML и языков XML-схем выявило два основных сценария использования XML-схем для проверки допустимости XML- документа.

Описание и обеспечение соблюдения контракта между авторами и получателями XML-документов: обычно XML-схема используется получателями и авторами XML-документов в качестве средства для понимания структуры передаваемого или формируемого документа. Схемы - это довольно сжатый машиночитаемый способ описания состава допустимого XML-документа, допустимого согласно отдельному XML-словарю. Таким образом, схема может рассматриваться как контракт между автором и получателем XML-документа. Как правило получатель сверяет передаваемый XML-документ с этим контрактом, проверив его допустимость по схеме.
Это описание контракта охватывает широкий спектр сценариев использования языка XML, начиная бизнес-субъектами, обменивающимися XML-документами, и заканчивая приложениями, в которых используются конфигурационные XML-файлы. Формирование основы для обработки и хранения типизированных данных, представленных в виде XML-документов: популярность языка XML как способа представления жестко структурированных, строго типизированных данных, таких как, например, содержимое реляционной базы или объектов различных языков программирования, потребовала возможности описывать типы данных элементов XML-документа. В результате, появились языки схем XML Data и XML Data-Reduced, а затем и XML-схема W3C. Эти языки схем используются для преобразования входного информационного набора XML (XML infoset) в аннотированный информационный набор типов (type annotated infoset (TAI)), в котором информационные единицы элемента и атрибута снабжены (аннотированы) именами типов.
В рекомендации консорциума W3C "XML Schema" описывается создание аннотированного информационного набора типов, появляющегося в результате проверки допустимости документа по схеме. При проверке документа по XML-схеме W3C входной информационный набор XML преобразуется в постверификационный информационный набор (post schema validation infoset (PSVI)), в котором помимо всего прочего содержатся аннотации типов. Однако, практический опыт показывает, что для создания аннотированных информационных наборов типов не требуется проведения полной проверки допустимости документа; как правило, большинство приложений, в которых используются XML-схемы для формирования строго типизированных XML-документов, например, для преобразования XML<->объект, не выполняет полной проверку допустимости документов, поскольку ряд конструкций XML-схемы W3C не соответствует понятиям предметной области.

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



С учетом нынешнего уровня развития


С учетом нынешнего уровня развития технологий возможность определения производных сложных типов в соответствии с положениями XML-схемы W3C скорее добавит сложности, а не упростит ситуацию в двух наиболее общих случаях использования схемы. Для сценариев проверки допустимости документов получение производных типов посредством ограничений имеет минимальную ценность, но получение производных типов посредством расширений - это удобный способ применить модульный подход и воспользоваться принципом повторного использования. Однако, следует внимательно изучить последствия использования подстановок различных типов (xsi:type и группы подстановок) при определении производных типов посредством расширения в сценариях, задействованных в проверке допустимости документа.
В настоящий момент обработка и хранение строго типизированных XML-данных - это удел традиционных объектно-ориентированных языков программирования и реляционных баз данных. Это означает, что определенные возможности XML-схемы W3C, такие как получение производного типа посредством ограничения (и в меньшей степени определение производного типа посредством расширения) являются причиной возникновения несоответствия между системой типов, используемых для описания строго типизированного XML-документа, и механизма, применяемого для обработки и хранения вышеупомянутого XML. В конечном счете, когда такие технологии, как XQuery, получат широкое распространение как средство обработки и поддержки типизированных XML-документов, а XML-схема W3C будет интегрирована в основные продукты баз данных, это несоответствии перестанет быть существенным. Но до этого момента необходимо тщательно продумывать, применять ли определение производных сложных типов в ситуациях, в которых XML-схема W3C используется главным образом как механизм создания аннотированных информационных наборов типов XML.