2010-10-20 2 views
1

1) Я понимаю, что пространства имен являются средством дифференцирования между различными схемами/словарями, указанными с использованием XML-схемы, но я не понимаю, почему это хорошая идея, что пространство имен (для которых схема разрабатывает словарь) указывается в самой схеме (через атрибут targetNamespace).Xml Schema namespace

a) Не было бы лучше, если бы мы смогли связать конкретное пространство имен с определенным лексиконом/схемой внутри документов экземпляра? Таким образом, у тех, кто пишет документы экземпляра, была бы полная свобода связывать схему с любым именем пространства, которое они хотели бы!

b) Единственное преимущество, которое я вижу в схеме, указывающей целевое пространство имен, заключается в том, что ее создатели имеют возможность помещать документ в конец пространства имен, который может описывать элементы этого пространства имен (при условии, что схема использует URL-адрес для пространства имен) , Существуют ли другие преимущества?

2) Если схема не имеет targetNamespace, вы должны ссылаться (в пределах экземпляра документа) к конкретной схеме, используя атрибут noNamespaceSchemaLocation вместо schemaLocation атрибута.

Не было бы проще, если бы экземпляр экземпляра документа просто указывал местоположение схемы и позволял валидатору XML Schema выяснить, указывает ли схема targetNamespace?

спасибо

+1

Термин «схема XML» относится только к языку описания схемы. Отдельные схемы просто называются «схемой» или «схемой». –

ответ

1

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

В этом процессе атрибут «schemaLocation» - это всего лишь подсказка, и много раз вообще не полезен.

Рассмотрим следующий сценарий:

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

В этом случае вы можете сказать: «Пусть приложение поддерживает отображение из пространства имен в схему, все еще нет причины, чтобы пространство имен указывалось внутри самой схемы»; к сожалению, это приводит к проблемам, когда схема смешивает несколько пространств имен с импортом. В зависимости от выбранного вами XML-файла вы должны создать столкновение имен в схеме.

Надеюсь, что это имеет смысл.

+0

"• Процессор использует пространство имен элементов в файле XML для поиска схемы в кеше схемы в памяти. В этом случае вы можете сказать: «пусть приложение поддерживает сопоставление из пространства имен в схему, все еще нет причин для того, чтобы пространство имен было указано внутри самой схемы»; «Я предполагаю, что реализация, описанная в а), была бы идеальна для такого сценария , предполагая, что мы смогли сообщить процессору во время выполнения, которому Xml-схема должна отображать пространство имен элементов? – user437291

+0

«к сожалению, это приводит к проблемам, когда схема смешивает несколько пространств имен с импортом. В зависимости от выбранного вами XML-файла вы должны создать столкновение имен в схеме. Я предполагаю, что проблема может быть решена даже при использовании реализации, описанной в а)? – user437291

2

Я знаю только одно определение XML Namespaces и одно определение определения XML-схемы также на http://www.w3.org. Поскольку XML Schema очень сложна, он решил стандарт в трех частях XML Schema Part 0: Primer Second Edition, XML Schema Part 1: Structures Second Edition и XML Schema Part 2: Datatypes Second Edition.

Если вы знаете больше определений пространств имен XML и схемы XML (более «словари»), пожалуйста, разместите ссылку на определение, которое вы имеете в виду.

Смысл targetNamespace в корне любой схемы очень прост для очистки.XML не является языком. Это метаязык. XML-схема помогает нам определить один язык. Мы должны дать уникальное имя для языка (схемы), который мы определяем. Это targetNamespace схемы. Таким образом, какой-то документ должен интерпретироваться как документ, написанный на английском языке на английском языке, он может быть не совсем корректным на английском языке.

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

Если вы определяете схему без targetNamespace, означает, что соответствующие элементы и атрибуты из документа XML также должны относиться к «без пространства имен». Использование атрибута noNamespaceSchemaLocation или schemaLocation - не обязательно. Таким образом, вы, , не должны ссылаться на схему в документе XML. В случае, если читатель XML-документа должен знать из соответствующего контекста, какую схему вы имеете в виду.

В конце вашего вопроса вы спрашиваете

Не было бы проще, если бы вместо того, чтобы экземпляра документа будет просто указать местоположение XML-схему и пусть Xml Schema валидатор фигуры из ли а не schema указывает targetNamespace?

Но значение атрибута noNamespaceSchemaLocation - это точно путь к файлу XSD, который определяет используемую схему. Значение атрибута schemaLocation - это пространство имен и путь к файлу XSD, разделенный пробелом. Поэтому атрибуты уже делают то, что вы предлагаете.

1

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

Наиболее часто используемой схемой является http://www.w3.org/2001/XMLSchema, которая определяет встроенные типы, такие как xs:int и xs:string. SAML Assertion например, повторное использование http://www.w3.org/2000/09/xmldsig# и http://www.w3.org/2001/04/xmlenc#.

Было бы очень сложно, если бы каждый экземпляр документов определял xs:int в разных пространствах имен. Префикс типа xs может быть указан всем экземпляром, поэтому вы можете называть его foo:int, если хотите. Но валидатор должен знать, что в конечном итоге он разрешается до {http://www.w3.org/2001/XMLSchema}int.

+0

«Преимущество отдельной схемы (или« словарного запаса »в ваших словах), указывающее целевое пространство имен, заключается в том, что оно позволяет схемам повторно использовать схемы из других пространств имен». «Но валидатор должен знать, что в конечном итоге он разрешает {http://www.w3.org/2001/XMLSchema}int. " Но не могли ли быть достигнуты обе цели, даже если Xml namespaces и Xml Schemas были связаны с тем, как я описал это в a)? – user437291