Механизм оптимизации передачи SOAP-сообщений

Официальная нормативная версия этой спецификации возможна только на английском языке и находится по адресу: http://www.w3.org/TR/soap12-mtom/

Данный перевод НЕ является официальным документом W3C.

Данный документ может содержать ошибки перевода и опечатки.

1. Вступление

Первая часть этого документа (2 Абстрактная функция оптимизации SOAP-передачи) описывает абстрактную функцию оптимизации передачи и/или формата SOAP-сообщения ([SOAP версия 1.2 Часть 1: Модель передачи сообщений) с помощью выборочного шифрования частей сообщения, в то же время представляя информационный набор XML SOAP-приложению.

Использование "Абстрактной функции оптимизации SOAP-передачи" является последовательным контрактом между SOAP-узлом и следующим SOAP-узлом на пути SOAP-сообщения, в том случае, конечно, если нет обязательных соглашений по оптимизации SOAP-передачи на посредниках. Эта функция таки предоставляет опциональный способ, с помощью которого реализации связывания МОГУТ облегчить эффективный проход оптимизированных данных в заголовках или телах, передаваемых посредником (см. 2.3.4 Оптимизация связывания на посредниках). Также могут быть написаны дополнительные спецификации, с предложениями других возможностей оптимизированного прохода, основываясь, возможно, на описанных здесь механизмах.

Вторая часть (3 Оптимизированная сериализация смешанного MIME-типа SOAP-сообщений) описывает применение "Оптимизированной сериализацией смешанного MIME-типа SOAP-сообщений" абстрактной функции оптимизации SOAP-передачи для независимого связывания. Эта реализация основана на формате [XML-binary Optimized Packaging].

Третья часть (4 Функция оптимизации HTTP SOAP-передачи) использует эту "Оптимизированную сериализацию смешанного MIME-типа SOAP-сообщений" для описания реализации абстрактной функции оптимизации передачи для HTTPсвязывания SOAP версии 1.2 (см. [SOAP версия 1.2 Часть 2: Дополнения] 7. SOAP HTTP-связывание).

1.1 Соглашения об обозначениях

Ключевые слова в этом документе, такие как "ДОЛЖЕН", "НЕ ДОЛЖЕН", "ТРЕБУЕТСЯ", "БУДЕТ", "НЕ БУДЕТ", "СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ОПЦИОНАЛЬНО", должны интерпретироваться согласно описанию в RFC 2119 [RFC 2119].

В этой спецификации используется некоторое количество префиксов пространства имен; они перечислены в [Использованные в этой спецификации префиксы и пространства имен.]. Учитывайте, что выбор любого префикса пространства имен является произвольным и не имеет зсемантического начения (см. информационное множество XML [XMLInfoSet]).

Использованные в этой спецификации префиксы и пространства имен:
Префикс	Пространство имен
Префикс	Примечания
env	"http://www.w3.org/2003/05/soap-envelope"
env	Нормативная XML-Схема [XML-Схема, Часть 1: Структуры. Второе издание], [XML-Схема, Часть 2: Типы данных. Второе издание] описывающий пространство имен "http://www.w3.org/2003/05/soap-envelope" находится на http://www.w3.org/2003/05/soap-envelope.
xop	"http://www.w3.org/2004/08/xop/include"
xop	Ненормативная XML-Схема [XML-Схема, Часть 1: Структуры. Второе издание], [XML-Схема, Часть 2: Типы данных. Второе издание] описывающий пространство имен "http://www.w3.org/2004/08/xop/include" находится на http://www.w3.org/2004/08/xop/include.
rep	"http://www.w3.org/2004/08/representation"
rep	Нормативная XML-Схема [XML-Схема, Часть 1: Структуры. Второе издание], [XML-Схема, Часть 2: Типы данных. Второе издание] описывающий пространство имен "http://www.w3.org/2004/08/representation" находится на TBD.
xs	"http://www.w3.org/2001/XMLSchema"
xs	Пространство имен типов данных XML-Схемы (см. [XML-Схема. Часть 2: Типы данных. Второе издание]).

1.2 Связь с другими спецификациями

4 Функция оптимизации HTTP SOAP-передачи (которая является реализацией 2 Абстрактной функции оптимизации SOAP-передачи для SOAP версия 1.2 HTTP-связывания) предназначается для улучшения раобты SOAP HTTP-связывания, описанного в [SOAP, версия 1.2. Часть 2: Дополнения] 7. SOAP HTTP-связывание либо откорректированной версии этого документа.

Этот документ, а также [XML-binary Optimized Packaging] и [SOAP Representation Header], были составленны в связи с разработкой требований, воплощенных в документе [W3C.soap-attachment-req].

2 Абстрактная функция оптимизации SOAP-передачи

2.1 Вступление

Абстрактная функция оптимизации SOAP-передачи позволяет SOAP-связываниям оптимизировать передачу и/или формат передачи SOAP-сообщений с помощью выборочного шифрования частей сообщения, в то же время представляя информационный набор XML SOAP-приложению. Оптимизация возможна только для содержимого элементов, являющегося каноническим лексическим представлением типа данных xs:base64Binary (см. [XML-Схема. Часть 2: Типы данных. Второе издание] 3.2.16 base64Binary).

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

Согласно требованию, что SOAP-связывание должно передавать информационное множество конверта нетронутым, реализации этой функции НЕ ДОЛЖНЫ замещать канонические представления на неканонические, либо вносить в содержимое оптимизированных элементов какие-либо другие изменения.

2.2 Абстрактная функция оптимизации SOAP-передачи - Имя

Эта "Абстрактная функция оптимизации SOAP-передачи" идентифицируется согласно URI:

"http://www.w3.org/2004/08/soap/features/abstract-optimization".

2.3 Абстрактная функция оптимизации SOAP-передачи - Обработка

2.3.1 Посылание сообщения

При посылании SOAP-сообщения, в случае испльзования абстрактной функции оптимизации SOAP-передачи вместе со схемой обмена SOAP-сообщениями запроса-ответа ([SOAP, версия 1.2. Часть 2: Дополнения] 6.2 Схема обмена SOAP-сообщениями запроса-ответа) либо Схема обмена SOAP-сообщениями ответа ([SOAP, версия 1.2. Часть 2: Дополнения] 6.3 Схема обмена SOAP-сообщениями ответа), свойством http://www.w3.org/2003/05/soap/mep/OutboundMessage, отправляется информационное множество SOAP-сообщения. В зависимости от ситуации похожие правила должны применяться в отношении других схем обмена сообщениями.

Целью "Абстрактной функции оптимизации SOAP-передачи" является оптимизация передачи данных закодированных в base64. Чтобы быть оптимизированными, символы состоящие из [дочерних элементов](children) элемента информации, ДОЛЖНЫ быть в канонической форме xs:base64Binary (см. [XML-Схема. Часть 2: Типы данных. Второе издание] 3.2.16 base64Binary) и НЕ ДОЛЖНЫ содержать пробелов, предшествующих, входящих, либо следующих за непробельным содержимым.

Примечание: способы идентификации элементов информации, которые содержат закодированные в base64 данные в канонической лексической форме зависят от реализации. Некоторые реализации могут идентифицировать подобные элементы информации по конструкции (например, потому что некоторые API могут создавать только канонические формы); другие могут проверять символы перед отправкой, еще одни могут полагаться на информацию в описании, такую как присутствие и/или значение анотирования схемы xmlmime:expectedMediaType (см. [Назначение медиа-типов бинарным данным в XML]), если схема доступна. Вследствие необходимости полной сохранности символов в передаваемом информационном множестве, неканонические представления НЕ ДОЛЖНЫ оптимизироваться реализациями этой функции.

2.3.2 Получение сообщения

При получении SOAP-сообщения, оптимизированного с помощью реализации "Абстрактной функции оптимизации SOAP-передачи", SOAP-узлу СЛЕДУЕТ сгенерировать отказ, если он не поддерживает использованную реализацию, либо "Абстрактную функцию оптимизации SOAP-передачи".

При получении SOAP-сообщения, получающий узел ДОЛЖЕН восстановить информационное множество конверта из оптимизированного SOAP-сообщения. Потом, получающий узел ДОЛЖЕН выполнить SOAP-обработку восстановленного информационного множества (см. [SOAP, версия 1.2. Часть 1: Модель передачи сообщений] 2. Модель SOAP-обработки). В любом случае, полученное информационное множество ДОЛЖНО быть в точности таким, как и переданное отправителем.

Реализации вольны восстанавливать только те части, которые требуются для обработки, либо подавать информацию сообщения в самой удобной для обработки форме. Например, посланное в оптимизированном виде (например, двоичном) значение МОЖЕТ быть сделано доступным в этой форме, а также в форме символа, закодированного в base64.

Когда эта функция используется вместе со "Схемой обмена SOAP-сообщениями запроса-ответа" ([SOAP, версия 1.2. Часть 2: Дополнения] 6.2 Схема обмена SOAP-сообщениями запроса-ответа) либо "Схема обмена SOAP-сообщениями ответа" ([SOAP, версия 1.2. Часть 2: Дополнения] 6.3 Схема обмена SOAP-сообщениями ответа), информационное множество, содержащееся в свойстве http://www.w3.org/2003/05/soap/mep/InboundMessage является информационным множеством восстановленного SOAP-конверта. В зависимости от ситуации похожие правила должны применяться в отношении других схем обмена сообщениями.

2.3.3 Посредники

Использование "Абстрактной функции оптимизации SOAP-передачи" является последовательным контрактом между SOAP-узлом и следующим SOAP-узлом на пути SOAP-сообщения. Потому эта функция не вводит на посреднике какие-либо изменения или ограничения модели SOAP-обработки. Раздел 2.3.4 Оптимизация связывания на посредниках детально описывает способы выполнения некоторых видов оптмизации с помощью связывания на посредниках.

Тем не менее SOAP-посредник реализующий "Абстрактную функцию оптимизации передачи" ДОЛЖЕН все же следовать правилам использования "Абстрактной функции оптимизации передачи" при получении сообщения (см. 2.3.2 Получение сообщения), а также относящимся к применению реализации "Абстрактной функции оптимизации SOAP-передачи" при посылании сообщения (см. 2.3.1 Посылание сообщения). В частности, он ДОЛЖЕН следовать правилам передачи SOAP-сообщений (см. [SOAP, версия 1.2. Часть 1: Модель передачи сообщений] 2.7 Передача SOAP-сообщений).

2.3.4 Оптимизация связывания на посредниках

Согласно описанию в [SOAP, версия 1.2. Часть 1: Модель передачи сообщений] 2.7 Передача SOAP-сообщений, SOAP-посредник может быть вызван для передачи нетронутыми некоторых заголовков, либо чтобы вставить заново заголовки идентичные полученным, но удаленным на время обработки. Более того, многие посредники будут передавать содержимое SOAP-тело немодифицированным. Во всех этих случаях части передаваемого сообщения имеют содержимое, которое идентично соответствующим частям входящего сообщения.

"Абстрактная функция оптимизации SOAP-передачи" не требует какого-либо особого соответствия между оптимизацией входящего и исходящего сообщения, даже когда оптимизированные части входящего сообщения передаются нетронутыми, либо заново вставленны в идентичную форму в информационном множестве конверта. Тем не менее, реализации связывания получения и связывания для передачи перепринимаемого сообщения МОГУТ работать вместе для осуществления эффективной передачи. Например, если входящее и исходящее связывавние использует одно и то же представление для оптимизированного двоичного кода, то реализации МОГУТ работать вместе для передачи оптимизированной формы напрямую от входящего связывания на исходящее. Решение реализовывать ли такую совместную работу, и если да, то каким способам, выносится в зависимости от спецификации(й) связывания и/или реализации связываний.

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

3 Оптимизированная сериализация смешанного MIME-типа SOAP-сообщений

3.1 Вступление

"Оптимизированная сериализация смешанного MIME-типа SOAP-сообщений" является расширением "Абстрактной функции оптимизации SOAP-передачи" используя как основу для описания моментов реализации этой функции формат [XML-binary Optimized Packaging]. Эта спецификация не описывает полную реализацию, но служит для того, чтобы предоставить поддержку для построения полной реализации "Абстрактной функции оптимизации SOAP-передачи". В частности, эта спецификация не определяет использование каких-то механизмов транспортировки SOAP-сообщения. Полная реализация основанная на этой спецификации описана в Функция оптимизации HTTP SOAP-передачи - Имя.

"Оптимизированная сериализация MIME Multipart/Related" предоставляет основу для реализации "Абстрактной функции оптимизации SOAP-передачи", описывая как оптимизированно сериализовать SOAP-конверт, используя формат [XML-binary Optimized Packaging] и MIME Multipart/Related пакетирование ([RFC 2387]).

Если говорить конкретней, информационное множество SOAP-конверта передается как MIME Multipart/Related XOP пакет (см. [XML-binary Optimized Packaging], 4.1 MIME Multipart/Related XOP пакеты). Любая версия XML, рекомендованная W3C, может хранить информационное множество XOP, созданное из информационного множества SOAP-конверта, в MIME Multipart/Related XOP пакете, хотя, надо учитывать, что информационное множество SOAP-конверта ДОЛЖНО быть сериализовано как XML версии 1.0.

3.2 Сериализация SOAP-сообщения

При посылании SOAP-сообщения с помощью MIME Multipart/Related сериализации, информационное множество SOAP-конверта сериализуется как обозначено в [XML-binary Optimized Packaging] 3.1 Создание XOP-пакетов. В частности:

Тип содержания внешнего пакета ДОЛЖЕН быть multipart/related.
Параметр типа заголовка типа содержимого внешнего пакета ДОЛЖЕН иметь значение "application/xop+xml" (см. [XML-binary Optimized Packaging], 4.1 MIME Multipart/Related XOP-пакеты).
Параметр "startinfo" заголовка типа содержания внешнего пакета ДОЛЖЕН должен указывать тип содержания для корневой части "application/soap+xml".
Тип содержания корневой части ДОЛЖЕН быть application/xop+xml (см. [XML-binary Optimized Packaging], 4.1 MIME Multipart/Related XOP-пакеты).
Параметр "type" заголовка типа содержания корневой части ДОЛЖЕН указывать тип содержания "application/soap+xml".

Результатом является MIME Multipart/Related XOP-пакет (см. [XML-binary Optimized Packaging]): одна часть тела, корень, содержит XML-представление модифицированного SOAP-конверта, с использованием дополнительной части для содержания бинарного представления каждого оптимизированного элемента.

3.3 Десериализация SOAP-сообщения

При получении SOAP-сообщения использующего эту оптимизированную MIME Multipart/Related сериализацию, информационное множество SOAP-конверта восстанавливается из MIME Multipart/Related XOP-пакета с помощью обработки, описанной в [XML-binary Optimized Packaging] 3.2 Интерпретирование XOP-пакетов.

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

4 Функция оптимизации HTTP SOAP-передачи

4.1 Вступление

Функция оптимизации HTTP SOAP-передачи является функцией уровня связывания, которая реализует "Абстрактную функцию оптимизации SOAP-передачи" в HTTP-связывании. Основой данной "Функции оптимизации HTTP SOAP-передачи" является "Оптимизированная MIME Multipart/Related сериализация", описанная в 3 Оптимизированная MIME Multipart/Related сериализация SOAP-сообщений.

Эта "Функция оптимизации HTTP SOAP-передачи" строится на текущем HTTP-связывании (см. [SOAP, версия 1.2. Часть 2: Дополнения] 7. SOAP HTTP-связывание), расширяя ее с помощью поддержки "Абстрактной функции оптимизации SOAP-передачи". По всем не описанным в этом разделе аспектам правила HTTP-связывания не модифицируются.

4.2 Функция оптимизации HTTP SOAP-передачи - Имя

Эта "Функция оптимизации HTTP SOAP-передачи" идентифицируется согласно URI:

"http://www.w3.org/2004/08/soap/features/http-optimization".

4.3 Реализация

"Функция оптимизации HTTP SOAP-передачи" использует "Оптимизированную MIME Multipart/Related сериализацию" (см 3 Оптимизированная MIME Multipart/Related сериализация SOAP-сообщений) для реализации "Абстрактной функции оптимизации SOAP-передачи". На отправляющей стороне эта функция сериализует SOAP-сообщения, как описано в 3.2 Сериализация SOAP-сообщения и вставляет MIME-заголовки получившегося MIME Multipart/Related XOP-пакета в виде HTTP-заголовков и остальной части пакета в HTTP-тело. На принимающей стороне эта функция извлекает MIME-заголовки из HTTP-заголовков, и остальной MIME Multipart/Related XOP-пакет из HTTP-тела, после чего выполняет десериализацию, согласно 3.3 Десериализация SOAP-сообщения.

4.3.1 Посылание SOAP-сообщения

При посылании SOAP-сообщения, "Функция оптимизации HTTP SOAP-передачи" меняет поведение [SOAP, версия 1.2. Часть 2: Дополнения] 7. SOAP HTTP-связывание). Этот раздел описывает влияние на [SOAP, версия 1.2. Часть 2: Дополнения] 7.5.1 Поведение запрашиваещого SOAP-узла, из-за использования "Функции оптимизации HTTP SOAP-передачи". Только описанные внизу аспекты отличаются от обычной работы HTTP-связывания, все остальные аспекты его работы остаются неизменными.

