Управление версиями
Если требуется новая версия языка, и она обратно совместима с более старым языком, разработчик схем должен принять решение об имени пространства имен для имен в новом языке. В этом случае имеется два варианта: создать новое имя пространства имен или воспользоваться существующим. По нашему мнению, повторное использование более результативно, но мы рассмотрим и выбор №1 в разделе "новое пространство имен". Правило для повторного использования пространств имен может быть сформулировано следующим образом:
| 8. Правило "Повторного использования имен пространств имен": если в спецификацию могут быть внесены изменения, обеспечивающие обратную совместимость, НЕОБХОДИМО использовать старое имя пространства имен вместе с моделью расширения XML. |
Отсюда можно сделать важный вывод о том, что новое имя пространств имен необходимо только тогда, когда внесено несовместимое изменение.
| 9. Правило "Повторного использования пространств имен": новое имя пространства имен используется, если обратная совместимость недопустима, то есть программное обеспечение ОБЯЗАНО приостановиться, если оно не понимает новые конструкции языка. |
Изменения, не поддерживающие обратную совместимость, обычно возникают в следующих двух ситуациях: при добавлении требуемой информационной единицы или изменении семантики существующей информационной единицы.
Приведенное выше правило требует соблюдения правил "Обязательно игнорировать" и "Любое пространство имен". Если требования этих правил не выполнены, разработчик языка оказывается лишенным возможности вносить совместимые изменения и повторно использовать имя пространства имен.
Выше отмечалось, что повторное использование имен пространств имен для совместимых расширений - хорошая практика. Противоположенный подход состоит в том, что владелец пространства имен мог бы использовать новое имя для совместимых изменений, предоставив точки расширяемости, допускающие другие пространства имен - xs:any namespace="##other". Этот подход проблематичен - расширение в другом пространстве имен означает, что комбинированная схема не может быть проверена полностью. Точнее, невозможно создать новую схему, которая ограничивает групповой символ. Предположим, например, что ns1 содержит foo и bar. В этом случае просто используя ограничения XML-схемы W3C, невозможно взяв схему SOAP - пример схемы с групповым символом - потребовать, чтобы элемент ns1:foo был бы потомком элемента заголовка, а ns1:bar не был бы потомком элемента заголовка. Действительно, потребность в такой возможности "взывает" к функциональности WSDL (Web Services Description Language, язык описания Web сервисов). Применение подхода с новым именем пространства имен имеет своим результатом спецификации и пространства имен, которые расчленены неподходящим образом, поскольку связанные конструкции оказываются в различных пространствах имен. Далее, повторное использование одного и того же пространства имен гарантирует лучшую инструментальную поддержку. Многие приложения используют одну схему для создания эквивалентных программных конструкций. Эти инструменты часто работают наилучшим образом с поддержкой одиночного пространства имен для "обобщенных" конструкций. Повторное использование имени пространства имен разрешает по крайней мере автору пространства имен вносить изменения в пространства имен и выполнять проверку допустимости расширений.
