Зачем нам нужно targetNamespace?

Question

Я хотел бы понять цель targetNamespace как использованную как в XML-схеме, так и в WSDL. На самом деле, чтобы все было просто, давайте ограничимся этим вопросом XML-схемой.

Мне кажется, что я полностью понимаю понятие (простых) пространств имен XML. По соглашению мы используем URI/URL, но мы можем использовать любую строку, которую затем назначаем префикс для повторного использования узлами и атрибутами XML или просто используем пространство имен по умолчанию для области действия. Все идет нормально ?

Теперь вводится XML-схема. По каким-то причинам изобретатели XML Schema считали, что понятия простых пространств имен недостаточно, и им нужно было ввести targetNamespace. Мой вопрос: какое существенное преимущество представляет собой представление targetNamespace, которое не может быть обеспечено обычным пространством имен XML? Если XML-документ ссылается на документ xsd, либо с помощью schemaLocation, либо с помощью оператора import, в любом случае я даю путь к фактическому документу xsd, на который ссылаются. Это то, что однозначно определяет схему, на которую я хочу ссылаться. Если, кроме того, я хочу привязать эту схему к определенному пространству имен в моем справочном документе, почему я должен быть обязан реплицировать точное целевое пространство имен, уже определенное в XML-схеме, на которую я ссылаюсь? Почему я не могу просто переопределить это пространство имен, но я хочу, чтобы в документе XML, в котором это пространство имен будет использоваться для ссылки на этот конкретный документ XML-схемы, который я хочу ссылаться?

Update:

Для примера, если у меня есть следующие в экземпляре документа XML:

<p:Person 
    xmlns:p="http://contoso.com/People" 
    xmlns:v="http://contoso.com/Vehicles" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation= 
    "http://contoso.com/schemas/Vehicles 
    http://contoso.com/schemas/vehicles.xsd 
    http://contoso.com/schemas/People 
    http://contoso.com/schemas/people.xsd"> 
    <name>John</name> 
    <age>28</age> 
    <height>59</height> 
    <v:Vehicle> 
     <color>Red</color> 
     <wheels>4</wheels> 
     <seats>2</seats> 
    </v:Vehicle> 
</p:Person> 

Почему, например, в схеме people.xsd необходимо определить целевое пространство имен, которое «http://contoso.com/schemas/People»? Зачем нам вообще нужно определение targetNamespace в документе xsd? Мне кажется, что все, что вам нужно получить из части пространства имен схемы, уже содержится в документе экземпляра XML. В чем преимущество обеспечения существования целевого пространства имен с равным значением в документе xsd?

Последующая деятельность вопрос ответ Павла:

Можете ли вы дать мне конкретный пример, когда такие «столкновения» между именами элементов XSD становится очевидным, и что бы объяснить необходимость TargetNamespace?

---

Хорошо, вот попытка ответить на мой вопрос. Дайте мне знать, если это кажется вам последовательным. Глядя на примеры на странице, связанной с Павлом, помог мне.

Если мы возьмем пример экземпляра XML в исходном вопросе выше, мы имеем две ссылки на определение элемента транспортного средства. Один из них является явным и видимым в самом документе экземпляра XML, но мы также должны представить, что XML-схема person.xsd ссылается на одно и то же определение транспортного средства как на разрешенный дочерний элемент человека. Если бы мы использовали обычные пространства имен, где каждому документу было разрешено определять собственное пространство имен для транспортного средства, как мы узнаем, что экземпляр XML ссылается на одно и то же определение схемы XML для транспортного средства, как и на man.xsd? Единственный способ - это создать концепцию пространства имен, которое является более строгим, чем первоначальное простое, и которое должно быть написано точно так же в нескольких документах.

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

Представьте, что у нас есть два разных определения схемы XML для элемента транспортного средства. LOCATION1/транспортных средств.xsd будет содержать определение, подтверждающее пример из вопроса об этом сообщении (содержащем цвет, колеса и элементы детского элемента), тогда как location2/vehicles.xsd будет содержать совершенно другое определение для элемента транспортного средства (например, с дочерними элементами год, модель и объем). Теперь, если документ экземпляра XML ссылается на схему location1, как это имеет место в примере выше, но person.xsd говорит, что элемент person может содержать дочерний элемент транспортного средства типа, определенного в схеме Location2, а затем без понятия объекта targetNamespace, экземпляр XML будет проверять, даже несмотря на то, что он явно не имеет подходящего типа транспортного средства в качестве дочернего элемента его персонального элемента.

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