4.3.1.1 Инициализация (Init)

В состоянии "Init" формулируется HTTP-запрос и инициируется передача запроса. При использовании "Функции оптимизации HTTP SOAP-передачи" формулировка запроса отличается от [SOAP, версия 1.2. Часть 2: Дополнения] 7.5.1.1 Init, как указано в [Поля HTTP-запросов].

Поля HTTP-запросов
Поле	Значение
Поле заголовка для типа содержания	multipart/related
тело HTTP-сущности	SOAP-сообщение, сериализованное согласно 3 Оптимизированная MIME Multipart/Related сериализация SOAP-сообщений

XOP-пакет создается согласно 3 Оптимизированная MIME Multipart/Related сериализация SOAP-сообщений со следующими ограничениями:

Информационное множество XOP ДОЛЖНО быть сериализовано как application/xop+xml в корневой части пакета, согласно разделу 5 [XML-binary Optimized Packaging].
Каждый оптимизированный Узел ДОЛЖЕН генерировать в получившемся пакете ровно одну извлеченную бинарную часть, т.е. извлеченные на бинарные части НЕ ДОЛЖНО ссылаться более одного xop:Include в части SOAP-сообщения.
Каждая MIME-часть, на которую ссылается xop:Include ДОЛЖНА иметь поле заголовка Содержимое-Пересылка-Кодировка (Content-Transfer-Encoding).

