XML - статьи

         

Детерминизм


У определений типа документа (DTD, Document Type Definition) и XML-схемы W3C есть правило, согласно которому схемы должны иметь детерминистические модели содержания. Так, в спецификации "XML 1.0" записано:

Например, модель содержания ((b, c) | (b, d)) не является детерминистической, поскольку, принимая во внимание начальное b, XML-процессор, не проверив, какой элемент следует за b, не может знать, какая b в модели содержания сопоставляется.

Использование ##any означает, что имеются схемы, которые хотелось бы составить, но которые не являются допустимыми.

Групповые символы с ##any, где minOccurs не равен maxOccurs, не допускаются до объявления элемента. Экземпляр этого элемента был бы допустим для этого ##any или этого элемента. Мог бы использоваться ##other.

Элемент перед групповым символом с ##any обязан иметь количество элементов maxOccurs, равное minOccurs. Если бы они были различны, например, minOccurs="1" и maxOccurs="2", то необязательные вхождения элементов могли бы соответствовать либо описанию элемента, либо ##any. Следствием этого правила является требование о том, что minOccurs обязано быть больше нуля.

Необходимо избегать производных типов, которые добавляют описания элементов после группового символа с ##any. Если бы производный тип добавлял описание элемента после группового символа, экземпляр добавленного описания элемента мог бы соответствовать либо групповому символу, либо описанию производного элемента.

11. Правило "Детерминизм": использование групповых символов ОБЯЗАНО быть детерминистическим. Расположение групповых символов, пространство имен расширений групповых символов, значения minOccurs и maxOccurs являются ограниченными, а ограничения типов контролируемыми.

Как было показано выше, обычный подход проектирования - обеспечить точку расширяемости (не элемент), разрешив любое пространство имен в конце типа. Это обычно выполняется с помощью xs:any namespace="##any".

Во многих случаях, как и с законченным решением, в ситуации с детерминизмом это невыполнимо. Во-первых, точка расширяемости может иметь место только после обязательного элемента в исходной схеме, ограничивая тем самым область расширяемости исходной схемы. Во-вторых, изменения, поддерживающие обратную совместимость, требуют, чтобы добавленный элемент был необязательным, что подразумевает minOccurs="0". Детерминизм не позволяет разместить minOccurs="0" перед точкой расширяемости ##any. Таким образом, при добавлении элемента в точке расширяемости разарботчик схемы может задать элемент необязательным и потерять точку расширяемости или же определить его как обязательный, но лишиться обратной совместимости.



Идентификация и расширение языков


Встраивание расширяемости в языки обычно приводит к системам, которые являются более свободно связанными. Расширяемость позволяет отправителям изменять экземпляры без необходимости следовать централизованным нормативам. Таким образом, первое правило, касающееся расширяемости - это:

1. Правило "Расширяемость допускается": языки ДОЛЖНЫ быть предназначены для расширяемости

Основное требование, предъявляемое к расширяемости, это возможность определять язык, состоящий из элементов и атрибутов. Пространства имен XML обеспечивают технологию связывания URI (Uniform Resource Identifier, универсальный идентификатор ресурса) c именем XML-элемента или атрибута, то есть задают язык этого имени. В результате, также удается избежать конфликта имен.

Спецификация "W3C XML Schema" предоставляет конструкцию, называемую групповой символ (wildcard), <xs:any>, позволяющую проверять, где допускаются элементы из определенного пространства имен. Групповой символ означает, что элементы в указанном пространстве имен допустимы в реальных документах там, где находится групповой символ. Благодаря этому можно четко определять расширения схем. Получатели расширенных документов могут устанавливать и, в зависимости от модели обработки расширений, без риска игнорировать расширения, которые они не понимают.

<xs:any> использует атрибут namespace, чтобы проверять, из каких пространств имен поступают элементы расширения. Основные значения этого атрибута - ##any, которое означает, что схему можно расширить, используя элемент из любого возможного пространства имен; ##other, который допускает только элементы расширения из пространств имен, отличных от текущего; ##targetnamespace, допускает только элементы расширения из текущего пространства имен.

<xs:any> использует атрибут processContents, чтобы контролировать, как XML-парсер проверяет на допустимость расширенные элементы. Возможные методы: "lax" ("нестрогий") - допускающий проверку, "strict" ("строгий") - требующий проверки, "skip" ("пропустить") - позволяющий ее пропустить. В этой статье используется нестрогая проверка, поскольку это наиболее гибкий и типичный выбор для спецификаций Web-сервисов.


Основная цель модели "Необходимо пропускать" - разрешить внесение в документы изменений, обеспечивающих обратную и прямую совместимость. Как минимум, это не подразумевает ни добавления имен пространств имен, ни изменения имен элементов. Добавление имен элементов в целевое пространство имен (target namespace) может быть выполнено с пространством имен ##any или комбинацией пространства имен ##other и целевого пространства имен словаря.



