использование xsd: any для расширяемой схемы - PullRequest
3 голосов
/ 03 февраля 2011

До сих пор я обрабатывал extensions , определяя элемент-заполнитель, который имеет атрибуты "name" и "value", как показано в примере ниже

<root>
   <typed-content>
      ...
   </typed-content>
   <extension name="var1" value="val1"/>
   <extension name="var2" value="val2"/>
....
</root>

Теперь я планирую перейти на использование xsd: any . Буду признателен, если вы поможете мне выбрать лучший подход

  1. Какова добавленная стоимость xsd: любая по сравнению с моим предыдущим подходом, если я укажу processContents = "strict"
  2. Может ли инструмент / библиотека EAI / ESB выполнять выражения XPATH для произвольных возвращаемых мной элементов
  3. Я вижу, что различные инструменты привязки обрабатывают это отдельно при создании кода привязки. Это тот же самый случай, если я включаю namespace = "http://mynamespace" и предоставляю схему для" http://mynamespace" во время генерации кода?
  4. Соответствует ли этот стандарт WS-I?
  5. Есть ли какие-то ошибки, которые мне не хватает?

Спасибо

Ответы [ 2 ]

2 голосов
/ 03 февраля 2011
  1. Использование <xsd:any processContents="strict"> дает людям возможность добавлять расширения к их экземплярам XML-документов без изменения исходной схемы . Это критическое преимущество, которое оно дает вам.
  2. Да. Инструменты, которые управляют экземплярами, не заботятся о том, как выглядит схема, это документы экземпляров, на которые они смотрят. Для них не имеет значения, используете ли вы <xsd:any> или нет.
  3. Инструменты для переплета обычно не очень элегантно обрабатывают <xsd:any>. Это понятно, поскольку у них нет информации о том, что оно может содержать, поэтому они обычно дают вам нетипизированный заполнитель. Это код приложения для обработки этого во время выполнения. JAXB особенно (RI, по крайней мере) делает из этого кулак, но это выполнимо.
  4. Да. Это очень хорошая практика XML-схемы, и все действующие XML-схемы поддерживаются WS-I
  5. <xsd:any> усложняет жизнь программиста из-за нетипизированной природы привязок, но если вам нужно поддерживать произвольные точки расширения, это способ сделать это. Однако, если ваши расширения четко определены и не меняются, это может не стоить фактора раздражения.
1 голос
/ 04 февраля 2011

Относительно пункта 3

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

Это соответствует аннотации @ XmlAnyElement в JAXB. Поведение выглядит следующим образом:

@ XmlAnyElement - Сохранить все как узлы DOM

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

@ XMLAnyElement (lax = true) - преобразовать известные элементы в доменные объекты

Устанавливая lax = true , если JAXB имеет корневой тип, соответствующий этому QName, тогда он преобразует этот чанк в объект домена.

...