Существует ли (практически) 1: 1 соответствие между схемой XML и пространством имен XML?

Question

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

Хотя технически возможно создать схему XML без связанного пространства имен, разве не так, что почти каждая схема XML имеет свое уникальное целевое пространство имен?

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

Дополнительный вопрос: Если бы вы версировали свою XML-схему (и ее URI), вы бы сделали версию URI пространства имен?1007 *

Answer 1

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

Возможно, вы даже захотите определить схему для определенного подмножества пространства имен.

Например, когда я пишу CMS, которая позволяет использовать только подмножество HTML (по соображениям безопасности, например, без тегов <script>), один из способов - указать схему new для пространства имен HTML, и проверьте любой ввод по этой схеме «безопасного подмножества HTML». После этого, хотя это все еще фрагмент HTML, он не должен содержать тегов <script>, поскольку они не разрешены схемой.

Answer 2

Этот ответ в первую очередь относится к последующему вопросу.

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

Например, допустим, вы хотите предоставить сервис, структура входящего сообщения которого определяется как submitStuff-v1-0.xsd. Первоначально он может иметь целевой URI пространства имен (скажем):

http://www.example.org/services/submitStuff/1

В какой-то момент после выпуска v1.0 мы вводим неразрывное изменение (например, добавление необязательного элемента). Это приведет к выпуску submitStuff-v1-1.xsd, но URI пространства имен останется как:

http://www.example.org/services/submitStuff/1

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

Если позднее будет введено критическое изменение (например, введение нового обязательного элемента), у нас будет submitStuff-v2-0.xsd с новым пространством имен:

http://www.example.org/services/submitStuff/2

Клиенты службы смогут затем явно указать во входящем сообщении, пытаются ли они отправить v1.x- или v2.x-совместимый запрос.

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

• Файлировщик попытался отправить сообщение v2.x, но пропустил обязательный элемент, и в этом случае должно быть возвращено сообщение об ошибке.
• Файлер действительно отправил сообщение v1.x, поскольку его система еще не была обновлена ​​для создания сообщений v2.x, и в этом случае ошибка не должна возвращаться.

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

Answer 3

Схема может описывать более одного пространства имен. Он должен быть построен из нескольких документов схемы (используя xs: import), но все равно будет одной схемой.

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

Так что на самом деле это не отношения 1: 1.