Приведем ряд примеров, демонстрирующих это правило. Предположим, что заказ на поставку (purchase order) пересылается с одной машины на другую. В результате обработки этого заказа появляется сообщение "отгружено" ("shipped"). Однако, это сообщение могло быть отправлено спустя какое-то время после получения заказ на поставку. Было бы желательно, чтобы программное обеспечение, осуществляющее отправку, могло бы подождать ответ произвольное время (синхронный обмен сообщениями). Предпочтительная модель для получателя - иметь возможность самостоятельно отправить сообщение "отгружено", не заставляя отправителя ждать. Получатель "перезванивает" первоначальному отправителю - отсюда происходит термин "обратный вызов" ("callback"). Отправитель предоставляет получателю адрес в виде адреса обратного вызова. Он указывает адрес, который получатель должен использовать для отправки отправителю любых последующих сообщений. В случае Web-сервисов этот обратный вызов обычно отравляется в виде блока SOAP Header.

Предпочтительным вариантом было бы применение расширяемого стиля ##any. Ниже приведен тип CallbackType (тип обратного вызова), который использует эту модель:

Пример 1. Схема, в которой для расширяемости используется ##any

<s:complexType name="CallbackType"> <s:sequence> <s:element name="callbackLocation" type="s:anyURI" minOccurs="1" maxOccurs="1"/> <s:any processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##any"/> </s:sequence> <s:anyAttribute/> </s:complexType>



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

Пример 2. Неправомерная схема

<s:complexType name="CallbackType"> <s:sequence> <s:element name="callbackLocation" type="s:anyURI" minOccurs="1" maxOccurs="1"/> <s:element name="expires" type="s:dateTime" minOccurs="0" maxOccurs="1"/> <s:any processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##any"/> </s:sequence> <s:anyAttribute/> </s:complexType>

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

2. Правило "Любое пространство имен": уровень расширяемости ДОЛЖЕН предусматривать расширения в любом пространстве имен. Для приложений XML-схемы точка расширяемости ДОЛЖНА быть элементом, который разрешает расширение в целевом пространстве имен, и групповым символом, который разрешает расширения в любом другом пространстве имен.
Второе правило - допущение расширяемости:

3. Правило "Полная расширяемость": все XML-элементы ДОЛЖНЫ разрешать расширяемость элемента после определения элемента и допускать любые атрибуты.


Ниже приведен пример типа Callbacktype, который выполняет эти требования:

Пример 3. Тип Callback с расширяемостью

<s:complexType name="CallbackType"> <s:sequence> <s:element name="callbackLocation" type="s:anyURI" minOccurs="1" maxOccurs="1"/> <s:element name="Extension" type="wscb:ExtensionType" minOccurs="0" maxOccurs="1"/> <s:any processContents="lax" minOccurs="0" maxOccurs="unbounded" namespace="##other"/> </s:sequence> <s:anyAttribute/> </s:complexType> <s:complexType name="ExtensionType"> <s:sequence> <s:any processContents="lax" minOccurs="1" maxOccurs="unbounded" namespace="##targetnamespace"/> </s:sequence> <s:anyAttribute/> </s:complexType>

Поскольку каждое расширение в целевом пространстве имен находится внутри элемента Extension, каждое последующее пространство имен будет увеличивать вложенность на один уровень. Хотя такой уровень вложенности на расширение нежелателен, это то, что сегодня можно сделать при задании строгой проверки на допустимость по XML-схеме W3C. Кажется, что наличие многочисленных вложенных элементов оправдано, если в язык могут быть внесены многократные совместимые исправления. Этот прием позволяет выполнить проверку допустимости расширений в целевом пространстве имен при сохранении проверки допустимости самого целевого пространства имен.

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


Определение совместимости


Определения обратной и прямой совместимости можно найти в Бесплатном он-лайн словаре по вычислительной технике FOLDOC . В этой статье эти определения переосмысливаются с позиции инициатора сообщений, а именно: отправителей и получателей, а не клиентов и серверов. Итак, обратная совместимость означает, что при установке новой версии получателя существующая версия отправителя не будет разрушена. Другими словами, отправитель посылая старую версию сообщения получателю, который понимает новую версию, может быть уверен, что его сообщение успешно обработано. Прямая совместимость означает, что более старая версия получателя может использовать более новые сообщения и при этом не останавливаться. Разумеется, эта более старая версия не реализует новое поведение, но отправитель может посылать более новую версию сообщения, и это сообщение будет успешно обработано.

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

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

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



Понимание расширений


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

4. Правило "Обеспечение модели обработки": языки ДОЛЖНЫ устанавливать модель обработки для взаимодействия с расширениями.

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