Примечание: это не предотвращает MIME Multipart/Related пакет от включения дополнительных частей, на которые не ссылается элемент xop:Include. Такие дополнительные части не являются частью информационного множества SOAP-сообщения и не включается в модель обработки SOAP.

Реализации этого связывания ДОЛЖНЫ вводить правило, что XOP не должен использоваться с информационными множествами, которые содержат элементы информации имени xop:Include (см. [XML-binary Optimized Packaging] 3. Структурные элементы информационных множеств XOP). В любом случае там, куда посылается SOAP-конверт содержащий подобный элемент информации, связывание ДОЛЖНО выполнить одно из перечисленного ниже:

Вернуться к использованию медиа-типа application/soap+xml или любого другого подходящего медиа-типа, т.е. послать SOAP-конверт не используя "Функцию оптимизации HTTP SOAP-передачи".
Сгенерировать зависимый от связывания SOAP-отказ.

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

4.3.1 Получение SOAP-сообщения

При получении SOAP-сообщения, реализация SOAP HTTP-связывания (см. [SOAP, версия 1.2. Часть 2: Дополнения]) определит, была ли использована "Функция оптимизации HTTP SOAP-передачи" для проверки наличия медиа-типа application/xop+xml (см. [XML-binary Optimized Packaging] Раздел 5.1). Если медиа-тип HTTP-сообщения является "multipart/related", и медиа-тип корневой части MIME Multipart/Related пакета является application/xop+xml, и параметр "start-info" указывает тип содержимого "application/soap+xml", то полученное SOAP-сообщение было передано с помощью "Функции оптимизации HTTP SOAP-передачи" и ДОЛЖНО обрабатываться соответственно.

