Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

23.04.2017

Google
WWW CITForum.ru
С Новым годом!
2005 г.

Стоит ли отменять пространства имен XML?

Пэрэнд Тони Дэйруджэр (Parand Tony Darugar)
Перевод: Intersoft Lab

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

Проблема

По словам автора, очень часто разработчики, использующие XML, не совсем понимают, что такое пространства имен, а если и понимают, то испытывают трудности в практической работе и при исправлении связанных с ними ошибок. Современные пространства имен XML требуют более двух недель для освоения всех нюансов. Примером проблем, связанных с пространствами имен, может быть следующий часто задаваемый вопрос (см. раздел Ресурсы):

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

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

Каковы преимущества пространства имен XML?

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

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

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

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

Далее автор обращается к еще одному распространенному вопросу о пространствах имен XML:

Какова цель создания пространств имен XML?

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

  • объединять фрагменты различных документов без возникновения конфликтов имен (см. пример ниже);
  • писать модули кодов, которые могут многократно использоваться и вызываться для определенных элементов и атрибутов. Уникальные имена гарантируют, что такие модули будут вызываться только для необходимых элементов и атрибутов;
  • определять элементы и атрибуты, которые могут использоваться в других схемах или реальных документах без опасности вызвать конфликт имен. Например, элементы XHTML могут использоваться в каталоге запчастей для их описания, а нулевые атрибуты, определенные в схемах XML, - для обозначения пропущенных значений.

Автор советует обратить внимание на следующий пример. Представленная проблема состоит в том, что элемент Address появляется в двух отдельных документах в двух различных контекстах и при этом имеет различные значения.

В таком случае возникает следующий вопрос:

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

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

Объединенный документ выглядит следующим образом.

Листинг 1. Объединенный документ с пространствами имен

<Department>
     <Name>DVS1</Name>
     <addr:Address xmlns:addr="http://www.tu-darmstadt.de/ito/addresses">
        <addr:Street>Wilhelminenstr. 7</addr:Street>
        <addr:City>Darmstadt</addr:City>
        <addr:State>Hessen</addr:State>
        <addr:Country>Germany</addr:Country>
        <addr:PostalCode>D-64285</addr:PostalCode>
     </addr:Address>
     <serv:Server xmlns:serv="http://www.tu-darmstadt.de/ito/servers">
        <serv:Name>OurWebServer</serv:Name>
        <serv:Address>123.45.67.8</serv:Address>
     </serv:Server>
  </Department>

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

Листинг 2. Объединенный документ без пространств имен

<Department>
     <Name>DVS1</Name>
     <Address>
        <Street>Wilhelminenstr. 7</Street>
        <City>Darmstadt</City>
        <State>Hessen</State>
        <Country>Germany</Country>
        <PostalCode>D-64285</PostalCode>
     </Address>
     <Server>
        <Name>OurWebServer</Name>
        <Address>123.45.67.8</Address>
     </Server>
  </Department>

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

Элементы в контексте

К сожалению, спецификация пространства имен XML игнорирует один из основных принципов XML: документы XML являются иерархическими; ни один тэг не является изолированным.

При выборе того или иного элемента Address пользователь может указать конкретно, какой именно элемент ему нужен: адрес сервера, который находится внутри тэгов Server, или адрес отдела, обозначенный тэгами Department. В формате XML это будут выглядеть следующим образом: /Department/Server/Address или /Department/Address, соответственно. Такой формат не несет никакой двусмысленности; совершенно очевидно, какой элемент имеется в виду в том или другом случае. Это происходит потому, что тэг XML определяется контекстом, а не только именем.

Двусмысленность появляется только при игнорировании контекста.

Игнорировать структуру и иерархию при работе с XML - это фундаментальная ошибка.

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

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

На самом деле решением проблемы является рассмотрение элементов в их иерархическом контексте. Стандартный язык XML это обеспечивает, и никакой необходимости в пространствах имен не возникает.

Более интересные примеры

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

Первый вариант - использование пространств имен как метода идентификации типов документов или управления их версиями. Достаточно распространенными являются следующие конструкции:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

Это пример самого верхнего тэга сообщения SOAP 1.2. Здесь пространство имен выполняет важную задачу. Оно информирует потребителя, что данный элемент XML является конвертом SOAP, связан с международным консорциумом W3C (World Wide Web Consortium) и соответствует версии спецификации, принятой в мае 2003 г. Это, безусловно, более информативно, чем альтернативный тэг без пространства имени: <Envelope>.

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

<Envelope documentIdentifier="http://www.w3.org/2003/05/soap-envelope"> 

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

<element name="cost" type="xsd:float"/> 

или

<element name="greeting" type="SOAP-ENC:string"/> 

Здесь xsd и SOAP-ENC - идентификаторы пространства имен, которые относятся к типам схемы XML (XSD) и кодировки SOAP, соответственно. Таким образом, cost является элементом типа float, определяемого в соответствии с XSD, а greeting - элементом типа string, определяемого в соответствии со спецификацией кодировки SOAP. Вот еще похожий пример:

<cost xsi:type="xsd:float">29.95</cost> 

Эта запись обозначает, что элемент cost имеет определенный тип, определяемый XSI, а также то, что float является типом, определяемым XSD. Ключевым моментом является то, что каждому типу действительно требуются исключительные идентификаторы, не привязанные к контексту. Здесь не происходит объединения одного документа с другим, имеющим кодировку XSD или SOAP. Просто определенные элементы в каждой из спецификаций, используемых в документе, имеют собственные обозначения. Спецификация даже не обязательно должна быть написана на XML, поскольку речь идет о плоской структуре, просто списке типов. Если структура типа является иерархической, тогда нужно полностью указать путь к нему:

<cost xsi:type="xsd:/types/simple/float">29.95</cost> 

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

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

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

"Осуждение" пространств имен XML

Автор считает, что приведенные им аргументы достаточно убедительно свидетельствуют о проблемах с пространствами имен XML и о их ограниченной применимости.

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

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

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

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

Ресурсы

Об авторе

Большая часть карьеры Пэрэнда Тони Дэйругэра (Parand Tony Darugar) была посвящена созданию высокопроизводительных распределенных систем, а также разработке их архитектуры. Он имеет опыт руководства нескольким проектами одновременно, а также работал в крупном интернет-бизнесе. Его интересы включают web-сервисы и сервис-ориентированную архитектуру (Service Oriented Architectures, сокр. SOA), XML, распределенную архитектуру и искусственный интеллект. Его статьи доступны на сайте Standard Deviations. Связаться с автором статьи можно по адресу tdarugar@yahoo.com.

Оригинальный текст статьи можно посмотреть здесь: Abolish XML namespaces?

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...