5. Правило "Обязательно игнорировать": получатели документа ОБЯЗАНЫ игнорировать любые XML-атрибуты и элементы в допустимом XML-документе, которые они не распознают.

Это правило не требует, чтобы элементы были физически удалены - они должны быть только пропущены при обработке. У правила "Обязательно игнорировать" длинные исторические корни. HTML 1.1, 2.0 и 3.2 следуют этому правилу; в этих языках установлено, что любой неизвестный начальный или конечный тег не отображается во процессе преобразования в символы. В HTTP 1.1 указано, что получатель должен пропускать любой заголовок, который он не понимает: "Нераспознанные поля заголовков ДОЛЖНЫ быть пропущены получателем и ОБЯЗАНЫ быть пересланы прозрачными представителями (proxy)". Впервые правило "Обязательно игнорировать" появилось в 1997г., оно было введено рабочей группой WebDAV в разделе 14 спецификации RFC 2518 (Запрос на комментарии), а затем опубликовано отдельным документов - "Гибкий профиль обработки XML-документов" (Flexible XML Processing Profile ).

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


6. Правило "Обязательно игнорировать все": правило "Обязательно игнорировать" применяется к нераспознанным элементам и их потомкам.
Например, если сообщение получено с нераспознанными элементами в блоке SOAP header, они должны быть пропущены, если только не помечены как "mustUnderstand" (см. ниже правило 10), однако допустимо предположить, что нераспознанные элементы могут быть записаны в лог-файл.

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

7. Правило "Обязательно игнорировать контейнер": правило "Обязательно игнорировать" применяется только к нераспознанным элементам.
В результате потомки элементов сохраняются, например, с целью отображения.

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


Причины сложностей


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

Что касается XML-схемы W3C, то было бы удобно иметь возможность добавлять элементы в произвольных местах, например, перед другими элементами, однако ограничения детерминизма этому препятствуют. Можно было бы воспользоваться менее ограниченной детерминистической моделью, такой как "жадный" алгоритм (greedy algorithm), определенный в спецификации URI . Это разрешило бы располагать необязательные элементы перед групповыми символами и позволило бы устранить потребности в введенном выше типе Extensiontype. Однако, групповые символы по-прежнему недопустимы перед элементами, поскольку вместо этого групповой символ соответствовал бы элементам. Далее, по-прежнему не могут сосуществовать групповые символы и расширения типа. "Приоритетная" модель, в которой элемент мог бы быть сопоставлен с групповым символом или элемент сопоставлялся бы с элементом, если такое возможно, разрешала бы групповые символы до и после объявления элементов. Кроме того, групповой символ, который допускал элементы, которые не были определены - фактически другие пространства имен плюс что-нибудь, не определенное в целевом пространстве имен - еще одна удобная модель. Эти изменения также разрешили бы более четкое объединение наследования и групповых символов. Но это также означает, что разработчик схемы должен распределить групповые символы по их типам. Требуется элемент уровня типа в сочетании с вышеупомянутыми изменениями групповых символов. Возможное решение заключается в том, что объявление последовательностей могло бы содержать атрибут, указывающий, что расширения допустимы в любом месте, затем - соответствующие атрибуты, указывающие пространства имен, элементы и правила проверки на допустимость.


Сложность с последним подходом состоит в том, что для конкретной схемы иногда необходимо применять в различных частях системы одну и ту же схему нестрого и нестрого. Давнее правило для Интернет - это принцип устойчивости (Robustness Principle), сформулированный следующим образом в протоколе Internet (Internet Protocol) : "в большинстве случаев реализация должна быть консервативна при отправке сообщений и либеральна при их получении". Применительно к проверке допустимости по схеме отправитель может применять схему строго, а получатель - нестрого. В этом случае степень строгости - это не атрибут схемы, а то, как она используется. Решение, которое, кажется, может решить эти проблемы, - определить форму проверки по схеме, которая разрешит открытую модель содержания, используемую при задании версий схем. Назовем эту модель проверкой допустимости "по отображению" - она работает игнорируя, а не отбрасывая, имена компонентов, которые появляются в сообщении, не являясь явно определенными в схеме. Автор статьи планирует в будущем рассмотреть эту модель нестрогой проверки допустимости.

Последнее замечание в адрес расширяемости XMLсхемы W3C заключается в том, что по-прежнему остается нерешенным вопрос определения схем, которые проверяют допустимость известных расширений, сохраняя при этом расширяемость. Разработчикам схем потребуется не только создавать схему, основанную на расширяемой схеме, но и соединить с другими известными схемами с отдельными групповыми символами, сохраняя при этом расширяемость групповых символов. Автор столкнулся с такой сложностью при описании блоков SOAP header. Вопрос компоновки схем из множества схем хотя и не прост, но требует скорейшего разрешения.

