О документе
Рабочая группа по сетям S. Hollenbeck
Запрос комментариев: 3470 VeriSign, Inc.
BCP: 70 M. Rose
Категория: Лучшая современная практика Dover Beach Consulting, Inc.
L. Masinter
Adobe Systems Incorporated
Январь 2003
Рекомендации по использованию Extensible Markup Language (XML)
в протоколах IETF
1. Введение и обзор
Extensible Markup Language (XML, [8]) — это основа для структурирования
данных. Хотя XML произошёл от Standard Generalized Markup Language
(SGML, [30]) — языка разметки, в первую очередь ориентированного на
структурирование документов, — XML стал широко используемым механизмом
представления структурированных данных при обмене по протоколам. Введение
в XML см. в «XML in 10 points» [47].
1.1 Предполагаемая аудитория
Многие разработчики интернет-протоколов рассматривают использование XML
и XML-фрагментов в контексте существующих и новых интернет-протоколов.
Этот документ предназначен как руководство по использованию XML и как
политика IETF для документов на пути стандартизации. Опытные специалисты
по XML, вероятно, уже знакомы с приведёнными здесь базовыми материалами,
однако рекомендации также предназначены для таких читателей.
1.2 Область применения
Этот документ предназначен для предоставления рекомендаций по
использованию содержимого XML в составе более крупного протокола. Цель
состоит не в том, чтобы утверждать, что XML является «лучшим» или
«предпочтительным» способом представления данных; напротив, цель состоит
в изложении контекста использования XML в протоколе, когда другие факторы
указывают на XML как на возможное решение для представления данных.
Common Name Resolution Protocol (CNRP, [24]) является примером протокола,
к которому применялись бы эти рекомендации, если бы он определялся вновь.
Этот документ не рассматривает использование таких протоколов, как SMTP
или HTTP, для отправки XML-документов в качестве обычного содержимого
электронной почты или веб-содержимого.
Уже используется или разрабатывается ряд протокольных каркасов, полностью
сосредоточенных на «протоколе XML» — исключительном использовании XML как
представления данных в протоколе. Например, World Wide Web Consortium
(W3C) разрабатывает каркас XML Protocol, основанный на SOAP ([45] и [46]).
Применимость таких протоколов не входит в область применения данного
документа.
Кроме того, существуют основанные на XML каркасы представления более
высокого уровня, разработанные как носители определённых классов
информации; например, Resource Description Framework (RDF, [38]) — это
основанное на XML представление логических утверждений. Этот документ не
предоставляет рекомендаций по использованию таких каркасов.
1.3 Эволюция XML
XML 1.0 первоначально был опубликован как рекомендация W3C в феврале
1998 года [35], а в октябре 2000 года был пересмотрен во 2-м издании [8].
Также был определён ряд дополнительных средств, надстраиваемых над базовой
спецификацией. Хотя эти дополнения спроектированы совместимыми с XML 1.0,
они обладают различными уровнями стабильности, консенсуса и реализации.
Соответственно, этот документ определяет основные эволюционные возможности
XML и предлагает обстоятельства, в которых следует использовать каждую из
них.
1.4 Пользователи XML, группы поддержки и дополнительная информация
Существует много групп поддержки XML: некоторые посвящены всей индустрии
XML [51], некоторые — разработчикам [52], некоторые — деловым применениям
XML [53], а также имеется множество, множество групп, посвящённых
использованию XML в конкретном контексте.
Предоставление исчерпывающего списка ссылок выходит за рамки данного
документа. Заинтересованным читателям в качестве отправных точек
предлагаются три приведённые выше ссылки, а также их предпочитаемая
интернет-поисковая система.
2. Факторы выбора XML
XML — это инструмент, предоставляющий средство для достижения цели. Выбор
правильного инструмента для данной задачи является существенной частью
обеспечения возможности удовлетворительного выполнения задачи. В этом
разделе описываются факторы, о которых следует знать при рассмотрении XML
как инструмента для применения в протоколах IETF:
1. XML является метаязыком разметки, который можно использовать для
определения языков разметки для конкретных предметных областей и
пространств задач.
2. XML предоставляет как логическую, так и физическую структуру для
описания данных. Кадрирование данных встроено.
3. Экземпляры XML могут быть проверены на соответствие формальному
определению спецификации протокола.
4. XML поддерживает интернационализацию.
5. XML расширяем. В отличие от некоторых других языков разметки (таких
как HTML), новые теги (и, следовательно, новые элементы протокола)
могут определяться без внесения изменений в сам XML.
6. XML всё ещё развивается. Формальные спецификации продолжают
формироваться и обновляться по мере накопления и применения опыта
использования.
7. XML не предоставляет встроенных механизмов для поддержки подробной
типизации данных. Для задания абстрактных типов данных протокола
требуются дополнительные механизмы (такие как описанные в разделе 4.7).
8. XML основан на тексте, поэтому XML-фрагменты легко создавать,
редактировать и сопровождать с использованием распространённых
утилит. Кроме того, текстовая основа означает, что XML проще
поддерживает инкрементальную разработку,
отладку и журналирование. Простой «заготовленный» XML-фрагмент можно
встроить в программу как строковую константу, вместо того чтобы
конструировать его.
9. Чтобы представить двоичные данные в XML, их необходимо закодировать в
текстовую форму.
10. XML многословен по сравнению со многими другими языками представления
структурированных данных. Представление с расширяемостью элементов и
читаемостью для человека обычно требует больше битов по сравнению с
представлением, оптимизированным для эффективной машинной обработки.
11. Реализации XML всё ещё относительно новы. По мере того как разработчики
и реализаторы получают опыт, нередко обнаруживаются дефекты в ранних и
текущих продуктах.
12. Поддержка XML доступна во множестве средств разработки программного
обеспечения, представленных как продуктами с открытым исходным кодом,
так и проприетарными продуктами.
13. Скорость обработки XML в некоторых средах может быть проблемой.
Обработка XML может быть медленнее, поскольку потоки данных XML могут
быть больше других представлений, а использование XML-анализаторов
общего назначения добавляет программный слой с собственными затратами
производительности (хотя эти затраты можно сократить последовательным
применением оптимизированного анализатора). В некоторых ситуациях
обработка XML требует проверки каждого байта всего потока данных XML,
с большими накладными расходами, чем у представлений, в которых
неинтересующие сегменты можно пропускать.
3. Альтернативы XML
Этот документ сосредоточен на рекомендациях по использованию XML. Полезно
рассмотреть, почему можно использовать XML, а не какой-либо другой
механизм. В данном разделе рассматриваются некоторые другие широко
используемые механизмы представления и сопоставляется XML с этими
альтернативами.
Для многих фундаментальных протоколов требования к расширяемости умеренны,
а требования к производительности достаточно высоки, чтобы подходящим
представлением были блоки двоичных данных фиксированного формата; такие
механизмы, как XML, лишь добавляют раздувание. RFC 3252 [23] описывает
шуточный пример XML как раздувания протокола.
Кроме того, в коммуникационных протоколах успешно использовались другие
каркасы представления и расширяемости. Например, Abstract Syntax Notation 1
(ASN.1) [28] вместе с соответствующими Basic Encoding Rules (BER, [29])
являются частью набора коммуникационных протоколов OSI и использовались во
многих последующих стандартах связи (например, в протоколе ANSI Information
Retrieval [27] и Simple Network Management Protocol (SNMP, [13]). External
Data Representation (XDR, [14]) и его варианты использовались во многих
других распределённых сетевых приложениях (например, в протоколе Network
File System (NFS) [22]). При некоторых типах кодирования ASN.1 типы данных
явным образом присутствуют в представлении, тогда как в XDR типы данных
компонентов описываются внешним образом как часть спецификации интерфейса.
Многие другие протоколы используют структуры данных непосредственно (без
инкапсуляции данных), описывая структуру данных с помощью Backus Normal Form
(BNF, [25]); многие протоколы IETF используют Augmented Backus-Naur Form
(ABNF, [16]). Simple Mail Transfer Protocol (SMTP, [21]) является примером
протокола, специфицированного с использованием ABNF.
ASN.1, XDR и BNF описаны здесь как примеры альтернатив XML для использования в протоколах IETF. Существуют и другие альтернативы, однако полное перечисление всех возможных альтернатив выходит за рамки настоящего документа.
Другие методы представления могут отличаться от XML несколькими важными свойствами:
Кодирование текста и наборы символов: кодировка символов, используемая для представления формальной спецификации. XML определяет согласованную модель символов, основанную на Universal Character Set (UCS, [31] и [33]), и требует, чтобы XML-парсеры принимали как минимум UTF-8 [4] и UTF-16 [20], а также допускает другие кодировки. Хотя ASN.1 и XDR могут передавать строки в любой кодировке, в них нет общего механизма для определения кодировок символов. Как правило, определения ABNF формулируются в терминах октетов или символов ASCII.
Кодирование данных: XML определяется как последовательность символов, а не как последовательность байтов. XML Schema [42] включает механизмы представления некоторых типов данных (целое число, дата, массив и т. д.), но многие двоичные типы данных кодируются в Base64 [15] или в шестнадцатеричном виде. ASN.1 и XDR имеют развитые механизмы кодирования широкого разнообразия типов данных.
Расширяемость: XML имеет развитую модель расширяемости, благодаря которой спецификации XML часто могут версионироваться независимо. Спецификации могут расширяться добавлением новых имён элементов и атрибутов (если это сделано совместимым образом); другие расширения могут добавляться определением новых пространств имён XML [9], хотя в XML нет стандартного механизма для указания того, обязательно ли распознавать новые расширения. Аналогично, для расширения спецификаций ASN.1 доступны несколько методов. Спецификации XDR, как правило, не могут независимо расширяться разными сторонами, поскольку кадрирование и типы данных являются неявными и не самоописываются.
Расширяемость элементов протокола, основанных на BNF, должна быть явно спланирована.
Читаемость элементов протокола: как отмечено выше, XML основан на тексте и поэтому обладает преимуществами (и недостатками) текстовых элементов протокола. Обычно это свойство разделяют элементы протокола, определённые посредством (A)BNF. ASN.1 и XDR используют двоичные кодировки, которые человеку нелегко читать.
4. Соображения и рекомендации по использованию XML
В этом разделе отмечаются несколько аспектов XML и даются рекомендации по его использованию. После публикации XML версии 1 [35] в 1998 году в 2000 году было опубликовано редакционное второе издание [8]; в этом разделе имеется в виду второе издание.
4.1 Синтаксис XML и корректная сформированность
XML [8] определяется через конкретный синтаксис: последовательность символов, использующую символы «<», «=», «&» и т. д. в качестве разделителей. Экземпляр является XML тогда и только тогда, когда он корректно сформирован, то есть все символьные данные и данные разметки соответствуют структурным правилам, определённым в разделе 2.1 документа [8].
Символьные данные и данные разметки, которые не являются корректно сформированными, не являются XML; корректная сформированность — основа синтаксической совместимости с XML. Без корректной сформированности все преимущества использования XML исчезают. Поэтому рекомендуется, чтобы спецификации протоколов явно требовали корректной сформированности XML («ДОЛЖЕН (MUST) быть корректно сформирован»).
IETF имеет давнюю традицию «быть либеральным в том, что принимаешь», которая может показаться противоречащей этой рекомендации. Поскольку XML требует корректной сформированности, соответствующие XML-парсеры нетерпимы к ошибкам корректной сформированности. При определении обработки ошибочных XML-элементов протокола проектирование протокола никогда не должно рекомендовать попытку частично интерпретировать некорректно сформированные экземпляры элемента, который должен быть XML. Разумное поведение в таком сценарии может включать попытку повторной передачи или прерывание сеанса, находящегося в процессе выполнения.
4.2 Информационный набор XML
Помимо конкретного синтаксиса XML существует абстрактная модель содержимого XML, известная как «Information Set» (infoset) [37]. XML-парсер можно представлять как средство, которое потребляет конкретный синтаксис и создаёт XML Information Set для дальнейшей обработки.
При типичном использовании XML определение допустимых XML-документов часто формулируется в терминах Information Set XML, а не конкретного синтаксиса. Идея состоит в том, что любое синтаксическое представление, порождающее тот же информационный набор, рассматривалось бы как эквивалентное.
В некоторых случаях протоколы определялись исключительно в терминах XML Information Set либо с допущением представлений в другом конкретном синтаксисе. Однако, поскольку контекст XML, встроенного в другие интернет-протоколы, требует однозначного определения конкретного синтаксиса, определение элемента XML-протокола только в терминах его XML Information Set и допущение представлений в другом конкретном синтаксисе выходят за рамки настоящего документа.
4.3 Синтаксические ограничения
В некоторых обстоятельствах разработчик протокола может испытать соблазн определить элемент протокола на основе XML как «XML», но одновременно наложить дополнительные ограничения сверх налагаемых самой рекомендацией XML — например, ограничить кодировку символов документа, избегать разделов CDATA, ссылок на символьные сущности, налагать дополнительные ограничения на использование пробельных символов и т. д. Общая категория ограничений, рассматриваемых в этом разделе, — это такие ограничения, которые допускали бы одни, но не другие синтаксические представления из множества представлений, имеющих одно и то же каноническое представление согласно каноническому XML, описанному в RFC 3076 [6].
Введение таких ограничений в определение протокола может иметь тот недостаток, что реализатор протокола не сможет использовать в остальном соответствующий XML-процессор для разбора элементов протокола на основе XML. В некоторых случаях мотивом выделения подмножества XML является возможность для реализаторов создавать специализированные процессоры с меньшими требованиями к ресурсам, чем полнофункциональный соответствующий XML-процессор. Существует ряд хороших, соответствующих XML-парсеров, которые малы, быстры и бесплатны, тогда как специализированные процессоры часто оказывались неспособными обработать некоторые случаи допустимого синтаксиса XML.
В целом таких синтаксических ограничений следует избегать. В обстоятельствах, когда ограничения изменчивости синтаксического представления XML необходимы по той или иной причине, разработчикам следует рассмотреть использование «Canonical XML» [6] в качестве определения элемента протокола, поскольку вся такая изменчивость в нём устранена. Некоторые конкретные вопросы обсуждаются ниже, в разделе 4.4, разделе 4.13 и разделе 5.1.
4.4 Объявления XML
Объявление XML (определённое в разделе 2.8 документа [8]) — это небольшой заголовок в начале потока данных XML, указывающий версию XML и используемую кодировку символов. Например,
<?xml version="1.0" encoding="UTF-8"?>
задаёт использование XML версии 1 и кодировки символов UTF-8.
При некоторых вариантах использования XML в качестве встроенного элемента протокола используемый XML представляет собой небольшой фрагмент в более широком контексте, где версия XML зафиксирована как «1.0», а кодировка символов заведомо является «UTF-8». В таких случаях объявление XML может создавать дополнительные накладные расходы. В случаях, когда XML является более крупным компонентом, который может самостоятельно оказаться телом внешней сущности (например, передаваемым как MIME-сообщение), объявление XML является важным маркером и полезно для надёжности и расширяемости. Объявление XML также является важным маркером набора символов/кодировки (см. раздел 5.1), если используется любая кодировка, отличная от UTF-8 или UTF-16. Следует отметить, что в случае UTF-16 XML требует, чтобы сущность начиналась с Byte Order Mark (BOM), не являющегося частью символьных данных. Следует отметить, что само XML Declaration не является частью Information Set XML-документа.
Спецификации протоколов должны ясно определять использование объявлений XML. В XML [8] отмечено, что «XML-документы следует начинать с объявления XML, указывающего используемую версию XML». В целом объявление XML следует поощрять («СЛЕДУЕТ (SHOULD) присутствовать») и всегда допускать («МОЖЕТ (MAY) быть отправлено»). Объявление XML следует требовать в случаях, когда при его допустимости кодировка символов является любой кодировкой, отличной от UTF-8 или UTF-16.
4.5 Инструкции обработки XML
Инструкция обработки XML (определённая в разделе 2.6 документа [8]) — это компонент XML-документа, передающий получателю дополнительную информацию «вне полосы»; распространённое применение инструкций обработки XML — приложения для работы с документами. Например, приложение XML2RFC, использованное для создания настоящего документа и описанное в RFC 2629 [19], поддерживает инструкцию обработки «table of contents»:
<?rfc toc="yes"?>
Как описано в разделе 2.6 документа [8], инструкции обработки не являются частью символьных данных документа, но должны передаваться приложению. Как следствие, рекомендуется игнорировать инструкции обработки при их обнаружении в обычной обработке протокола. Поэтому также рекомендуется не использовать инструкции обработки для определения нормативных структур данных протокола или расширений по следующим причинам:
o Инструкции обработки не учитывают пространства имён; отсутствует способ квалифицировать цель инструкции обработки пространством имён.
o Использование инструкций обработки не может быть ограничено большинством языков схем,
o Ссылки на символы не распознаются внутри инструкции обработки.
o Инструкции обработки не имеют определённой XML структуры, кроме разделения между целью и всем остальным. Это означает, что приложения обычно вынуждены разбирать содержимое инструкции обработки способом, зависящим от системы; если бы содержимое было предоставлено внутри элемента, структура могла бы быть выражена в XML, а разбор мог бы выполняться XML-парсером.
4.6 Комментарии XML
Комментарий XML (определённый в разделе 2.5 документа [8]) — это компонент XML-документа, предоставляющий описательную информацию, которая не является частью символьных данных документа. Комментарии XML, подобно комментариям, используемым в языках программирования, часто применяются для предоставления поясняющей информации в понятных человеку терминах. Пример:
<!-- This is a example comment. -->
Комментарии XML могут игнорироваться соответствующими процессорами. Как следствие, настоятельно рекомендуется не использовать комментарии для определения нормативных структур данных протокола или расширений. Поэтому также настоятельно рекомендуется игнорировать комментарии при их обнаружении в обычной обработке протокола.
4.7 Валидность и расширяемость
Одно из важных достоинств XML состоит в наличии формальных механизмов определения ограничений структуры и содержимого данных; они ограничивают идентичность элементов или атрибутов либо значения, содержащиеся в них. Существует более одного такого формализма:
o «Document Type Definition» (DTD) определено в разделе 2.8 документа [8]; эта концепция возникла из аналогичного механизма для SGML. Накоплен значительный опыт использования DTD, в том числе в протоколах IETF.
o XML Schema (определённая в [41] и [42]) предоставляет дополнительные возможности, позволяющие точнее и строже специфицировать допустимый синтаксис протокола и спецификации типов данных.
o Существует также ряд других механизмов описания валидности экземпляра XML; к ним относятся, например, Schematron [49] и RELAX NG [48]. Часть 2 стандарта ISO/IEC Document Schema Definition Language (DSDL, [32]) основана на RELAX NG.
В сообществе XML продолжается обсуждение (и полемика) использования и применимости различных механизмов ограничений валидности. Выбор инструмента зависит от потребностей в расширяемости либо в формальном языке и механизме ограничения допустимых значений и проверки соблюдения ограничений.
Известны случаи, когда протоколы определяли валидность с помощью того или иного механизма валидности, но определения протокола не настаивали на том, чтобы все соответствующие элементы протокола были «валидными». Решение отчасти зависит от проектирования расширяемости протокола. Каждый формализм располагает различными способами допущения будущих расширений; кроме того, проектирование протокола может предусматривать собственный механизм версионирования, способ обновления схемы или указания на новую схему. Например, использование пространств имён XML (раздел 4.9) совместно с XML Schema допускает другие виды расширяемости без нарушения валидности схемы.
Независимо от выбранного формализма обычно существуют дополнительные синтаксические ограничения и неизбежно дополнительные семантические ограничения валидности XML-элементов, которые не могут быть выражены в формализме.
Настоящий документ даёт следующие рекомендации для определения протоколов, использующих XML:
o Протоколам следует использовать подходящий формализм для определения валидности XML-элементов протокола.
o Протоколы могут как требовать, так и не требовать, чтобы все соответствующие элементы протокола были действительными в соответствии с выбранным механизмом действительности; в любом случае проект расширяемости должен быть ясным. Что происходит, если данные недействительны?
o Как описано в разделе 3, в XML нет стандартного механизма для указания того, обязательно ли распознавать новые расширения. Поэтому спецификациям протоколов на основе XML следует явно описывать механизмы расширения, а также требования к распознаванию или игнорированию расширений.
Идеализированная модель обработки XML могла бы сначала проверять правильность формирования; если всё в порядке, применять основной формализм и, если экземпляр «проходит» проверку, применять остальные ограничения, чтобы одновременно можно было проверить весь набор (или настолько большую его часть, насколько допускает машинная обработка).
Однако разумно разрешить соответствующим реализациям избегать выполнения валидации во время выполнения и вместо этого полагаться на специализированный код, чтобы избежать более высоких затрат, например затрат на валидацию схемы, особенно с учётом того, что, вероятно, потребуется дополнительная вручную созданная семантическая валидация.
4.8 Семантика наряду с синтаксисом
Хотя определение элемента протокола XML с использованием формализма действительности полезно, его недостаточно. XML сам по себе не предоставляет семантику. Любой документ, определяющий элемент протокола с помощью XML, ДОЛЖЕН (MUST) также содержать достаточное текстовое описание семантики того XML, который документ решил определить.
4.9 Пространства имён
Пространства имён XML, определённые в [9], предоставляют средство назначения разметки конкретному словарю. Если два элемента или атрибута из разных словарей имеют одно и то же имя, их можно однозначно различить, если они принадлежат разным пространствам имён. Кроме того, пространства имён существенно поддерживают расширяемость протоколов, поскольку их можно определять, повторно использовать и обрабатывать динамически.
Коллизии словарей разметки вполне возможны, когда пространства имён не используются для разделения и однозначной идентификации словарей. В определениях протоколов следует использовать существующие пространства имён XML там, где это уместно. Когда требуется новое пространство имён, «имя пространства имён» представляет собой URI, используемый для идентификации пространства имён; также полезно, чтобы этот URI указывал на описание пространства имён. Обычно (и в качестве практики, рекомендуемой W3C) имена пространств имён назначают с использованием постоянных http URI.
В случае пространств имён в документах IETF уровня стандартов было бы полезно иметь некоторую постоянную часть собственного веб-пространства IETF, которую можно было бы использовать для этой цели. При отсутствии такой части можно использовать другие постоянные URI, например URN в пространстве имён IETF URN (см. [11] и [12]). Хотя существуют примеры спецификаций IETF, создающих новые схемы URI для определения пространств имён XML, такая практика настоятельно не рекомендуется.
4.9.1 Пространства имён и атрибуты
Часто неверно понимается один аспект связи между атрибутами без префикса и пространством имён XML по умолчанию: естественно предположить, что атрибут без префикса квалифицируется пространством имён по умолчанию, но это неверно. Напротив, атрибут без префикса вообще не принадлежит никакому пространству имён. Таким образом, в следующем примере:
<ns1:fox a="xxx" ns1:b="qqq"
xmlns="http://example.org"/>
<fox a="xxx" ns1:b="qqq"
xmlns="http://example.org" xmlns:ns1="http://example.org"/>
атрибут «a» не находится ни в каком пространстве имён, тогда как «ns1:b» находится в том же пространстве имён, что и содержащий его элемент. Конкретное описание связи между пространствами имён по умолчанию и атрибутами приведено в разделе 5.2 [9]. Практическое следствие связи между пространствами имён и атрибутами состоит в том, что необходимо позаботиться о том, чтобы ни один элемент не содержал нескольких атрибутов с идентичными именами либо с квалифицированными именами, имеющими одинаковую локальную часть и префиксы, связанные с идентичными именами пространств имён.
В приложениях XML выбор между атрибутами с префиксом и без префикса часто основывается на том, всегда ли они появляются внутри элементов одного и того же пространства имён (в этом случае используются имена без префикса и, следовательно, без пространства имён) либо требуется ли, чтобы они могли применяться к элементам в других произвольных пространствах имён (в этом случае используется имя с префиксом). Обе ситуации встречаются в языке XSLT [43]: хотя атрибуты не имеют префикса, когда они появляются внутри элементов в пространстве имён XSLT, например:
<xsl:value-of select="."/>
они имеют префикс, когда появляются в элементах, не относящихся к XSLT, например атрибут «xsl:version» при использовании «literal result element stylesheets»:
<html xsl:version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/xhtml1/strict">
<head>
<title>Expense Report Summary</title>
</head>
<body>
<p>Total: <xsl:value-of select="exp-rep/total"/></p>
</body>
</html>
4.10 Соображения по проектированию элементов и атрибутов
XML предоставляет большую гибкость, позволяя разработчику использовать для передачи данных элементы, атрибуты или содержимое элементов. Этот раздел даёт представление о соображениях проектирования; в литературе по XML об этом написано много. Последовательное использование элементов, атрибутов и значений является важной характеристикой качественного проекта.
Атрибуты в целом предназначены для содержания метаданных, описывающих элемент, и поэтому подчиняются следующим ограничениям:
o Атрибуты не упорядочены,
o В данном элементе может быть не более одного экземпляра заданного атрибута, хотя атрибут может содержать несколько значений, разделённых пробельными символами ([8], разделы 2.3 и 3.3.1),
o Значения атрибутов не могут содержать внутреннюю разметку XML для предоставления внутренней структуры, и
o Значения атрибутов нормализуются ([8], раздел 3.3) перед обработкой.
Рассмотрим следующий пример, описывающий IP-адрес с использованием атрибута для описания значения адреса:
<address addrType="ipv4">10.1.2.3</address>
Ту же информацию можно было бы закодировать, используя элемент <addrType> вместо атрибута «addrType»:
<address>
<addrType>ipv4</addrType>
<value>10.1.2.3</value>
</address>
Другой способ кодирования той же информации состоял бы в использовании разметки для «addrType»:
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
Выбор между этими проектами предполагает компромиссы, касающиеся, помимо прочего, вероятных моделей расширяемости и способности формализма надлежащим образом ограничивать значения. В первом примере атрибут можно рассматривать как метаданные элемента, который он изменяет, и как обеспечивающий своего рода «расширяемость элемента». Третий пример допускает другой вид расширяемости: пространство «ipv4» можно расширить, используя другие пространства имён, а элемент <ipv4> может включать дополнительную разметку.
Многие протоколы включают параметры, выбираемые из перечисляемого набора значений. Такие перечисляемые значения можно кодировать как элементы, атрибуты или строки внутри значений элементов. При любом проектировании протокола следует учитывать, как будет расширяться набор перечисляемых значений: пересмотром протокола, включением разных значений в разные пространства имён XML или учреждением реестра IANA (согласно RFC 2434 [18]). Кроме того, обычной практикой в XML является использование URI в качестве значения атрибута XML или содержимого.
Языки, описывающие синтаксическую действительность (включая XML Schema и DTD), часто предоставляют механизм задания «значений по умолчанию» для атрибута. Если элемент не задаёт значение атрибута, используется значение «по умолчанию». Этот документ не рекомендует использовать значения по умолчанию для атрибутов. Хотя использование этой возможности может уменьшить как размер, так и загромождённость документов XML, оно отрицательно влияет на программное обеспечение, которое не знает ограничений действительности документа (например, на трассировку пакетов или цифровую подпись).
4.11 Двоичные данные и текст с управляющими символами
XML определён как поток символов, а не поток октетов. Не существует способа встроить необработанные двоичные данные непосредственно в поток данных XML; все двоичные данные должны кодироваться как символы. Возможен ряд кодировок; например, XML Schema [42] определяет кодировки с использованием десятичных цифр для целых чисел, Base64 [15] или шестнадцатеричных цифр. Кроме того, двоичные данные могут передаваться через некоторый другой канал связи, а ссылка на них может приводиться в самих данных XML с помощью URI.
Протоколам, которым необходим контейнер, способный содержать как структурные данные, так и большие объёмы двоичных данных, следует тщательно рассмотреть, подходит ли XML, поскольку кодировки Base64 и hex неэффективны. В противном случае протоколам следует использовать механизмы XML Schema для представления двоичных данных; кодировка Base64 лучше всего подходит для больших объёмов данных.
XML не допускает «управляющие» символы (0x00-0x1F), кроме TAB (0x09), CR (0x0A) и LF (0x0D). Их нельзя задавать даже с использованием ссылок на символьные сущности. В настоящее время нет общепринятого способа кодировать их в том, что в остальном является обычным текстом. Это означает, что строки, которые могли бы считаться «текстом» внутри элемента протокола, определённого ABNF, возможно, потребуется обрабатывать как двоичные данные в представлении XML либо, возможно, потребуется изобрести какой-либо иной механизм кодирования.
4.12 Инкрементальная обработка
В некоторых ситуациях возможно инкрементально обрабатывать документ XML по мере получения каждого тега; это аналогично процессу, при котором браузеры инкрементально отображают страницы HTML по мере их получения. Обратите внимание, что инкрементальную обработку трудно реализовать, если она чередуется между несколькими взаимодействиями. Иными словами, если протокол требует инкрементальной обработки в обоих направлениях двунаправленного потока, это может возложить необычную нагрузку на реализаторов протокола.
4.13 Объявления сущностей и ссылки на сущности
Помимо своей роли механизма действительности, XML DTD предоставляет средство для «объявлений сущностей» ([8], раздел 4.2). Объявление сущности определяет в DTD своего рода возможность макроса, при которой «ссылка на сущность» может использоваться для вызова и включения содержимого объявления сущности.
Эта возможность добавляет сложность обработке XML и, по-видимому, более уместна для использования XML при обработке документов, чем при представлении данных. Поэтому этот документ рекомендует избегать объявлений сущностей в спецификациях протоколов.
С другой стороны, в XML встроены пять стандартных ссылок на сущности: "&", "<", ">", "'" и """. XML также позволяет записывать символьные данные с использованием числовых ссылок на сущности (используя значение Unicode [33] для символа). Ссылки на сущности обычно раскрываются до вычисления XML Information Set. Ограничение использования этих ссылок на сущности без необходимости ввело бы дополнительное синтаксическое ограничение (см. раздел 4.3); эти ссылки на сущности следует разрешать.
4.14 Внешние ссылки
При использовании XML в контексте протокола без состояния — будь то сам протокол (например, SOAP) либо просто содержимое, передаваемое существующим протоколом (например, XML/HTTP), — необходимо позаботиться о том, чтобы смысл сообщения не зависел от информации вне самого сообщения. XML предоставляет внешние сущности (см. раздел 4.13), которые являются простым способом сделать смысл сообщения зависимым от чего-либо внешнего. Использование языков схем, способных изменять Infoset, таких как XML Schema, является другим способом.
4.15 Обработка URI
Спецификация XML Base [36] определяет в пространстве имён XML атрибут «xml:base», предназначенный для влияния на «базу», используемую при обработке относительных URI, описанной в RFC 2396 [17]. Возможности xml:base по управлению обработкой URI могут быть полезны разработчикам протоколов, но если xml:base разрешён, необходимо ясно определить взаимодействие с любыми другими средствами протокола для установления контекста URI. Обратите внимание, что W3C объявил использование относительных URI в объявлениях пространств имён устаревшим; некоторые конкретные вопросы, связанные с относительными URI в объявлениях пространств имён и каноническим XML, приведены в разделе 1.3 RFC 3076 [6].
Следует также отметить, что во многих случаях термин «URI» и синтаксическое использование URI в XML допускают не-ASCII-символы в URI. Например, тип данных XML Schema «anyURI» ([42], раздел 3.2.17) допускает непосредственное кодирование символов вне диапазона US-ASCII. Большинство современных протоколов и спецификаций IETF не допускают этот синтаксис. Спецификациям протоколов следует чётко указывать диапазон задаваемых символов, например добавляя ограничение на диапазон символов, разрешённых в типе данных схемы anyURI, либо указывая, что символы вне диапазона US-ASCII следует экранировать при передаче в старые протоколы или API.
4.16 Пробельные символы
Предписанное XML поведение при обработке пробельных символов может быть источником недопонимания между разработчиками протоколов и реализаторами. В XML-экземплярах все пробельные символы считаются значимыми и по умолчанию видимы приложениям обработки. Рассмотрим этот пример из раздела 4.10:
<address>
<addrType><ipv4/></addrType>
<value>10.1.2.3</value>
</address>
Этот фрагмент содержит элемент <address> и два дочерних элемента. Он также содержит пробельные символы для целей красивого форматирования:
o по меньшей мере три разделителя строк, которые XML-процессор преобразует в символы новой строки (U+000A) (см. раздел 2.11 документа [8]), и
o один или более пробельных символов перед элементами <addrType> и <value>, которые XML-процессор сделает видимыми программному обеспечению, читающему экземпляр.
Реализаторы могут безопасно предположить, что могут игнорировать пробельные символы в приведённом выше примере, но пробельные символы, используемые для красивого форматирования, могут быть источником недопонимания в других ситуациях. Рассмотрим небольшое изменение элемента <value>:
<value>
10.1.2.3
</value>
где пробельные символы находятся с обеих сторон IP-адреса. XML-процессоры рассматривают пробельные символы, окружающие «10.1.2.3», как неотъемлемую часть элемента <value>. Неспособность распознать это поведение может привести к недопониманию и ошибкам как при проектировании, так и при реализации.
Все пробельные символы считаются значимыми в XML-экземплярах. Следовательно, рекомендуется, чтобы разработчики протоколов предоставляли конкретные указания по обработке пробельных символов в протоколах, использующих XML.
4.17 Взаимодействие с IANA
Когда XML используется в протоколе IETF, существует несколько факторов, которые могут потребовать действий IANA, включая:
o Типы носителей XML. Фрагмент XML в элементе протокола иногда неразрывно связан с контекстом протокола, в котором он появляется, и, в частности, может быть непосредственно производным от реализаций конечного автомата протокола и/или входными данными для них. В случаях, когда XML-содержимое не имеет относящегося к делу значения вне исходного контекста протокола, нет причин регистрировать MIME-тип. Когда возможно, что XML-содержимое может интерпретироваться вне исходного контекста (например, когда это XML-содержимое хранится в файловой системе или туннелируется через другой протокол), MIME-тип может быть зарегистрирован, чтобы определить конкретный формат данных и дать подсказку о том, как они могут обрабатываться.
Если необходима MIME-маркировка, применимы рекомендации RFC 3023 [5]. В частности, если XML представляет новый язык или тип документа, следует зарегистрировать новый MIME-тип носителя по причинам, описанным в разделах 7 и A.1 RFC 3023. В ситуациях, когда XML используется для кодирования универсальных структурированных данных (например, в ориентированном на документы приложении, предусматривающем объединение XML с таблицей стилей), «application/xml» может быть уместным («МОЖЕТ использоваться» (MAY be used)). Тип носителя «text/xml» не рекомендуется («НЕ СЛЕДУЕТ использовать» (SHOULD NOT be used)) из-за вопросов, связанных с поведением отображения и наборами символов по умолчанию.
o Регистрация URI. Ведётся работа ([11], [12]) по созданию пространства имён URN специально для определения URI для имён пространств имён и других обозначаемых URI элементов протокола, используемых в документах IETF стандартизируемого направления; она также может установить политику IETF для такого использования.
5. Вопросы интернационализации
В этом разделе описываются вопросы интернационализации при использовании XML для представления данных в протоколах IETF. В дополнение к приведённым здесь рекомендациям также применяется политика IETF по использованию наборов символов и языков, описанная в RFC 2277 [3].
5.1 Наборы символов и кодировки
В протоколах IETF часто говорят о «наборе символов» или «charset» строки; это используется для обозначения как репертуара символов, так и кодировки, используемой для представления последовательностей символов в виде последовательностей байтов.
XML выполняет всю обработку символов в терминах Универсального набора символов (UCS, [31] и [33]). XML требует, чтобы все XML-процессоры поддерживали как кодировку UTF-8 [4], так и UTF-16 [20] для UCS, хотя могут быть разрешены и другие совместимые с UCS кодировки (наборы символов). Документы и внешние разобранные сущности, закодированные в UTF-16, должны начинаться с метки порядка байтов (Byte Order Mark) ([8], раздел 4.3.3).
Политика IETF [3] требует, чтобы набор символов UTF-8 был разрешён для всего текста.
Этот документ требует, чтобы протоколы IETF, использующие XML, допускали кодировку данных XML UTF-8. Поскольку соответствующие XML-процессоры также обязаны принимать кодировку UTF-16, рекомендуется также допускать кодировку UTF-16 (с обязательной меткой порядка байтов). Некоторые XML-приложения используют метку порядка байтов с кодировкой UTF-8, но такое использование не следует поощрять, и оно не подходит для XML, встроенного в другие протоколы.
Ограничение данных XML возможностью выражаться только в UTF-8 является дополнительным синтаксическим ограничением (см. раздел 4.3), которое в зависимости от обстоятельств может добавлять дополнительную сложность реализации. Когда используются кодировки, отличные от UTF-8 или UTF-16, кодировка должна быть указана с использованием атрибута «encoding» в XML-декларации (см. раздел 4.4), даже если могут существовать другие механизмы протокола для обозначения кодировки.
5.2 Объявление языка
Текст, заключённый в XML, может быть представлен на множестве различных человеческих языков, и часто полезно явно идентифицировать язык, используемый для представления текста. XML определяет специальный атрибут в пространстве имён «xml», xml:lang, который может использоваться для указания языка, применённого для представления данных в XML-документе. Атрибут xml:lang (который должен быть явно объявлен для использования в DTD или XML Schema) и значения, которые он может принимать, определены в разделе 2.12 документа [8].
Настоятельно рекомендуется, чтобы протоколы, представляющие данные на человеческом языке, предписывали использование атрибута xml:lang, если XML-экземпляр может интерпретироваться в зависимых от языка контекстах.
5.3 Другие вопросы интернационализации
В типографике некоторых человеческих языков существуют стандартные механизмы, которые может быть трудно представить, используя лишь строковые типы данных символов XML. Например, подсказки произношения могут предоставляться с использованием аннотации Ruby [39], а управляющие символы встраивания (такие как описанные в разделе 3.4 документа [34]) или атрибут XHTML [40] «dir» могут использоваться для указания правильного направления отображения двунаправленного текста.
Существует ряд сложных вопросов, которые могут возникнуть при использовании расширенных наборов символов с форматами XML-документов. Например:
o Существуют разные способы представления символов, состоящих из комбинируемых символов, и
o Велись некоторые споры о том, должны ли URI представляться с использованием ограниченного подмножества US-ASCII или произвольного Unicode (например, «URI character sequence» в сравнении с «original character sequence» в RFC 2396 [17]).
Некоторые из этих вопросов обсуждаются вместе с рекомендациями в документе W3C «Character Model for the World Wide Web» [44].
Настоятельно рекомендуется, чтобы протоколы, представляющие данные на человеческом языке, повторно использовали существующие механизмы по мере необходимости, чтобы обеспечить правильное отображение читаемого человеком текста.
6. Вопросы IANA
Эта памятка как таковая не оказывает влияния на IANA. В разделе 4.17 отмечены некоторые факторы, которые могут потребовать действий IANA при определении протоколов, использующих XML.
7. Вопросы безопасности
Сетевые протоколы сталкиваются со множеством различных видов угроз, включая непреднамеренное раскрытие, изменение и повторную передачу. Пассивные атаки, такие как перехват пакетов, позволяют атакующему захватывать и просматривать информацию, предназначенную для другого лица. Захваченные данные могут быть изменены и повторно переданы исходному предполагаемому получателю, при этом у получателя нет способа узнать, что информация была скомпрометирована, обнаружить изменения, удостовериться в личности отправителя или подтвердить, какой экземпляр протокола является законным.
Доступны несколько вариантов служб безопасности для XML, помогающих снизить эти риски. Хотя XML не включает встроенных служб безопасности, другие протоколы и уровни протоколов предоставляют службы, которые могут использоваться для защиты XML-протоколов. XML-шифрование [10] предоставляет службы конфиденциальности для предотвращения непреднамеренного раскрытия. Канонический XML [6] и цифровые подписи XML [7] предоставляют службы целостности для обнаружения изменения и службы аутентификации для подтверждения идентичности источника данных. Другие протоколы безопасности IETF (например, протокол Transport Layer Security (TLS) [2]) также доступны для защиты данных и конечных точек служб в зависимости от обстоятельств.
Учитывая отсутствие служб безопасности в XML, крайне важно, чтобы спецификации протоколов предписывали дополнительные службы безопасности для противодействия распространённым угрозам и атакам; конкретные требуемые службы будут зависеть от модели угроз протокола.
Опыт показал, что код, разбирающий сетевой трафик, часто является «лёгкой целью» для злоумышленников. Соответственно, реализаторы ДОЛЖНЫ (MUST) проявлять большую осторожность, чтобы гарантировать устойчивость их кода обработки XML к некорректно сформированному XML, переполнениям буфера, неправомерному использованию объявлений сущностей и тому подобному.
Механизмы XML, которые следуют внешним ссылкам (раздел 4.14), также могут подвергать реализацию различным угрозам, заставляя её автоматически обращаться к внешним ресурсам. Важно запретить произвольный доступ к таким внешним ссылкам внутри XML-данных из недоверенных источников. Многие грамматики XML определяют конструкции, использующие URI для внешних ссылок; в таких случаях должны быть приняты те же меры предосторожности.
8. Благодарности
Авторы хотели бы поблагодарить следующих людей, которые внесли значительный вклад в разработку этого документа:
Mark Baker, Tim Berners-Lee, Tim Bray, James Clark, Josh Cohen, John Cowan, Alan Crouch, Martin Duerst, Jun Fujisawa, Christian Geuer-Pollmann, Yaron Goland, Graham Klyne, Dan Kohn, Rick Jeliffe, Chris Lilley, Murata Makoto, Michael Mealling, Jean-Jacques Moreau, Andrew Newton, Julian Reschke, Jonathan Rosenberg, Miles Sabin, Rich Salz, Peter Saint-Andre, Simon St Laurent, Margaret Wasserman и Daniel Veillard.
9. Нормативные ссылки
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[6] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[7] Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[9] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[10] Imamura, T., Dillaway, B., Schaad, J. and E. Simon, "XML Encryption Syntax and Processing", W3C REC-xmlenc-core, October 2001, <http://www.w3.org/TR/xmlenc-core/>.
10. Справочные ссылки
[11] Masinter, L., Mealling, M., Klyne, G. and T. Hardie, "An IETF URN Sub-namespace for Registered Protocol Parameters", Work in Progress.
[12] Mealling, M., "The IETF XML Registry", Work in Progress.
[13] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[14] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[16] Crocker, D. (Ed.) and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[17] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[19] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[21] Klensin, J. (Ed.), "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[22] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,
C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC
3010, December 2000.
[23] Kennedy, H., "Binary Lexical Octet Ad-hoc Transport", RFC 3252,
April 2002.
[24] Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution
Protocol (CNRP)", RFC 3367, August 2002.
[25] Backus, J., "The syntax and semantics of the proposed
international algebraic language of the Zurich ACM-GAMM
conference", June 1959.
[26] American National Standards Institute, "Code Extension
Techniques for Use with the 7-bit Coded Character Set of
American National Standard Code (ASCII) for Information
Interchange", ANSI X3.41, FIPS PUB 35, 1974.
[27] American National Standards Institute, "Information Retrieval:
Application Service Definition and Protocol Specification",
ANSI Z39.50, ISO Standard 23950, 1995.
[28] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1)", ISO
Standard 8824, December 1990.
[29] International Organization for Standardization, "Information
Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN.1)", ISO Standard 8825, December 1990.
[30] International Organization for Standardization, "Information
processing - Text and office systems - Standard Generalized
Markup Language (SGML)", ISO Standard 8879, 1988.
[31] International Organization for Standardization, "Information
Technology - Universal Multiple-octet coded Character Set (UCS)
- Part 1: Architecture and Basic Multilingual Plane", ISO
Standard 10646-1, May 1993.
[32] International Organization for Standardization, "DSDL Part 0 -
Overview", December 2001, <http://www.jtc1.org/FTP/Public/SC34/
DOCREG/0275.htm>.
[33] Unicode Consortium, "The Unicode Standard, as it may from time
to time be revised or amended", March 2002, <http://
www.unicode.org/unicode/standard/standard.html>.
[34] Duerst, M. and A. Freytag, "Unicode in XML and other Markup
Languages", February 2002, <http://www.w3.org/TR/unicode-xml/>.
[35] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup
Language (XML) 1.0", W3C REC-xml-1998, February 1998, <http://
www.w3.org/TR/1998/REC-xml-19980210/>.
[36] Marsh, J., "XML Base", W3C REC-xmlbase, June 2001, <http://
www.w3.org/TR/xmlbase/>.
[37] Cowan, J. and R. Tobin, "XML Information Set", W3C REC-infoset,
October 2001, <http://www.w3.org/TR/xml-infoset/>.
[38] Lassila, O. and R. Swick, "Resource Description Framework (RDF)
Model and Syntax Specification", W3C REC-rdf-syntax, February
1999, <http://www.w3.org/TR/REC-rdf-syntax>.
[39] Suignard, M., Ishikawa, M., Duerst, M. and T. Texin, "Ruby
Annotation", W3C REC-RUBY, May 2001, <http://www.w3.org/TR/
ruby/>.
[40] Pemberton, S., "XHTML 1.0: The Extensible HyperText Markup
Language", W3C REC-XHTML, January 2000, <http://www.w3.org/TR/
xhtml1/>.
[41] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
<http://www.w3.org/TR/xmlschema-1/>.
[42] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
[43] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-
xslt, November 1999, <http://www.w3.org/TR/xslt>.
[44] Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A. and
T. Texin, "Character Model for the World Wide Web 1.0", April
2002, <http://www.w3.org/TR/charmod/>.
[45] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", June 2002,
<http://www.w3.org/TR/soap12-part1/>.
[46] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
Version 1.2 Part 2: Adjuncts", June 2002,
<http://www.w3.org/TR/soap12-part2/>.
[47] W3C Communications Team, "XML in 10 points", November 2001,
<http://www.w3.org/XML/1999/XML-in-10-points>.
[48] OASIS Technical Committee: RELAX NG, "RELAX NG Specification",
December 2001, <http://www.oasis-open.org/committees/relax-ng/
spec-20011203.html>.
[49] Jelliffe, R., "The Schematron", November 2001, <http://
www.ascc.net/xml/schematron/>.
URI (универсальные идентификаторы ресурсов)
[50] <http://www.imc.org/ietf-xml-use/>
[51] <http://xml.org/>
[52] <http://xmlhack.com/>
[53] <http://oasis-open.org/>
11. Адреса авторов
Scott Hollenbeck
VeriSign, Inc.
21345 Ridgetop Circle
Dulles, VA 20166-6503
US
Phone: +1 703 948 3257
EMail: shollenbeck@verisign.com
Marshall T. Rose
Dover Beach Consulting, Inc.
POB 255268
Sacramento, CA 95865-5268
US
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Larry Masinter
Adobe Systems Incorporated
Mail Stop W14
345 Park Ave.
San Jose, CA 95110
US
Phone: +1 408 536 3024
EMail: LMM@acm.org
URI: http://larry.masinter.net
12. Полное заявление об авторском праве
Copyright (C) The Internet Society (2003). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, которые комментируют или иным образом разъясняют его либо содействуют его реализации, могут подготавливаться, копироваться, публиковаться и распространяться полностью или частично без каких-либо ограничений при условии, что приведённое выше уведомление об авторском праве и этот абзац включены во все такие копии и производные работы. Однако сам этот документ не может быть каким-либо образом изменён, например путём удаления уведомления об авторском праве или ссылок на Internet Society либо другие интернет-организации, кроме случаев, когда это необходимо для разработки интернет-стандартов, при которой должны соблюдаться процедуры, касающиеся авторских прав, определённые в процессе разработки интернет-стандартов, либо когда это необходимо для перевода его на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут отозваны Internet Society или её правопреемниками либо цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ КОММЕРЧЕСКОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.