В этом смысл?

Answer 1

Q: «По соглашению мы используем URI/URL,, но мы могли бы использовать любую строку, которая мы затем присвоить префикс для повторного использования узлов XML и атрибутов, или использовать просто как пространство имен по умолчанию для под рукой ".

A: Да, точно.

Q: «По какой-то причине авторы схемы XML считают, что понятие простых пространств имен не было достаточно, и они должны были ввести TargetNamespace.»

A: http://www.liquid-technologies.com/Tutorials/XmlSchemas/XsdTutorial_04.aspx

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

...

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

Разъяснение:

• Основная цель XML-схем является объявить "словарный запас".

• Эти словари могут быть идентифицированы пространством имен, указанным в атрибуте targetNamespace.

• Схема (документ XML) может иметь «пространство имен». «Словарь», который описывает документ, может иметь «targetNamespace».

• Так же, как XML-схемы обеспечивают более высокий уровень абстракции, чем SGML DTD (оригинальные архитекторы XML-DTD были достаточными), XML-схема «targetNamespaces» обеспечивает уровень абстракции над «простыми пространствами имен».

«Надежда, что помогает

Answer 2

Это не для меня ясно, что именно вы просите. Очевидно, что схема может содержать определения компонентов во многих разных пространствах имен, и должен быть некоторый способ сказать: «Это объявление элемента E в пространстве имен N». Дизайнеры XSD решили разработать язык так, чтобы все объявления в одном документе схемы принадлежали одному пространству имен, называемому целевым пространством имен модуля. Его можно было бы упаковать по-разному, но разница была бы очень поверхностной. Что, по вашему мнению, неверно с решением о выравнивании модулей с пространствами имен?

Answer 3

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

• В документе экземпляра, можно использовать XML-пространства имен для идентификации имен, что элемент или атрибут находится.
• В документе схемы, вы объявляете элементы и атрибуты, которые будут появляться в тех случаях. Какое пространство имен указано в них? Для этого используется targetNamespace.
• Расположение документа схемы и пространство имен - это не одно и то же. Обычно имеется несколько документов .xsd с одним и тем же целевым пространством имен. (Они могут включать или не включать друг друга, но обычно будут включать друг друга.)
• Документы экземпляра не всегда имеют элемент xsi: schemaLocation, чтобы сообщать парсерам, где найти схемы. Различные методы могут использоваться для указания парсеру, где можно найти соответствующие документы схемы. XSD может быть размещен на локальном диске или на каком-либо веб-адресе, и это не должно влиять на пространство имен элементов в нем.
  • xsi: schemaLocation - это подсказка. Parsers могут найти схему для данного пространства имен в другом месте, что подразумевает, что они должны быть в состоянии знать, для чего принадлежит пространство имен, для которого предназначена схема.
  • Инструменты, такие как инструменты привязки данных, предварительно скомпилируют схемы и создают код, который распознает действительные документы. Они должны иметь возможность знать пространства имен объявленных элементов.

Я думаю, что вы предполагая, что экземпляр документа может указать пространство имен элементов и атрибутов, объявленных в какой-то схемы документа, используя XSI: SchemaLocation. Это не работает. Во-первых, синтаксический анализатор может найти другие документы схемы, кроме перечисленных, и должен знать, для какого пространства имен они предназначены. С другой стороны, это затрудняло бы или затрудняло бы рассуждения о схемах: вы не смогли бы взглянуть на схему и знать пространства имен, в которых все принадлежало, потому что это решение будет отложено до тех пор, пока не будет написан экземпляр.

Answer 4

Я думаю, что это помогает одновременно посмотреть как документ экземпляра, так и документ схемы, чтобы понять, что делает targetNamespace. Рассмотрим это (на основании вашего экземпляра документа):