"Функция оптимизации HTTP SOAP-передачи" меняет поведение [SOAP, версия 1.2. Часть 2: Дополнения] 7. SOAP HTTP-связывание для получения SOAP-сообщения. Изменения в [SOAP, версия 1.2. Часть 2: Дополнения] 7.5.2 Поведение отвечающего SOAP-узла вследствие применения "Функции оптимизации HTTP SOAP-передачи", таковы:

При создании абстракции сообщения-запроса, находящейся на http://www.w3.org/2003/05/soap/mep/InboundMessage, HTTP-связывание ДОЛЖНО восстановить информационное множество SOAP-конверта, как описано в 3.3 Десериализация SOAP-сообщения.

Все другие аспекты работы HTTP-связывания остаются неизменными.

A Ссылки

SOAP Version 1.2 Part 1: Модель передачи сообщений: SOAP Version 1.2 Part 1: Messaging Framework, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, et. al., Editors. World Wide Web Consortium, 24 июня 2003. Эта версия находится на http://www.w3.org/TR/2003/REC-soap12-part1-20030624/. Самая новая версия находится на http://www.w3.org/TR/soap12-part1/.
SOAP Version 1.2 Part 2: Дополнения: SOAP Version 1.2 Part 2: Adjuncts, Henrik Frystyk Nielsen, Noah Mendelsohn, Jean-Jacques Moreau, et. al., Editors. World Wide Web Consortium, 24 июня 2003. Эта версия находится на http://www.w3.org/TR/2003/REC-soap12-part2-20030624/. Самая новая версия находится на http://www.w3.org/TR/soap12-part2/.
XML-binary Optimized Packaging: XML-binary Optimized Packaging, Mark Nottingham, Noah Mendelsohn, Martin Gudgin, and Hervé Ruellan, Editors. World Wide Web Consortium, 25 января 2005. Эта версия находится на http://www.w3.org/TR/2005/REC-xop10-20050125/. Самая новая версия находится на http://www.w3.org/TR/xop10/.
Функция присоединения SOAP, версия 1.2: SOAP 1.2 Attachment Feature, Hervé Ruellan and Henrik Frystyk Nielsen, Editors. World Wide Web Consortium, 08 июня 2004. Эта версия находится на http://www.w3.org/TR/2004/NOTE-soap12-af-20040608/. Самая новая версия находится на http://www.w3.org/TR/soap12-af/.
Требования и сценарии использования SOAP-оптимизированной сериализации: SOAP Optimized Serialization Use Cases and Requirements, Tony Graham, Mark Jones, and Anish Karmarkar, Editors. World Wide Web Consortium, 08 июня 2004. Эта версия находится на http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/. Самая новая версия находится на http://www.w3.org/TR/soap12-os-ucr/.
Представление ресурсов блоком SOAP-заголовка: Resource Representation SOAP Header Block, Martin Gudgin, Yves Lafon, and Anish Karmarkar, Editors. World Wide Web Consortium, 25 января 2005. Эта версия находится на http://www.w3.org/TR/2005/REC-soap12-rep-20050125/. Самая новая версия находится на http://www.w3.org/TR/soap12-rep/.
Назначение медиа-типов бинарным данным в XML: Assigning Media Types to Binary Data in XML, Ümit Yalçınalp and Anish Karmarkar, Editors. World Wide Web Consortium, 02 ноября 2004. Эта версия находится на http://www.w3.org/TR/2004/WD-xml-media-types-20041102. Самая новая версия находится на http://www.w3.org/TR/xml-media-types.
Extensible Markup Language (XML) версия 1.0 (Третье издание): Extensible Markup Language (XML) 1.0 (Third Edition), Jean Paoli, Eve Maler, Tim Bray, et. al., Editors. World Wide Web Consortium, 04 февраля 2004. Эта версия находится на http://www.w3.org/TR/2004/REC-xml-20040204. Самая новая версия находится на http://www.w3.org/TR/REC-xml.
Пространства имен в XML: Namespaces in XML, Andrew Layman, Dave Hollander, and Tim Bray, Editors. World Wide Web Consortium, 14 января 1999. Эта версия находится на http://www.w3.org/TR/1999/REC-xml-names-19990114. Самая новая версия находится на http://www.w3.org/TR/REC-xml-names.
Информационное множество XML (Второе издание): XML Information Set (Second Edition), Richard Tobin and John Cowan, Editors. World Wide Web Consortium, 04 февраля 2004. Эта версия находится на http://www.w3.org/TR/2004/REC-xml-infoset-20040204. Самая новая версия находится на http://www.w3.org/TR/xml-infoset.
XML-Схема. Часть 1: Структуры. Второе издание: XML Schema Part 1: Structures Second Edition, David Beech, Murray Maloney, Henry S. Thompson, and Noah Mendelsohn, Editors. World Wide Web Consortium, 28 октября 2004. Эта версия находится на http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ Самая новая версия находится на http://www.w3.org/TR/xmlschema-1/.
XML-Схема. Часть 2: Типы данных. Второе издание.: XML Schema Part 2: Datatypes Second Edition, Ashok Malhotra and Paul V. Biron, Editors. World Wide Web Consortium, 28 октября 2004. Эта версия находится на http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Самая новая версия находится на http://www.w3.org/TR/xmlschema-2/.
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. IETF, март 1997. Этот RFC находится на http://www.ietf.org/rfc/rfc2119.txt.
RFC 2387: The MIME Multipart/Related Content-type, E. Levinson, Editor. IETF, август 1998. Этот RFC находится на http://www.ietf.org/rfc/rfc2387.txt.
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding and L. Masinter, Editors. IETF, август 1998. Этот RFC находится на http://www.ietf.org/rfc/rfc2396.txt.
RFC 3023: XML Media Types, M. Murata, S. St.Laurent and D. Kohn, Editors. IETF, январь 2001. Этот RFC находится на http://www.ietf.org/rfc/rfc3023.txt.
PASWA: Proposed Infoset Addendum to SOAP Messages with Attachments, AT&T, BEA Systems, Canon, Microsoft Corporation, SAP AG и Tibco Software, апрель 2003. Этот документ находится на http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html.