Закончив с рассмотрениеv расширяемости групповых символов, отметим, что использование расширения типов во "Всемирной паутине" могло бы быть более удобным, если бы в реальном документе был выражен базовый тип, когда получатель не понимает тип расширения, например, в выражении xsi:basetype="". Тогда получатель мог бы нейтрализовать неисправность, воспользовавшись базовым типом, если он не понял расширения этого базового типа.



Еще одна область архитектурного улучшения - обеспечиn в XML, или даже XML-схеме W3C, модель mustUnderstand. В настоящий момент каждый словарь, который предоставляет модель mustUnderstand, изобретает заново "колесо mustUnderstand". XML мог бы предоставлять атрибут xml:mustUnderstand и модель, которую мог бы использовать каждый язык. Хотя в феврале 2000г. Тим Бернерс-Ли в своей проектной записке о обязательных расширениях [8] писал о необходимости включения этой модели в XML, она не была добавлена ни в XML 1.0, ни в XML 1.1.

Наконец, сохраняется неоднозначность при испытании реализаций на соответствие XML-схемам W3C. Набор тестов по XML-схемам W3C не охватывает более общие случаи, которые не были рассмотрены в данной статье. Например, тесты включают особый стиль, для которого xs:any находится внутри сложного типа. Однако, они не рассматривают некоторые недетерминистические случаи, обычно возникающие при комбинировании вариаций minOccurs/maxOccurs с ##any или комбинировании наследования с ##any. Следовательно, некоторые реализации не являются корректно оттестированными в случае отсутствия детерминизма, что может привести к появлению неработоспособных документов.

Еще одна сложность связана с поддержкой в реализациях этих функциональных возможностей и комбинаций. Данные примеры были апробированы в различных парсерах и инструментальных инструментах, предназначенных для работы со схемой, как, например, XML Beans, SQC и JAX-RPC. Несмотря на то, что хотя невозможно выяснить, все ли реализации поддерживают эти правила, то, что было протестировано, похоже обеспечивает хорошую поддержку. Автору статьи, разумеется, будет небезынтересно узнать о инструментальных средствах, которые не обеспечивают поддержку этих правил.


Ресурсы


Бесплатный он-лайн словарь по вычислительной технике ()

Гибкий профиль обработки XML-документов ()

Запрос на комментарии комитета по инженерным вопросам Internet 791 ()

Запрос на комментарии комитета по инженерным вопросам Internet 2396 ()

Запрос на комментарии комитета по инженерным вопросам Internet 2518 ()

Запрос на комментарии комитета по инженерным вопросам Internet 2616 ()

Протокол

Спецификация

Примеры успешного использования схем на сайте Xfront ()

Примечания консорциума W3C "Архитектура Web: расширяемые языки" ()

Спецификация консорциума W3C "XML 1.0" ()

Спецификация консорциума W3C "Пространства имен XML" ()

Спецификация консорциума W3C "XML-схема, Часть 1" ()

Набор тестов Рабочей группы XML Schema консорциума W3C для конструкции Any ()

Статья Деара Обасаньо (Dare Obasanjo), опубликованная на ресурсе XML.com, "Принципы проектирования XML-схем" ()

Работы Тима Бернерса-Ли (Tim Berners-Lee) о развитии, расширяемости и mustUnderstand:

Заключение Группы технического проектирования W3C о расширяемости и управлению версиями ()

Раздел документа Группы технического проектирования W3C "Архитектура Web" о расширяемости и управлении версиями ()



Управление версиями


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

8. Правило "Повторного использования имен пространств имен": если в спецификацию могут быть внесены изменения, обеспечивающие обратную совместимость, НЕОБХОДИМО использовать старое имя пространства имен вместе с моделью расширения XML.

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

9. Правило "Повторного использования пространств имен": новое имя пространства имен используется, если обратная совместимость недопустима, то есть программное обеспечение ОБЯЗАНО приостановиться, если оно не понимает новые конструкции языка.

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

Приведенное выше правило требует соблюдения правил "Обязательно игнорировать" и "Любое пространство имен". Если требования этих правил не выполнены, разработчик языка оказывается лишенным возможности вносить совместимые изменения и повторно использовать имя пространства имен.

