При создании XML-документа мы можем столкнуться с тем, что разные по смыслу элементы будут иметь одинаковое имя. Вы можете увидеть пример в статье «10 главных ошибок RSS» в пункте 5 «Неправильное расширение RSS».

Разберём пример, явно «притянутый за уши», зато простой для понимания. Нам необходимо сделать выборку из двух таблиц базы данных, касающихся творчества некоего музыкального коллектива и сформировать каталог в виде XML-документа. В одной таблице базы данных содержится информация об аудио записях коллектива, в другой – информация о книгах посвященных его творчеству. По какой-то причине (непонятно какой, но очень важной), и описание аудио записей и описание книг должно содержаться в элементе «item». По той же причине, и названия записей и названия книг должны содержаться в элементе «title».

В результате получаем, что-то вроде этого:

1
2
3
4
5
6
7
8

<catalog>
    <item>
        <title />
    </item>
    <item>
        <title />
    </item>
</catalog>

Налицо конфликт имен, так как сложно определить, какой вид данных содержит каждый из элементов «item» и «title». Первый блок «item» относится к дискографии и элемент «title» содержит название диска. Второй блок «item» относится к библиографии и элемент «title» содержит название книги. Для предотвращения подобного конфликта нам надо разделить эти группы логически. Делается это заданием пространства имен: одни элементы относятся к имени «music», другие — к имени «book». Для объявления пространствa имeн используeтся атрибут имя которого состоит из зарезервированного слова «xmlns», после которого следует двоеточие и, собстветнно, само имя:

xmlns:music = "http://ininfo.biz/music"

Первый вопрос, который возникает, что использовать в качестве значения атрибута «xmlns»? Для того, чтобы обеспечить уникальность пространства имен надо использовать какой-либо URI (Uniform Resource Identifier, Унифицированный Идентификатор Ресурса), проще говоря — уникальную строку, которая будет однозначно идентифицировать данный элемент^*. Многие используют в качестве идентификатора URL, так как имена доменов, которые используются в URL являются уникальными. Кроме того, вряд ли кто-нибудь будет использовать адрес «http://ininfo.biz/book» кроме его владельца, так что конфликт исключен.

Пространства имен для элементов

Указание на то, к какому пространству имен относится тот или иной элемент, записывается перед началом имени элемента с разделителем в виде двоеточия:

<music:title />

Исходя из вышеизложенного, в принципе, можно объявить пространство имен для каждого элемента, который используется в документе:

1
2
3
4
5
6
7
8

<catalog>
    <music:item xmlns:music = "http://ininfo.biz/music">
        <music:title xmlns:music = "http://ininfo.biz/music" />
    </music:item xmlns:music = "http://ininfo.biz/music">
    <book:item xmlns:book = "http://ininfo.biz/book">
        <book:title xmlns:book = "http://ininfo.biz/book" />
    </book:item xmlns:book = "http://ininfo.biz/book">
</catalog>

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

Пространство имен объявленное для какого-либо элемента, является таковым для всех вложенных в него элементов, если для них не объявлено других пространств имен.

1
2
3
4
5
6
7
8

<music:catalog xmlns:music = "http://ininfo.biz/music">
    <music:item>
        <music:title />
    </music:item>
    <book:item xmlns:book = "http://ininfo.biz/book">
        <book:title />
    </book:item>
</music:catalog>

Можно поступить еще проще — объявить все пространства имен за один раз в корневом элементе:

1
2
3
4
5
6
7
8
9
10

<music:catalog 
    xmlns:music = "http://ininfo.biz/music"
    xmlns:book = "http://ininfo.biz/book">
    <music:item>
        <music:title />
    </music:item>
    <book:item>
        <book:title />
    </book:item>
</music:catalog>

