Понимание расширений
В идеале отправители должны уметь расширять существующие 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. Правило "Обязательно игнорировать все": правило "Обязательно игнорировать" применяется к нераспознанным элементам и их потомкам. |
Возможно, что для словарей, ориентированных на документы, необходимо другое правило, поскольку приложение обычно пытается представить содержание неизвестного элемента. Ниже приведено правило для приложений, ориентированных на документы:
| 7. Правило "Обязательно игнорировать контейнер": правило "Обязательно игнорировать" применяется только к нераспознанным элементам. |
Вместо игнорирования нераспознанных элементов язык может обеспечить иную модель для обработки расширений. Такая модель может заключаться в том, что получатель генерирует ошибку, если он обнаруживает компонент, который не понимает. В качестве примера можно привести спецификацию безопасности, согласно которой получатель должен понимать любое расширение. Для этого случая характерен существенный недостаток, поскольку внесение совместимых изменений в язык не допускается, а такие изменения не могут быть проигнорированы. Еще одна модель - это модель нейтрализация неисправности (fallback), в которой в случае, если получатель не понимает расширения, предлагается альтернативные элементы. XSLT 2.0 обеспечивает такую модель.