Выше отмечалось, что повторное использование имен пространств имен для совместимых расширений - хорошая практика. Противоположенный подход состоит в том, что владелец пространства имен мог бы использовать новое имя для совместимых изменений, предоставив точки расширяемости, допускающие другие пространства имен - xs:any namespace="##other". Этот подход проблематичен - расширение в другом пространстве имен означает, что комбинированная схема не может быть проверена полностью. Точнее, невозможно создать новую схему, которая ограничивает групповой символ. Предположим, например, что ns1 содержит foo и bar. В этом случае просто используя ограничения XML-схемы W3C, невозможно взяв схему SOAP - пример схемы с групповым символом - потребовать, чтобы элемент ns1:foo был бы потомком элемента заголовка, а ns1:bar не был бы потомком элемента заголовка. Действительно, потребность в такой возможности "взывает" к функциональности WSDL (Web Services Description Language, язык описания Web сервисов). Применение подхода с новым именем пространства имен имеет своим результатом спецификации и пространства имен, которые расчленены неподходящим образом, поскольку связанные конструкции оказываются в различных пространствах имен. Далее, повторное использование одного и того же пространства имен гарантирует лучшую инструментальную поддержку. Многие приложения используют одну схему для создания эквивалентных программных конструкций. Эти инструменты часто работают наилучшим образом с поддержкой одиночного пространства имен для "обобщенных" конструкций. Повторное использование имени пространства имен разрешает по крайней мере автору пространства имен вносить изменения в пространства имен и выполнять проверку допустимости расширений.



Язык XML предназначен для создания


Язык XML предназначен для создания языков, основанных на самодокументированной разметке. Неизбежное развитие этих языков называется управлением версиями. Управление версиями подразумевает добавление, удаление или изменение частей языка. На практике управление версиями - это чрезвычайно сложная задача в теории вычислительной техники, имеющая длинную историю безуспешных проб и ошибок. Можно утверждать, что одна из причин невероятного роста популярности "Всемирной паутины" заключается в том, что развитие языков и управление версиями были встроены в заголовки HTML и HTTP, каждый из которых предоставляет явные точки и правила расширяемости, необходимые для понимания расширений, сделавших возможным их децентрализованное расширение и управление версиями.
Спецификация "Пространства имен XML" обеспечивает идеальный механизм идентификации версий языков, и все языки XML-схемы - такие как W3C XML Schema - предусматривают управляемую расширяемость.
В этой статье описываются подходы, позволяющие добиться более эффективной слабой связи между системами за счет расширения возможности вносить изменения, обеспечивающие обратную и прямую совместимость (backwards- and forwards-compatible changes) при развитии связанных систем. Эти приемы предназначены для совместимых изменений как при передаче схемы, так и без ее распространения. Для управления версиями XML-словарей определяется набор правил, в которых используются конструкции спецификаций "Пространства имен XML" и "XML Schema". Этот набор включает правила для работы с языками, которые предоставляют расширяемую модель контейнера, особенно SOAP. Этот совокупный набор правил называется моделью расширяемости "Обязательно игнорировать" ("Must Ignore" pattern). Как ни странно, но несмотря на то, что эта модель в значительной степени способствовала признанию тегов HTML и заголовков HTTP, среди практиков-разработчиков XML-приложений она не снискала широкую популярность. Данная статья призвана исправить эту ситуацию в отношении существующих программных оболочек, предназначенных для проверки допустимости документов по схеме. В последующих материалах будут рассмотрены оболочки, в которых реализуется более новый подход к проверке допустимости - нестрогая проверка.

и расширяемости оказалась настолько важной


Проблема управления версиями и расширяемости оказалась настолько важной для архитектуры Web, что Группа технического проектирования W3C (Technical Architecture Group, сокр. TAG) опубликовала свои заключение по этому вопросу и включила соответствующие материалы в документ "Архитектура Web" (Web Architecture) . Данную статью можно считать отправным моментом при изучении материалов TAG, в документах TAG область рассмотрения шире, а изложение материала носит более последовательный характер. Читатели могут обриться к этим документам за текущей трактовкой вопросов расширяемости и управления версиями.
В этой статье описан ряд правил использования XML, XML-схем W3C и пространства имен XML в конструкциях и расширениях языка. Основная задача этого набора правил - разрешить разработчикам схем вносить в свои языки изменения, поддерживающие обратную и прямую совместимость, чтобы реализовать слабую связь между системами.
В определенной степени описанный подход является комбинацией моделей ##any и ##other с хорошо известными правилами построения схем, которые решают задачу совместимой расширяемости и управления версиями с проверкой допустимости с помощью XML-схемы W3C. Владелец имени пространств имен может вносить в элемент расширяемости изменения, поддерживающие обратную и прямую совместимость, сохраняя возможность проверять допустимость всех компонентов, а другие разработчики схем могут добавлять изменения в расположении группового символа ##other.

Замещение модели обработки по умолчанию


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

10. Правило "Обеспечение mustUnderstand": языки контейнера должны обеспечить модель "mustUnderstand" для обработки факультативности расширений, которые замещают правило "Обязательно пропускать".