B. Благодарности (ненормативный раздел)

Эта спецификация составлена Рабочеу группой W3C по XML-протоколам.

Членами этой Рабочей группы являются (на момент написания и в алфавитном порядке): David Fallside (IBM), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, ранее в DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), John Ibbotson (IBM), Anish Karmarkar (Oracle), Suresh Kodichath (IONA Technologies), Yves Lafon (W3C), Michael Mahan (Nokia), Noah Mendelsohn (IBM, ранее в Lotus Development), Jeff Mischkinsky (Oracle), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, ранее в Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Herve Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Ранее участвовали: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (webMethods), Mark Baker (Idokorro Mobile, Inc., ранее в Sun Microsystems), Philippe Bedu (EDF (Electricite De France)), Olivier Boudeville (EDF (Electricite De France)), Carine Bournez (W3C), Don Box (Microsoft Corporation, ранее в DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell, Inc.), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion (Software AG), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Dave Cleary (webMethods), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (Excelon Corporation), Ron Daniel (Interwoven), Glen Daniels (Macromedia), Doug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE Corporation), Frank DeRose (TIBCO Software, Inc.), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett Packard), James Falek (TIBCO Software, Inc.), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Dietmar Gaertner (Software AG), Scott Golubock (Epicentric), Mike Greenberg (IONA Technologies), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Frederick Hirsch (Zolera Systems), Erin Hoffmann (Tradia Inc.), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Limited), Oisin Hurley (IONA Technologies), Yin-Leng Husband (Hewlett Packard, formerly of Compaq), Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.), Scott Isaacson (Novell, Inc.), Kazunori Iwasa (Fujitsu Limited), Murali Janakiraman (Rogue Wave), Mario Jeckle (DaimlerChrysler Research and Technology), Eric Jenkins (Engenia Software), Mark Jones (AT&T), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Jacek Kopecky (Systinet), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Michah Lerner (AT&T), Bob Lojek (Intalio Inc.), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Nilo Mitra (Ericsson), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Highland Mary Mountain (Intel), Don Mullen (TIBCO Software, Inc.), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco Systems), Masahiko Narita (Fujitsu Limited), Mark Needleman (Data Research Associates), Art Nevarez (Novell, Inc.), Eric Newcomer (IONA Technologies), Henrik Nielsen (Microsoft Corporation), Conleth O'Connell (Vignette), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Andreas Riegg (DaimlerChrysler Research and Technology), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE Corporation), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera Systems), Krishna Sankar (Cisco Systems), George Scott (Tradia Inc.), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Miroslav Simek (Systinet), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Seumas Soltysik (IONA Technologies), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Anne Thomas Manes (Sun Microsystems), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (webMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (MartSoft Corp.).

Мы выражаем свою глубокую признательность всем людям, которые вносили свои предложения по этому адресу xml-dist-app@w3.org.