Однако надо помнить, что идентификатором пространства имен является значение атрибута «xmlns», а не его название-префикс. В следующем примере все элементы принадлежат одному пространству(значение атрибута равно «http://ininfo.biz/group») хотя и имеют разные имена-префиксы(«music» и «book»):

1
2
3
4
5
6
7
8
9
10

<music:catalog 
    xmlns:music = "http://ininfo.biz/group"
    xmlns:book = "http://ininfo.biz/group">
    <music:item>
        <music:title />
    </music:item>
    <book:item>
        <book:title />
    </book:item>
</music:catalog>

Допускается и обратное — элементы имеют различные пространства имен, но используют одинаковые имена-префиксы:

1
2
3
4
5
6
7
8

<catalog>
    <group:item xmlns:group = "http://ininfo.biz/music">
        <group:title />
    </group:item>
    <group:item xmlns:group = "http://ininfo.biz/book">
        <group:title />
    </group:item>
</catalog>

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

1
2
3
4
5
6
7
8

<catalog>
    <item xmlns = "http://ininfo.biz/music">
        <title />
    </item>
    <item xmlns = "http://ininfo.biz/book">
        <title />
    </item>
</catalog>

Для того, чтобы отменить пространство имен заданное по-умолчанию, необходимо присвоить атрибуту «xmlns» значение пустой строки:

1
2
3
4
5
6
7
8
9

<catalog 
    xmlns = "http://ininfo.biz/group">
    <item>
        <title />
    </item>
    <item xmlns = "">
        <title />
    </item>
</catalog>

Пространства имен для атрибутов элементов

Также как и элементы, к заданному пространству имен могут быть отнесены и их атрибуты:

1
2
3
4
5
6
7
8
9
10

<music:catalog 
    xmlns:music = "http://ininfo.biz/music"
    xmlns:book = "http://ininfo.biz/book">
    <music:item music:number="10">
        <music:title book:numref="20" />
    </music:item>
    <book:item book:number="20">
        <book:title music:numref="10" />
    </book:item>
</music:catalog>

Однако пространство имен по-умолчанию на атрибуты не распостраняется. Если у атрибута не указан префикс, то он не принадлежит ни к одному пространству имен:

1
2
3
4
5
6
7
8
9
10

<music:catalog 
    xmlns:music = "http://ininfo.biz/music"
    xmlns:book = "http://ininfo.biz/book">
    <music:item music:number="10">
        <music:title numref="20" />
    </music:item>
    <book:item book:number="20">
        <book:title numref="10" />
    </book:item>
</music:catalog>

Вышеизложенное верно и для случая, когда пространство имен задано для элемента, к которому принадлежит атрибут, например:

<music:item number="10" 
    xmlns:music = "http://ininfo.biz/music">

Чтобы совсем запутаться, можно отметить, что объявление пространства имен действует в рамках того элемента, в котором оно встречается:

1
2
3
4
5
6
7
8
9

<root xmlns:primer = "http://ininfo.biz/one"> 
    <primer:el1 xmlns:primer = "http://ininfo.biz/two"> 
        <primer:el2 /> 
        <el3 xmlns:primer = "http://ininfo.biz/three"> 
            <primer:el2 />
        </el3> 
    </primer:el1> 
    <primer:el2 /> 
</root>

Возможно, эта статья будет дополнена. Поэтому, продолжение следует и следите за обновлениями.

^* У гражданина РФ уникальным идентификатором может считаться его ИНН. Не номер паспорта – паспорт трижды меняется и, в случае потери, выписывается новый.

1. Синтаксические ошибки RSS потока

Многие разработчики забывают о том, что RSS — это, прежде всего, XML. А XML-документы изначально «не прощают» ошибки, так как большинство XML анализаторов работают по принципу: «Или этот XML документ не нарушает синтаксис, или это не XML». В отличие от HTML, DOM анализатор обязан отказаться от разбора XML документа, если в документе есть ошибки. Поэтому контролировать синтаксис своего RSS просто необходимо! Существуют множество инструментов для проверки RSS-каналов, но, пожалуй, самый популярный — http://feedvalidator.org/

Рекомендация: используйте RSS агрегатор, чувствительный к ошибкам. Многие RSS агрегаторы могут игнорировать ошибки, используя не XML DOM парсер (который, как мы отметили, обязан отказаться от анализа в случае ошибки), а свои собственные, но большинство всё же используют именно DOM парсер. Вот пример такого агрегатора: RSS Bandit. Установите этот бесплатный агрегатор к себе на компьютер и подпишитесь в нём на собственный RSS канал. Если у вас возникнут ошибки, вы узнаете о них первым!

2. Использование спец.символов HTML в заголовках или описаниях элементов RSS

Очень распространенная ошибка! Веб-мастера очень привыкли использовать так называемые спец. символы типа   " и др. Ну и понятно, если RSS лента генерируется автоматически (что бывает в 99.9% случаев), то такие символы попадают в заголовок элемента или в его описание, например:

<item>
	<title>&nbsp;Вот моя &quot;новость&quot;</title>
	<pubDate>Thu, 19 Feb 2009 09:00:47 +0300</pubDate>
	<link>http://www.mysite.ru/item1</link>
	<description>&nbsp;Это моя &quot;новость&quot;</description>
	<guid>http://www.mysite.ru/item1</guid>
</item>

Формально   и другие сущности не определены в XML разметке, что приводит к неизбежным ошибкам вашей ленты. Как этого избежать?

Рекомендация 1: Если вы используете автоматическую генерацию RSS, заключайте содержимое элементов title и description в секции CDATA, например:

<item>
	<title><![CDATA[[&nbsp;Вот моя &quot;новость&quot;]]></title>
	<pubDate>Thu, 19 Feb 2009 09:00:47 +0300</pubDate>
	<link>http://www.mysite.ru/item1</link>
	<description><![CDATA[[&nbsp;Это моя &quot;новость&quot;]]></description>
	<guid>http://www.mysite.ru/item1</guid>
</item>

Рекомендация 2: Вообще-то, может быть имеет смысл выглянуть в окошко и заметить, что на дворе уже как 9-й год идёт во всю XXI век, век юникода. И также имеет смысл не заменять специальные символы на их HTML-представление, а просто их использовать в своих текстах. Например, если вам нужны кавычки, просто набирайте их в своей ленте (это символы набираются как Alt+0171 и Alt+0187):

<item>
	<title>Вот моя «новость»</title>
	<pubDate>Thu, 19 Feb 2009 09:00:47 +0300</pubDate>
	<link>http://www.mysite.ru/item1</link>
	<description>Это моя «новость»</description>
	<guid>http://www.mysite.ru/item1</guid>
</item>

Если нужен неразрывный пробел — просто его поставьте как символ Alt+0160 (U+ 00A0)

Более подробно см. здесь:

• http://ru.wikipedia.org/wiki/Пробел
• http://ru.wikipedia.org/wiki/Юникод
• http://ru.wikipedia.org/wiki/Символы,_представленные_в_Юникоде

3. HTML теги в description

Самый распространенный случай! Вообще-то, это — не ошибка, но всё же, неточность. Формально, элемент description — это краткое текстовое описание вашей новости. Мы знаем, что HTML и XML не совместимы просто синтаксически (XHTML — пожалуйста, но не HTML), и прямое использование HTML в description формально нарушает грамматику RSS. Поэтому в спецификации RSS читаем: «допускается использование только экранированной разметки HTML» («An item may also be complete in itself, if so, the description contains the text (entity-encoded HTML is allowed)»)

<description>this is &lt;b&gt;bold&lt;/b&gt;</description>

Но, всё же, я не рекомендую так поступать. Дело в том, что есть агрегаторы, которые считают содержимое элемента description текстом и выводят его как текст, не воспринимая его внутреннюю разметку. И в результате пользователь увидит примерно следующее:

this is <b>bold</b>

Понятно, такой текст прочитать невозможно. Я однажды озадачился идеей поставить себе скринсейвер Windows, который бы показывал новости из RSS потоков. И в результате я отказался от этой идеи — они все показывали новость именно в таком виде!

Рекомендация: В элементе description используйте только текст. А форматированный текст пишите, используя расширения RDF Site Summary Modules, например, вот так (обратите внимание на объявление пространства имен с префиксом content):

<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
	<!-- ... -->
		<item>
			<title>Вот моя «новость»</title>
			<pubDate>Thu, 19 Feb 2009 09:00:47 +0300</pubDate>
			<link>http://www.mysite.ru/item1</link>
			<description>Это моя «новость»</description>
			<guid>http://www.mysite.ru/item1</guid>
			<!-- Здесь полный и HTML форматированный текст элемента -->
			<content:encoded><![CDATA[<p>What a <em>beautiful</em> day!</p>]]></content:encoded>
		</item>
	<!-- ... -->
	</channel>
</rss>

Такой способ понимается практически всеми RSS агрегаторами (мне известен только один распространенный агрегатор, который не понимает такое расширение — встроенный в FireFox)

4. Неправильная разметка в HTML

При представлении форматированного текста в RSS многие Веб-мастера пытаются перенести в RSS элемент чуть ли не весь дизайн своего сайта. Так вот, этого делать не следует. Дело в том, что каждый RSS агрегатор отображает элементы RSS по-своему, и вы не знаете, каким именно агрегатором будет пользоваться ваш пользователь: это может быть и desktop-агрегатор, такой как RSS bandit, и online-агрегатор, как Goole Reader или Яндекс.Лента, или вообще агрегатор на мобильном телефоне. У каждого из них свои возможности, и ваша красивая верстка колонками может просто не вписаться в экран пользователя.

Рекомендация: используйте следующие простые правила:

1. Никогда не фиксируйте ширину текста своего элемента — пусть текст заполняет все доступное пространство
2. Никогда явно не указывайте размер шрифта в абсолютных единицах, например, px, pt. Лучше использовать либо em, ex, или относительные размеры, например, 80%
3. Никогда явно не указывайте цвет фона и желательно не указывайте цвет шрифта (ссылок и т.п.). У агрегатора может быть свой фон (например, темный) и указанный вами цвет шрифта начнет с ним сливаться.
4. Никогда не используйте колонки текста, опять же — представление текста отдайте на откуп агрегатору

5. Неправильное расширение RSS

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

Например, вот фрагмент RSS известного новостного сайта Росбалт:

<item>
	<title>По делу грабителей, похитивших 43 млн рублей, проверяет лиц, знавших о сделке</title>
	<link>http://www.rosbalt.ru/2009/02/23/620591.html</link>
	<category/>
	<section>Главная лента</section>
	<pubDate>Mon, 23 Feb 2009 19:42:00 +0300</pubDate>
	<full-text>МОСКВА, 23 февраля. Следователи в рамках уголовного ....</full-text>
</item>

Легко увидеть, что, с одной стороны, разработчики «забыли» про обязательный элемент description, но добавили свои элементы section и full-text, чем формально нарушили стандарт.

Читаем в спецификации: «Канал RSS 2.0 может содержать элементы и атрибуты, не упомянутые на этой странице, только если они определены в своих пространствах имен.»

То есть, в данном случае мы можем решить эту проблему следующим образом: полный текст вынести на элемент content:encoded как рекомендовано в совете №3, а раздел новости указать хотя бы так:

<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:rosbalt="http://www.rosbalt.ru/my-rss-schema">
	<channel>
		<item>
			<title>По делу грабителей, похитивших 43 млн рублей, проверяет лиц, знавших о сделке</title>
			<link>http://www.rosbalt.ru/2009/02/23/620591.html</link>
			<category/>
			<rosbalt:section>Главная лента</rosbalt:section>
			<pubDate>Mon, 23 Feb 2009 19:42:00 +0300</pubDate>
			<content:encoded>МОСКВА, 23 февраля. ....</content:encoded>
		</item>
	</channel>
</rss>

Здесь мы ввели свое пространство имен и элемент section вынесли в него.

Рекомендация: при расширении RSS своими элементами всегда объявляйте свои пространства имен или используйте существующие схемы.

6. Отсутствие элемента GUID

Несмотря на то, что элемент guid не является обязательным, тем не менее подавляющее число агрегаторов используют его для идентификации элемента. Если в вашем RSS потоки элементы item не будут иметь guid, есть вероятность того, что агрегатор будет загружать одни и те же элементы повторно. Например, так ведет себя RSS-Hub на коммуникаторах HTC Touch Cruise.

Рекомендация: всегда явно указывайте уникальный guid у каждого из элементов RSS.

7. Неправильное указание даты элемента

У элемента item, как правило, присутствует дата публикации, указанная с помощью элемента pubDate. Так вот, эта дата указывается не в формате XSD Date and Time, что логично было бы предположить, а в старом формате RFC822, то есть так:

<pubDate>Sun, 19 May 2002 15:21:36 GMT</pubDate>

Рекомендация: обязательно проверяйте в каком формате вы передаёте дату.

8. Неправильная ссылка на RSS в HTML странице

Добавив к себе на сайт RSS поток (или несколько потоков), не забудьте указать браузерам, что эти RSS потоки у вас есть. Заметьте, это делается не просто ссылкой на странице (хотя и ссылка на странице не помешает), а объявлением в разделе head вашего HTML:

<head>
...
	<link rel="alternate" type="application/rss+xml"
		title="Мой сайт: новости" href="http://www.mysite.ru/rss.xml" />
 
	<link rel="alternate" type="application/rss+xml"
		title="Мой сайт: комментарии к заметкам" href="http://www.mysite.ru/comments.xml" />
...
</head>

Обратите внимание на атрибут title элемента link. Это название вашего RSS потока. Крайне желательно указать там внятное название вашего канала, а не просто безликое «RSS 2.0». Вообще, многие любят одновременно указывать несколько форматов, например, RSS 0.9, RSS 1.0, RSS 2.0, Atom. Я, честно говоря, считаю это, как бы помягче выразится, снобизмом. Ну зачем одновременно предлагать пользователю несколько практически идентичных форматов? Скажите, вы сами можете вот так, на вскидку, называть отличия RSS 1.0 от RSS 2.0? А вы думаете пользователь об этом знает? Ничего подобного! Поэтому лучше выбрать один формат и использовать его, тем более все агрегаторы, как правило, легко понимают эти форматы.

Рекомендация: выберите для себя наиболее приемлемый формат (RSS 2.0 или Atom) и придерживайтесь только его. Явно укажите ссылку на RSS поток на всех страницах сайта с помощью элемента link. Не забудьте написать внятный заголовок своего RSS.

9. Бестолковое использование виджетов в разметке элемента

Сейчас очень популярны так называемые виджеты, позволяющие одним кликом добавить RSS в любимый пользователем online агрегатор новостей. Как правило, это графическая ссылка на соответствующую службу с изображением логотипа этой службы. А поскольку таких служб много, Веб-мастера похоже соревнуются друг с другом, кто больше приляпает этих самых виджетов в свои RSS ленты:

Так вот, это уже не снобизм, а скорее — дебилизм! Нет, на сайте размещайте виджеты сколько угодно! Но зачем пихать 26 картинок к КАЖДОЙ ЗАПИСИ своего блога, к КАЖДОЙ НОВОСТИ своего сайта, то есть в RSS, если учесть, что пользователь УЖЕ ЧИТАЕТ ваш RSS с помощью своего любимого агрегатора! То есть, пользователь уже подписался на ваш канал, и эти ссылки ему попросту не нужны!

Рекомендация: виджеты подписки на ваш RSS размещайте на сайте, а не в тексте самих элементов RSS.

10. Полнота изложения

Ну и самая, пожалуй, распространенная «ошибка» — неполный текст новости/заметки и т.п. в RSS. Вы наверняка замечали, что большинство RSS передаются в виде анонсов, то есть не содержат в себе полный текст материала. Здесь в принципе существует несколько диаметрально противоположных точек зрения: например, некоторые считают, что пользователя нужно «подразнить», показав ему только лишь часть заметки и тем самым заставив его щелкнуть по ссылке «Читать далее» и перейти на сайт. Что ж, по-своему приверженцы такого подхода правы.

Правда, я считаю, что самая главная ценность RSS в том, что пользователь может быть в курсе событий, вообще не открывая сайты ! Я, например, практически все свои RSS читаю в транспорте на мобильном телефоне. И когда скорость GPRS соединения снижается, открывать сайты для чтения статьи дальше становится очень некомфортно. Сам же телефон закачивает все RSS утром, при синхронизации с основным компьютером. Понятно, RSS с обрывочными новостями и ссылками «Читать далее» долго в моем агрегаторе не живут, я их просто удаляю! И вы, как автор сайта с такими RSS перестаете для меня существовать, потому что, я уже не помню где и когда я подписался на ваш RSS. С другой стороны, RSS с полным содержанием живут у меня годами, даже если мне неинтересна ваша новость, пролистать ее невероятно легко, буквально одним движением пальца.

Важно помнить, что наша основная задача при публикации RSS — обеспечить постоянную читающую аудиторию сайта, а не увеличить посещаемость! Ведь пользователь, постоянно читающий ваш RSS, относится к вашему сайту с бо́льшей степенью доверия, чем просто к сайту, и важно не отпугнуть такого пользователя.

Поэтому рекомендация: публикуйте в RSS материалы полностью! Ну разве что, исключение составляет статья объемом более 10 – 20 машинопечатных страниц… Если, конечно же, вы такие статьи пишете

Таким образом, мы видим, что RSS — это великолепная штука, особенно если его правильно подать. Успехов вам!

Некоторые полезные ссылки:

• Спецификация RSS 2.0
• Спецификация RSS 2.0 на русском языке

Post Scriptum
Скачать презентацию семинара по теме этой статьи можно по этой ссылке:
Основные ошибки при создании RSS.pps

Спецификация SGML предусматривает создание новых языков разметки.
HTML и XML как раз таковыми и являются. Причём XML сам по себе предусматривает расширяемость. Документы созданные с помощью этих языков могут быть «корректными (well-formed)» и «допустимыми (valid)».

С проверкой документа на корректность проблем не возникает: если ошибок не выскочило и всё отобразилось так, как мы хотели, то документ корректен. Например, если в HTML-документе написать что-то вроде «<Z>Привет!</Z>», то наш документ будет полностью корректен, но проигнорирован браузером. Почему? Потому что браузер ничего не знает о том, что это за «Z» такой. И если мы проверим наш документ на допустимость с помощью валидатора, то документ таковым признан не будет. А как об этом узнает валидатор и на основании чего он вынес такой вердикт?

Допустимость проверяется с помощью определения типа документа (DTD, document type definition). Например, для «строгого» HTML он выглядит так.

DTD может быть описан как внутри документа, так и вынесен в отдельный файл (аналогия с CSS: встроенные и подключаемые таблицы стилей).

Объявление DTD

Объявление DTD располагается перед первым (корневым) элементом документа, начинается с последовательности «<!DOCTYPE» и заканчивается символом «>».

Внутреннее DTD описывается так:

<!DOCTYPE catalog [
 
]
>

Между квадратными скобками располагается содержимое DTD, так называемое внутреннее подмножество, например:

<!DOCTYPE catalog [
    <!ELEMENT someelement (#PCDATA)>
]
>

Если DTD вынесено в отдельный файл (обычно имеющий расширение .dtd), то его объявление в документе записывается так:

<!DOCTYPE catalog SYSTEM "catalog.dtd">

Соответственно, в этом файле и прописываются все правила, так называемое внешнее подмножество.

Имя, указанное за словом «DOCTYPE» (в нашем случае «catalog»), должно соответствовать имени корневого элемента. То есть, XML-документ должен быть примерно таким:

<?xml version="1.0"?>
<!DOCTYPE catalog SYSTEM "catalog.dtd">
<catalog>
  <someelement>Hello, world!</someelement>
</catalog>

Вместо ключевого слова «SYSTEM» может быть использовано слово «PUBLIC», указывающее, что DTD применяется для широкого использования:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">

Внутренние и внешние подмножества могут быть заданы одновременно (опять же, аналогия с CSS):

<!DOCTYPE catalog SYSTEM "catalog.dtd"[
    <!ELEMENT someelement (#PCDATA)>
]
>

Здесь, сначала зачитывается содержимое файла «catalog.dtd», а потом содержимое, указанное внутри квадратных скобок.

Элементы документа

Элементы объявляются в DTD с помощью ключевого слова «ELEMENT», после которого следует имя элемента и его содержимое заключенное в круглые скобки :

<ELEMENT book (#PCDATA)>

Если у элемента есть дочерние элементы, то это записывается так:

<!ELEMENT book (title)>

что соответствует документу:

1
2
3

<book>
    <title />
</book>

Если у элемента несколько дочерних элементов, то они перечисляются через запятую и должны следовать строго в указанном порядке:

<!ELEMENT book (title, author)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>

Приведённый выше пример читается следующим образом. Элемент «book» должен содержать только один элемент «title», за которым должен следовать только один элемент «author». Сами элементы «title» и «author» никаких элементов не содержат, а могут содержать лишь какой-нибудь текст.

С помощью следующих специальных символов можно определять количественное присутствие элемента:

• Символ «*», следующий после элемента, означает, что элемент может присутствовать один или несколько раз, или не присутствовать вовсе(от нуля до + бесконечности)
• Символ «+», следующий после элемента, означает, что элемент может присутствовать один или несколько раз(от 1 до + бесконечности)
• Символ «?», следующий после элемента, означает, что элемент может либо отсуствовать, либо присутствовать только один раз(0 или 1)

<!ELEMENT book (title, author)>
...
<!ELEMENT book (title*, author)>
...
<!ELEMENT book (title+, author)>
...
<!ELEMENT book (title?, author)>

Если существует необходимость указать один из нескольких элементов (или title, или author – любой из них, но не оба), надо испольовать символ «|»:

<!ELEMENT book (title | author)>

Текст тоже равноправный участник игры. Ключевое слово «PCDATA» указывает на анализируемые символьные данные, поэтому любой текст содержащий символы разметки («<», «>» и «&») будет трактоваться как разметка. Совместное использование текста и элементов называется смешанным содержимым. При объявлении смешанного содержимого, «PCDATA» необходимо указывать первым:

<!ELEMENT book (#PCDATA | title | author)>

Следующий фрагмент документа валиден вышеприведенному примеру:

1
2
3
4
5
6
7
8
9

<book>
    <title />
</book>
<book>
    <author />
</book>
<book>
    Нет данных
</book>

Группы элементов заключаются в круглые скобки. Элемент «book» должен содержать либо текст, либо (один «title», один или неколько «author» и может быть один «pubyear» именно в таком порядке):

<!ELEMENT book (#PCDATA | (title, author+, pubyear?))>
<!ELEMENT disc (#PCDATA | title)*>

Данному примеру соответствует следующий фрагмент XML-документа:

1
2
3
4
5
6
7
8
9

<disc />
<book>
    <title />
    <author />
    <author />
</book>
<book>
    Нет данных
</book>

Элемент может быть пустым. Такой элемент не может содержать не дочерних элементов ни текста (например, элемент «br» в HTML). Такой элемент задается с ключевым словом «EMPTY»:

<!ELEMENT photo EMPTY>

Элемент также может быть объявлен с ключевым словом «ANY» означающее, что элемент может содержать и элементы, и текст, и все это вместе, и даже быть пустым.

Атрибуты элементов

Элементы в XML-документе могут иметь атрибуты, которые записываются в виде «имя = значение» в открывающем или пустом тегах. Общее объявление атрибутов конкретного элемента начинается с ключевого слова «ATTLIST», после которого следует имя данного элемента и объявления самих атрибутов:

<!ELEMENT title (#PCDATA)>
    <!ATTLIST title
           id CDATA #REQUIRED
           stock CDATA #IMPLIED>

Ключевое слово «REQUIRED» указывает на то, что атрибут обязателен. Ключевое слово «IMPLIED», наоборот, говорит, что атрибут необязателен.

У атрибутов могут быть перечисленны разрешенные значения:

<!ATTLIST title
       readonly (yes|no) #REQUIRED>

Также может быть задано значение по-умолчанию:

<!ATTLIST title
       readonly (yes|no) #REQUIRED "yes">
       pubyear CDATA #IMPLIED "2007">

Атрибут может быть и константой, то есть у него может быть только то значение, которое заявлено в объявлении атрибута. Делается это с помощью ключевого слова «FIXED»:

<!ATTLIST title
       copyright <strong>#FIXED "udvikler">

Тип атрибута «CDATA»позволяет использовать любые символы кроме «<», «>», «&», «"» и «'». В случае использования, данные символы должны быть заменены на спецсимволы типа «<» и т.п. Внимание: в DTD ключевое слово «CDATA» имеет другое значение, чем раздел «CDATA» в XML-документе!

Помимо типа CDATA, атрибуты могут иметь следующие типы:

• NMTOKEN — может содержать только буквы, цифры, «.», «-», «_» и «:»
• NMTOKENS — может содержать те же символы, что и «NMTOKEN», а также символы пробела, возврата каретки, перевода строки и табуляции

<!ATTLIST title
       id CDATA #REQUIRED
       stock NMTOKEN #IMPLIED
       publisher NMTOKENS #IMPLIED>

Еще один тип атрибута «ID» разрешает задавать те же значения, что и тип NMTOKEN, но начинаться значение должно либо с буквы, либо с «_», либо с «:». У любого элемента может быть только один атрибут с типом «ID». Атрибут типа «ID» не может быть константой (объявляться как «FIXED»). Значение атрибута типа «ID» должно быть уникальным для всего XML-документа:

<!ELEMENT book (title, author)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>
    <!ATTLIST title
           id ID #REQUIRED
           stock CDATA #IMPLIED>
    <!ATTLIST author
           id ID #REQUIRED
           city CDATA #IMPLIED>

Атрибут элемента может быть ссылкой на атрибут типа «ID» другого элемента. Для этого он объявляется как атрибут типа «IDREF». Если атрибут должен ссылаться на атрибут типа «ID» нескольких элементов, то испольуется ключевое слово «IDREFS»:

<!ELEMENT book (title+, author, year, publisher)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT author (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT publisher (#PCDATA)>
    <!ATTLIST title
           id ID #REQUIRED>
    <!ATTLIST author
           id ID #REQUIRED>
    <!ATTLIST year
           ref IDREF #REQUIRED>
    <!ATTLIST publisher
           from IDREFS #REQUIRED>

В XML-документе это будет выглядить так:

1
2
3
4
5
6
7
8

<book>
    <title id="t1" />
    <title id="t2" />
    <title id="t3" />
    <author id="a1" />
    <year ref="t2" />
    <publisher from="t1 t2 a1" />
</book>

Объявление сущностей

Помимо элементов и их атрибутов, мы можем определить сущности, записываемые с помощью ключевого слова «ENTITY»:

<!ENTITY name "SuperMegaMaster">

В XML-документе ссылка на эту сущность определяется следующим образом (амперсанд + имя сущности + точка с запятой):

1

<userName>&name;</userName>

В результате чего, на место имени сущности «name», будет подставлено ее значение, в нашем случае – «SuperMegaMaster».

И для полноты нашего счастья, надо добавить, что атрибуты элементов могут иметь в качестве значения подобные сущности – сущности-атрибуты. Они тоже определяются с помощью ключевого слова «ENTITY», но имеют одно ограничение – они должны ссылаться на внешние неанализируемые сущности, определенные во внешнем подмножестве DTD:

<!DOCTYPE catalog [
    <!ENTITY list SYSTEM "companyList.html" NDATA parse>
    <!ELEMENT catalog (user+)>
    <!ELEMENT user (name)>
        <!ATTLIST user company ENTITY #REQUIRED>
    <!ELEMENT name (#PCDATA)>
]
>

В вышеприведённом примере, объявлена сущность «list», которая ссылается на внешний документ «companyList.html». Ключевое слово «NDATA», говорит о том, что внешний документ неявляется XML-документом. Далее, для элемента «user» объявляется атрибут «company», который является обязательным и имеет тип «ENTITY», то есть ссылается на какую-либо сущность. Поскольку в нашем пример задана только одна сущность («list»), то именно она и только она может быть значением атрибута «company» в XML-документе:

1
2
3
4
5

<catalog>
    <user company="list">
        <name>SuperMegaMaster</name>
    </user>
</catalog>

Осталось только понять, что означает «parse» в строке объявления сущности «list»? Когда используются неанализируемые данные, то есть те, которые не анализируются синтаксическим анализатором XML, хорошо было бы дать информацию приложению (использующему данный XML-документ), каким образом обработать эту сущность, если все-таки потребуется. Для этого нужно использовать нотацию, задаваемую ключевым словом «NOTATION» и дополнить наш DTD следующим образом:

<!NOTATION parse SYSTEM "iexlorer">
<!ENTITY list SYSTEM "companyList.html" NDATA parse>

Слово «parse» в объявлении сущности лист указывает на то, каким образом можно проанализировать файл «companyList.html» – найти нотацию с именем «parse» и следовать ее указаниям. В нашем случае, приложение может открыть MS InternetExplorer и загрузить в него документ «companyList.html».

XML (англ. eXtensible Markup Language — расширяемый язык разметки) — рекомендованный Консорциумом WWW язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.

Целью создания XML было обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче таких данных через Интернет. Словари, основанные на XML (например, RDF, RSS, MathML, XHTML, SVG), сами по себе формально описаны, что позволяет программно изменять и проверять документы на основе этих словарей, не зная их семантики, то есть не зная смыслового значения элементов.

Декларация XML-документа

XML-документ начинается с XML-декларации, которая определяет используемую версию XML:

<?xml version="1.0"?>

Если в документе используются символы выходящие за рамки ASCII, то необходимо указать кодировку документа:

<?xml version="1.0" encoding="UTF-8"?>

Элементы

XML документ состоит из элементов, которые описываются открывающим (<element>) и закрывающим (</element>) тегами. Текст между открывающим и закрывающим тегами называется содержимым элемента.

<element>Содержимое элемента</element>

Если элемент не имеет содержимого(empty element) и, соответственно, закрывающго тега, то он все равно должен быть закрыт:

<element/>

XML документ должен содержать хотя бы один элемент:

<?xml version="1.0" encoding="UTF-8"?>

При наличие более, чем одного элемента, должен существовать один и только один корневой элемент, который не может быть вложен в другие элементы:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <title>XML за 10 минут</title>
  <author>Вася Пупкин</author>
</root>

Имена тегов чувствительны к регистру, поэтому нижеследующее допустимо:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <title>XML за 10 минут</title>
  <Title>XML за 20 минут</Title>
  <TITLE>XML за 30 минут</TITLE>
</root>

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

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <book>
    <title>XML за 10 минут</title>
  </book>
</root>

Имена элементов могут начинаться только с буквы или символа подчеркивания. Далее, имя может содержать буквы, цифры, дефисы, символы подчеркивания, и точки. Также, может быть использовано двоеточие, но только в специальных случаях, когда оно разделяет пространство имен (namespace).
Имя элемента не может начинаться с последовательности символов «xml» (в любой комбинации регистров букв) — такое начало имени зарезервированo для нужд стандарта XML.

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <_title>XML за 10 минут</_title>
  <xmlTitle>ОШИБКА! Неправильное имя элемента</xmlTitle>
</root>

Атрибуты

Элемент может иметь один или несколько атрибутов. Правила для имен атрибутов такие же как и для имен элементов.
Атрибут состоит из имени и значения разделенных символом «=». Значение атрибута заключается в одинарные(апострофы) или двойные кавычки. Указываются атрибуты внутри открывающего тега и отделяются друг от друга пробелом. При наличие нескольких атрибутив порядок их следования не важен:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <book id="1" quantity="100">
    <title lang='ru'>XML за 10 минут</title>
    <author age="15">Василий Пупкин</author>
  </book>
</root>

Если одинарные или двойные кавычки присутствуют в значении атрибута, то значение надо заключать в те, которые не используются в данном значении:

<title alias='book "learn XML"'>XML за 10 минут</title>
<author address="pupkin's homepage">Василий Пупкин</author>

Спецсимволы

В содержимом элемента не могут использоваться символы «<» и «&», так как они используются в разметке. В случае необходимости, надо использовать специальные символы — «&lt;» вместо «<» и «&amp;» вместо «&»:

<result>2 &lt; 5</result>

Также могут быть заменены символы «>», «»», и «’» на, соответственно, «&gt;», «&quot;» и «&apos;»:

<result>2 &lt; 5</result>
<result>5 &gt; 3</result>
<text>Скажите: &quot;Hello, world!&quot;</text>

Комментарии

XML-документ может содержать комментарии. Комментарии начинаются с последовательности символов «<!––» и заканчиваются последовательностью символов «––>». Однако, внутри комментария не должно встречаться последовательности символов «––»:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<!–- Это правильный комментарий -–>
  <title>XML за 10 минут</title>
<!–- А это -- неправильный комментарий -–>
</root>

Секция CDATA

Если, все-таки, необходимо в содержании элемента использовать текст который не должен восприниматься как разметка(например, часть кода), то этот текст можно заключить в секцию CDATA. Секция CDATA начинается с последовательности символов «<![CDATA[» и заканчивается последовательностью символов «]]>». Внутри секции может присутствовать любой текст, кроме последовательности символов «]]>», которая указывает на окончание самой секции:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <code>
    <![CDATA[
      <div><h2><a href="#">John & Peter</a></h2></div>
    ]]>
  </code>
</root>

Другое

И, в заключение, XML-документ может включать инструкции по обработке для приложений:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <?web-server add-header="Powered by Pupkin"?>
  <title>XML за 10 минут</title>
</root>

Подробнее о XML можно прочитать на www.w3.org/XML.

Обычно этот список выглядит так:

Но меня всегда раздражало то, что в нем показываются все будущие дела и задачи, даже те, которые терпят еще неделю-другую. Но они всё равно в списке, и поэтому список может быть большим (например, у меня сегодня задачи распланированы до конца марта!). С точки зрения юзабилити, это классический пример «размытия внимания»: пользователь привыкает к большому количеству дел в списке и просто не обращает на них свое внимание.

К сожалению, просто поставить фильтр в представлении, ограничивающий вывод делами только, например, на неделю – месяц вперед не получается, так как такого правила в нём нет.

Но подобное правило можно написать руками, так как в Outlook есть возможность использовать псевдо-SQL для выборки данных из MAPI хранилищ. Это вполне развитый язык запросов с кучей функций. Я воспользовался функцией today(n), которая возвращает дату через n секунд после текущей.

Не буду пространно объяснять теорию, вот готовый рецепт настройки «Списка дел»:

1. Щелкните по пустому месту в списке дел правой кнопкой мышки и выберите «Настроить текущее представление»

2. Щелкните по кнопке [Отбор]

3. Переключитесь на закладку SQL и поставьте галочку «Изменять фильтр напрямую»

4. Введите следующий текст:

("http://schemas.microsoft.com/mapi/id/{00062003-0000-0000-C000-000000000046}/810f0040" IS NULL
  AND "http://schemas.microsoft.com/mapi/proptag/0x10910040" IS NULL
  AND ("http://schemas.microsoft.com/mapi/id/{00062003-0000-0000-C000-000000000046}/81040040" <= today(864000)
   OR "http://schemas.microsoft.com/mapi/id/{00062003-0000-0000-C000-000000000046}/81040040" IS NULL))

5. Нажимайте [OK] чтобы закрыть все окна

Все! Теперь с списке дел выводятся все незавершенные дела на 10 дней вперед.

А это подтверждение для technorati:
Technorati Profile