Это правило и правило "Обязательно пропускать" работают совместно, обеспечивая стабильную и гибкую модель обработки расширений. Можно доказать, что наиболее простой и гибкий прием замещения - это признак mustUnderstand, который указывает, должна ли единица быть понятной. Атрибуты для SOAP , WSDL WS-Policy и значения для установления understand имеют следующий вид: soap:mustUnderstand="1", wsdl:required="1", wsp:Usage="wsp:Required", соответственно. SOAP, вероятно, наиболее общий случай контейнера, который обеспечивает модель mustUnderstand. Значение по умолчанию равно 0, что фактически является правилом "Обязательно пропускать".

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

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

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



Кандидат к рекомендации


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

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

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

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



Международный консорциум W3C: от Рабочего проекта до Рекомендации


Дата: 08-04-2003

Подготовлено: по материалам организации
Перевод: Intersoft Lab

Начиная рассказ о процедурах принятия стандартов, мы хотели бы подчеркнуть, что в настоящий момент "на ниве стандартизации" плодотворно трудится целый ряд различных международных и национальных органов, включая такую авторитетную организацию, как ISO (International Standards Organization, Международная организация по стандартизации). То, что мы остановились на W3C и OASIS (см. следующую статью), объясняется исключительно XML-направленностью данной рубрики. Кроме того, эти консорциумы являются наиболее авторитетными и известными организациями в области XML-технологий (сразу оговоримся, что мы нисколько не пытаемся принизить значимость других объединений, как, например, XBRL Inc. или WS-I, - изучив принятые в этих органах правила и нормы принятия стандартов, можно говорить об общности подходов при их разработке и утверждении).



Немного истории


World Wide Web Consortium (W3C) - это международная организация, объединяющая в своих рядах около 450 членов и постоянный штат из более чем 60 сотрудников. W3C был создан в октябре 1994 года по инициативе Тима Бернерса-Ли (Tim Berners-Lee), создателя "всемирной паутины", на базе Лаборатории вычислительной техники Массачусетского технологического института (Massachusetts Institute of Technology, ) при активном участии Европейской организации по ядерным исследованиям (Conseil Europeen pour la Recherche Nucleaire, CERN), Управления перспективных исследовательских программ (Defense Advanced Research Projects Agency, DARPA) и Европейской комиссии (European Commission). В апреле 1995 года европейское представительство консорциума "приютил" Национальный институт исследований в области компьютерной обработки данных и автоматики (Institut National de Recherche en Informatique et en Automatique, INRIA), а в 1996 году - появилось азиатское отделение - инициатором выступил японский центр Shonan Fujisawa Campus (Keio University of Japan). Наконец, в этом году Европейскому научно-исследовательскому консорциуму в области информатики и математики (European Research Consortium on Informatics and Mathematics, ERCIM) "были переданы функции" INRAI.



Организационная структура


Как отмечалось выше, основу W3C составляют его члены: поставщики продуктов и услуг, корпоративные пользователи, исследовательские лаборатории, органы стандартизации, правительства различных стран. Члены организации направляют технических специалистов и своих представителей для участия в работе различных групп консорциума: Рабочих групп (Working Group), Неспециализированных групп (Interest Group) и Координационных групп (Coordination Group) - руководство которыми осуществляет персонал W3C, или так называемая Целевая группа (Team). В этих группах выполняется львиная доля работы консорциума - результатом их деятельности являются технические отчеты, программные средства с открытым кодом и различные услуги.

Организационно, все работы в консорциуме ведутся по так называемым направлениям деятельности (Activity). Цели и задачи каждого такого направления излагаются в Декларации направления (Activity statement), в котором приводится список задействованных групп.



От предложения до рекомендации


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

В процессе рассмотрения различных заявок и замечаний, направляемых членами консорциума, организации конференций и семинаров, а также отслеживания развития Web-технологий, руководство W3C - Team - может прийти к выводу о необходимости формирования нового направления деятельности. С этой целью Директор (Director) направляет в Консультативный комитет (Advisory Committee) предложение о формировании нового направления деятельности (Activity Proposal). В течение периода рассмотрения, который длится не менее месяца, Консультативный комитет высказывает свои соображения и замечания по обсуждаемому вопросу, после чего Директор информирует комитет об отношении членов консорциума к этому предложению. При наличии консенсуса, то есть если эта идея получила всеобщую поддержку, W3C инициирует новое направление.

Как указывалось выше, итогом деятельности той или иной рабочей группы являются технические отчеты. Международный консорциум различает и публикует два типа отчетов: Примечания (Note) и Технические отчеты.

Примечания - это различные документы, комментарии, мнения членов консорциума и представителей общественности. К ним также относятся заявки на рассмотрение, направляемые членами W3C, и различные информационные ресурсы, сформированные в процессе работы какой-либо рабочей группы или Целевой группы.