<p:Person 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xmlns:p="http://localhost:8080/scribble/xml/Person" 
     xmlns:v="http://localhost:8080/scribble/xml/Vehicle" 
     xsi:schemaLocation=" 
      http://localhost:8080/scribble/xml/Person 
      http://localhost:8080/scribble/xml/person.xsd"> 
    <name>John</name> 
    <age>28</age> 
    <height>59</height> 
    <v:Vehicle> 
     <color>Red</color> 
     <wheels>4</wheels> 
     <seats>2</seats> 
    </v:Vehicle> 
</p:Person> 

Там нет пространства имен по умолчанию не указано в документе, но р * и v * являются псевдонимами к определенным NS URI.Теперь посмотрим на саму схему документа:

<?xml version="1.0" encoding="UTF-8"?> 
<schema 
    xmlns="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://localhost:8080/scribble/xml/Person" 
    elementFormDefault="qualified" 
    xmlns:v="http://localhost:8080/scribble/xml/Vehicle"> 

    <import 
     namespace="http://localhost:8080/scribble/xml/Vehicle" 
     schemaLocation="http://localhost:8080/scribble/xml/v.xsd"/> 

    <element name="Person"> 
     <complexType> 
      <sequence> 
       <element name="name" form="unqualified" type="NCName"/> 
       <element name="age" form="unqualified" type="integer"/> 
       <element name="height" form="unqualified" type="integer"/> 
       <element ref="v:Vehicle"/> 
      </sequence> 
     </complexType> 
    </element> 

</schema> 

и

<?xml version="1.0" encoding="UTF-8"?> 
<schema 
    xmlns="http://www.w3.org/2001/XMLSchema" 
    targetNamespace="http://localhost:8080/scribble/xml/Vehicle" 
    elementFormDefault="qualified"> 

    <element name="Vehicle"> 
     <complexType> 
      <sequence> 
       <element name="color" form="unqualified" type="NCName"/> 
       <element name="wheels" form="unqualified" type="integer"/> 
       <element name="seats" form="unqualified" type="integer"/> 
      </sequence> 
     </complexType> 
    </element> 
</schema> 

Если вы посмотрите на атрибуты на тегах, пространство имен по умолчанию является «http://www.w3.org/2001/XMLSchema» как для схемы документы ... но targetNamespace - это тот, который используется в качестве псевдонимого пространства имен в документе экземпляра.

targetNamespace - это ожидаемое пространство имен экземпляров, независимо от пространства имен документов схемы и любого другого пространства имен, указанного в документе экземпляра.

Я нахожу, что полезно подумать об этом, например, провести вечеринку, где у вас есть список гостей и гостей, носящих теги имен. Подумайте о targetNamespace в документах схемы, таких как имена в гостевом списке. Xmlns, aliased или нет, в документах экземпляра похожи на теги имен для гостей. До тех пор, пока у вас есть список гостей (который чудесным образом включает в себя ксерокопию удостоверения личности, выданного государством), всякий раз, когда вы сталкиваетесь с кем-то, вы можете подтвердить свою личность. Если вы сталкиваетесь с кем-то, носящим тег имени, который не соответствует указанным параметрам, вы можете выдохнуться (то есть выбросить ошибку).

со схемой/экземпляров, у вас есть:

Schemas:

targetNamespace="http://localhost:8080/scribble/xml/Person" 
targetNamespace="http://localhost:8080/scribble/xml/Vehicle" 

Instance:

xmlns:p="http://localhost:8080/scribble/xml/Person" 
xmlns:v="http://localhost:8080/scribble/xml/Vehicle" 

Или ... любой гость по прозвищу "v", что вы столкнулись в любом месте сторона (запрещающая специальные правила, которые говорят иначе), любой этаж дома или на заднем дворе или в бассейне, лучше соответствует описанию для гостя в списке гостей по имени http://localhost:8080/scribble/xml/Vehicle. или они являются злоумышленниками.

Эти специальные правила могут говорить что-то вроде, V может только болтаться, если они сразу рядом с P, или P может только болтаться, если V присутствует. В этом случае P должен зависать, когда V есть, но V может идти почти везде, где они хотят, не будучи там.

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