Технический отчет представляет собой одну из возможных версий стандарта, разрабатываемого рабочей группой: Рабочая версия (Working Draft), Последняя редакция Рабочей версии, или Рабочей версия в статусе "крайнего срока" (Last Call Working Draft), Кандидат к рекомендации (Candidate Recommendation), Предложенная рекомендация (Proposed Recommendation) и Рекомендация (Recommendation).

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


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

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

Остановимся более подробно на процедуре разработки и принятия различных версий стандартов W3C.





Рис. 1. Схематическое представление этапов стандартизации



Последняя редакция Рабочей версии


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

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



Предложенная рекомендация


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

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

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

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



Рабочая версия


Рабочая версия - это "первая ступень" в продвижении технического отчета к самому высокому статусу, который может получить спецификация - Рекомендации. Формально, для опубликования Рабочей версии необходимо согласие Директора, хотя факт обнародования документа не является отражением наличия консенсуса или одобрения со стороны W3C. При этом, Рабочая группа вправе запросить издания Рабочей версии, даже если ее текст не является окончательным и не отвечает всем требованиям группы.

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



Рекомендация


Чтобы Предложенная рекомендация превратилась в Рекомендацию, Директор должен быть уверен, что она пользуется ощутимой поддержки со стороны Консультативного комитета, Целевой группы, рабочих групп W3C и общественности. Решение о предании документу статуса Рекомендации является решением W3C.

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

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

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

document.write('');

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

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

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

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

 (66)

2 Август, 17:53

 (19)

2 Август, 17:51

 (34)

2 Август, 15:40

 (42)

2 Август, 15:35

 (1)

2 Август, 14:54

 (3)

2 Август, 14:34

 (3)

2 Август, 14:15

 (2)

2 Август, 13:34

 (7)

2 Август, 13:04

 (3)

2 Август, 12:28

BrainBoard.ru

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

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

Loading

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

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

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

This Web server launched on February 24, 1997

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


и не раз уже проверенная


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

Как работает WiX


В среду создания дистрибутивов входит четыре компонента. Это, во-первых, сама схема XML/WiX, вокруг которой построены основные утилиты. Компилятор candle компилирует исходные файлы в объектные. Линкер light связывает файлы в один MSI- или MSM-файл. Декомпайлер — dark — напротив, строит WiX-файлы на основании существующих MSI- или MSM-файлов.

В основе всего процесса генерации лежит обычно один XML-файл особого формата, в терминах XML называемого схемой. Обычно файлы WiX имеют расширение *.wxs. Самый простой и тривиальный файл содержит всего один тэг — ссылку на прототип WiX-документа и имеет вид:

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

В результате вы получите файл с тем же именем, что и ваш WXS, но только с расширением wixobj. Этот файл содержит всю информацию о составе дистрибутива, но не сами файлы — таким образом вы можете компилировать wix-файлы реже, чем выполнять сборку, поскольку компиляция нужна, только если вы изменяете состав инсталляции. Обновление самих файлов не требует повторного применения candle.
Говоря попросту, объектный файл тоже является XML-файлом, в котором компилятор добавляет дополнительную информацию о включаемых объектах. В числе прочего, ссылка на оригинальный файл позволяет отслеживать проблемы и их источник. Чтобы убедиться в этом, откройте результирующий wixobj в любом редакторе:



Реальные объекты


Наконец рассмотрим третий пример, который, помимо записи в "Установленных программах", создает еще один реальный объект, в частности записывает файл в каталог приложения. В качестве файла мы, вслед за документацией, будем использовать простой текстовый файл с произвольным содержанием, в нашем случае его имя — readme.txt. Создайте такой файл в каталоге, где расположен ваш проект. Файл WXS будет иметь такой вид:

Откомпилируйте и свяжите этот файл в MSI — после инсталляции вы получите ожидаемый эффект: в каталоге приложения C:\Program Files\Test Program появится текстовый файл. Удалить приложение можно, как и прежде, через "Панель управления". Дополнительно вы можете проделать то же самое, выполнив команду:

>msiexec /x 1.msi

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



Установка фиктивного продукта


Рассмотрим несколько более сложный пример, приведенный в документации по WiX, который создает пустой продукт, не содержащий файлов, но, тем не менее, отображающийся в "Панели управления":

Как видим, все подтверждает наши предпосылки: главным объектом является продукт, содержащий подсекции в виде пакетов, каталогов и опций. Иерархическая структура позволяет строить замысловатые и сложные структуры. Процесс компиляции заменяет содержательные тэги на более "техногенные", такие как section, reference, tuple или table. При просмотре обратите внимание на информацию о номерах строк исходного файла — это также позволяет производить отладку и поиск ошибок.

Вы можете откомпилировать и связать указанный файл с помощью команд (их вполне можно объединить в тривиальный BAT-файл):

>candle 1.wxs
>light 1.wixobj
>msiexec /i 1.msi

В результате вы запустите системный инсталлятор и установите новый фиктивный продукт. Зайдите в "Панель управления" и убедитесь, что у вас появилось новое приложение Test Package — удалите его на всякий случай (убедившись заодно, корректно ли отрабатывает эта операция).



Windows Installer XML: создание файлов инсталляции


Арсений Чеботарев,

Майкрософт преподнесла загадочный сюрприз — вынесла на суд общественности проект, снабженный лицензией Open Source (точнее, Common Public License). А чтоб выглядеть совсем уж по-свойски, исходники разместили на SourceForge. Посмотрим-посмотрим…

На самом деле это уже далеко не первый случай, когда "Майкрософт" засвечивается в сообществе Open Source. В памяти сразу же всплывает недавнее явление Services For UNIX. Но нас сейчас больше будет интересовать суть вопроса, то есть: что же такое XML-инсталлятор и как он работает.

WiX, Windows Installer XML — это набор инструментов для создания пакетов инсталляции Windows из XML-кода. Инсталляторы, как известно, служат для установки дистрибутива. А дистрибутив, как известно, состоит из объектов, таких как исполняемые файлы, ресурсы, библиотеки, ключи системного реестра, а также из интерактивных диалогов, с помощью которых пользователь может задать параметры инсталляции, вроде каталога приложения или состава устанавливаемых компонент.

Элемент новизны, или, по крайней мере, хорошая практика, заключается в том, что описание дистрибутива выглядит теперь как обычный XML-документ, в который легко можно вносить изменения. Создаваемый XML-файл должен удовлетворять требованиям WiX-схемы, которая, собственно, и есть основа открытого кода. Вторым компонентом является собственно построитель инсталляции, на входе которого — указанный XML-файл, плюс все файлы, входящие в дистрибутив, а на выходе — MSI, файл инсталляции сравнительно нового и, как говорят в "Майкрософт", окончательного формата.

Основным объектом верхнего уровня в терминах WiX является продукт — то есть одна инсталляция устанавливает один продукт. С продуктом связан уникальный идентификатор, который, как принято в MS Windows, представляет собой 128-битное число. Уникальность ключа продукта абсолютная, то есть ключ должен быть уникальным в масштабах всей Windows-вселенной. Такие глобально уникальные ключи сокращенно называют GUID’ами — Global Unique ID. Существует специальная утилита для их генерации, а также онлайн-сервис регистрации и резервирования ключей для гарантии уникальности последних.

Следующим (после продукта) уровнем детализации является пакет. Он может включать один или несколько файлов — обычно файлы инсталляции MSI, MSM (MS Merge Modules) и архивы CAB. Пакет тоже идентифицируется уникальным значением GUID.

Дополнительно весь продукт состоит из опций (features). Опции — это то, что видит пользователь при инсталляции и что он может выбрать (или не выбирать) для инсталляции.

Опции имеют иерархическую структуру: одни features включают другие и так далее. К примеру, при инсталляции Visual Studio вы можете выбрать установку компонент для создания программ на C++. Внутри этой опции вы можете выбрать установку статически и динамически связываемых библиотек, дополнительные средства отладки и так далее. Другой типичный пример опции — установка файлов помощи, help-файлов. При ограниченном объеме диска пользователь может предпочесть чтение help’а с лазерного диска.

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

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

Исторически для создания пакетов MSI использовался набор инструментов Windows Installer SDK. Это несколько утилит для компоновки инсталляции и специальный редактор Orca. С помощью этих средств можно задействовать все заложенные в MSI возможности, хотя использование штатных средств не настольно удобно, как хотелось бы. Более того, сторонние производители инсталляционного ПО, такого как InstallShield и Wise, тоже включили в свои продукты поддержку нового формата. Эти средства включают интерактивные помощники, конструкторы диалогов и другие инструменты, упрощающие процесс.

Казалось бы, проблема решена, но "Майкрософт" предлагает новый, обобщенный подход для тех же целей. В чем же проблема?

Проблема, по мнению компании, заключается в подходе к построению дистрибутивов. Все перечисленные средства являются интерактивными, то есть требуют выполнения пользователем операций для генерации результирующих файлов. Такой подход вполне подходит для небольших проектов, но не годится для поточного построения релизов. В первую очередь эта проблема коснулась самой "Майкрософт", где построение дистрибутивов — ежедневная, если не ежеминутная, операция. Особенный интерес к сборке "на лету" вызван возможностью динамической генерации дистрибутивов, как результата запроса пользователя через веб-интерфейс. Нелишним было бы и автоматизированное построение дистрибутивов в таких оболочках, как Visual Studio NET (что, кстати, уже реализовано с помощью нового мастера инсталляций).

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

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