nillable true что это

XSD элемент element

Элемент element определяет элемент.

Синтаксис элемента

Атрибуты элемента

Не обязательный. Препятствует использованию элемента, который имеет заданный тип наследования, вместо данного элемента. Может принимать значение #all или список из расширений/ограничений/замещений:

Не обязательный. Запрещает указанный метод наследования элемента. Может принимать значение #all или список из расширений/ограничений:

Пример использования

Пример №1
В следующем примере декларируется XML схема с четырьмя простыми элементами «fname», «lname», «age» и «dateborn»:

Пример №3
Следующий пример аналогичен примеру №2. Разница лишь в том, что для ссылки на имена элементов используется атрибут ref:

Источник

Журнал ВРМ World

Представление нулевых значений в схеме XML

Введение

Компонентная объектная модель для Java, известная как Java beans, имеет определенные свойства, называемые полями. Эти поля могут иметь нулевые значения, если только они не являются полями примитивного типа. При преобразовании («мэппировании») Java beans в XML эти поля становятся элементами или атрибутами. Простые элементы и атрибуты не могут иметь нулевых значений (их можно рассматривать как своего рода эквиваленты примитивным типам Java, которые также не могут иметь нулевых значений). Существует несколько способов изменить атрибуты и элементы XML таким образом, чтобы их экземпляры имели нулевое значение (или хотя бы логически были эквивалентны нулю):

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

Элементы и атрибуты

Листинг 1. Схема AttributeOrElement

В листинге 2 представлен экземпляр схемы листинга 1.

Листинг 2. Экземпляр AttributeOrElement

Ясно видно, что поле атрибута занимает меньше места в экземпляре, чем поле элемента. Соответственно, сообщения SOAP, которые переносят документы в формате XML, содержащие атрибуты, также будут меньше, что сократит время их передачи. Таким образом, кажется, что атрибуты оказываются предпочтительнее элементов. Но те специалисты, кто уже давно работает со схемами, могли заметить, что атрибуты используются не так уж часто. Возникает вопрос: почему? Автор затрудняется назвать точную причину, но приводит несколько аргументов:

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

Нулевой атрибут

Листинг 3. Схема TypeWithNullAttribute

Листинг 4. Экземпляры TypeWithNullAttribute

Атрибут со значением:

Атрибут, переданный как нулевой:

Нулевые элементы

Существует два способа представить нулевое значение, используя элементы: с помощью атрибутов nillable=»true» или minOccurs=»0″. В листинге 5 показана схема для оператора TypeWithNullElements, содержащая по одному элементу для каждого из стилей полей, которые могут иметь нулевое значение.

Листинг 5. Схема для TypeWithNullElements

Листинг 6. Экземпляры TypeWithNullElements

Элементы со значениями:

Элементы с нулевыми значениями:

Как и необязательный атрибут, элемент с атрибутом minOccurs=»0″, имеющий нулевое значение, просто отсутствует в экземпляре XML. Это способствует уменьшению размера сообщения, в отличие от того варианта, когда элемент определяется с помощью атрибута nillable=»true». Атрибут nillableElem, даже имея нулевое значение, включает поле для значения, которое показывает, что значение этого атрибута действительно равно нулю.

Когда атрибут nillable=»true» оказывается полезен

Листинг 7. Схема для элементов массива, значение которых может быть нулевым

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

Заключение

Источник

XML Schema nillable=”true” vs minOccurs=”0″

In a WSDL, XML Schema is the section where it define the message format for each operations, which eventually become the real API that users are interested. And it is the most tricky part of the WSDL. Nowadays there are many tools that you can design and use WSDLs without any needs in knowing the meaning of a single line of the WSDL. But there are situations that you may find it is better you have some knowledge in XML Schema section and in WSDL overall.
For this post I m taking a simple example of use of nillable=”true” and minOccurs=”0″. Take the following example.

Just ignore the meaning of what nillable and minOccurs attributes for now. You can safely say the following XML is valid for the above Schema.

Take the first element ‘nonboth’ in the schema, It has not any minOccurs or nillable attribute. By default minOccurs equal to 1 and nillable equal to false. That mean it can’t have nil value nor it can not be removed from the xml.

Is that making an element nil and removing the element from the XML is same? No. Take the second element in the schema ‘minzerostring’. There you have minOccurs =”0″ but there are no nillable=”true”, mean it is non-nillable. The idea is whenever you don’t want that element in your xml, you can’t have the element keeping empty like

But you can remove the whole element from the XML (since it is minOccurs=0).

Note that the correct way to declare the nil element is,

You can understand why when we look at the third element ‘nilstring’. Say you set message the following element

You can say that this is not nil, this is an empty string. In fact an empty string is nil in some other language, But if we take XML Schema as a language, then for someone to be nil, it have to have the xsi:nil attribute set to “true” or “1”.

So going back to the ‘minzero’ which is non-nillable, by theory you should be able to write the following xml,

Since you don’t have that xsi:nil=”1″ this is not a nil value, so the condition nillable=”false” condition is preserved. But unlike for string when you set an empty element for an integer, it doesn’t sound correct. So in practice whenever some schema says non-nillable you should set some valid value.

The last one is ‘minzeronil’ element which is both nillable=”true” and minOccurs=”0″. Whenever you don’t need to set a value for this element, you have the choice of either skipping the element or setting the value of the element to nil. It is obvious rather than setting a nil value it is better you just skip the element to make the XML shorter. This is really needed specially in web services where you need the payload to be minimum as much as possible.

Say you have to prepare the XML and you don’t have valid values for any of the element. So this can be the optimum XML you can create.

Источник

Справочник по схеме контрактов данных

В данном разделе описывается подмножество схемы XML (XSD), используемое DataContractSerializer для описания типов среды CLR, применяемых для сериализации XML.

DataContractSerializer сопоставляет типы CLR с XSD при экспорте метаданных из службы Windows Communication Foundation (WCF) с помощью конечной точки метаданных или средства служебной программы метаданных ServiceModel (Svcutil.exe). Дополнительные сведения см. в разделе сериализатор контрактов данных.

DataContractSerializer также сопоставляет типы XSD типам среды CLR, когда для доступа к документам WSDL или XSD и создания контрактов данных для служб или клиентов используется Svcutil.exe.

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

Уровни поддержки

DataContractSerializer обеспечивает следующие уровни поддержки для данной функции схемы XML:

Общие сведения

Пространство имен схемы описывается в разделе Схема XML. В этом документе используется префикс «xs».

Атрибуты с пространством имен, отличным от пространства имен схемы, игнорируются.

Любые заметки (за исключением описанных в данном документе) игнорируются.

: атрибуты

: содержимое

Сложные типы –

Общие сведения

Каждый сложный тип сопоставляется с контрактом данных.

: атрибуты

: содержимое

в сложном типе: атрибуты

в сложном типе: содержимое

Элементы –

Общие сведения

может использоваться в следующих случаях.

Он может использоваться в в качестве объявления глобального элемента.

с maxOccurs = 1 в (элементы данных)

с maxOccurs>1 в коллекции (коллекций)

В типах коллекции только один xs:element допустим в xs:sequence.

Коллекции могут быть следующих типов:

Обычные коллекции (например, массивы).

Коллекции-словари (сопоставляющие одно значение другому; например, Hashtable).

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

в объявлении глобального элемента

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

Экспорт схемы: связанные объявления глобальных элементов создаются для каждого создаваемого типа, как простого, так и сложного.

Десериализация/сериализация: связанные объявления глобальных элементов используются в качестве корневых элементов данного типа.

Импорт схемы: связанные объявления глобальных элементов не требуются и игнорируются, если они соответствуют следующим правилам (если только они не определяют типы).

: содержимое

* При использовании simpleType сопоставления и complexType, для анонимных типов такая же, как и для неанонимных типов, за исключением того, что нет анонимных контрактов данных, поэтому создается именованный контракт данных с созданным именем, производным от имени элемента. Ниже перечислены правила для анонимных типов.

Сведения о реализации WCF: Если xs:element имя не содержит точек, то анонимный тип сопоставляется внутреннему типу внешнего типа контракта данных. Если имя содержит точки, итоговый тип контракта данных является независимым (не внутренним типом).

Если контракт данных с таким именем уже существует, уникальное имя создается путем добавления «1», «2», «3» и т. д., пока не будет создано уникальное имя.

: атрибуты

: содержимое

Ограничения сложных типов поддерживаются только для base=» xs:anyType «.

: атрибуты

для всех остальных случаев: содержимое

Перечисление

для перечислений: атрибуты

для перечислений: содержимое

В следующем коде показан класс перечисления C#.

DataContractSerializer сопоставляет этот класс следующей схеме. Если значения перечисления начинаются с 1, блоки xs:annotation не создаются.

: атрибуты

: содержимое

В следующем коде показана установка флагов для типа перечисления.

Этот тип сопоставляется следующей схеме.

Наследование

Основные правила

Контракт данных не может наследовать от контракта данных коллекции.

В следующем коде показан пример контракта данных.

Этот контракт данных сопоставляется следующему объявлению типа схемы XML.

: атрибуты

: содержимое

в : атрибуты

в : содержимое

Если производный тип содержит элемент с тем же именем, что и элемент базового типа, дублирующееся объявление элемента сопоставляется члену данных с создаваемым уникальным именем. Положительные целые числа добавляются к имени члена данных («member1», «member2» и т. д.) до тех пор, пока не будет найдено уникальное имя. И наоборот:

Если производный контракт данных имеет член данных с тем же именем и типом, что и член данных в базовом контракте данных, DataContractSerializer создает соответствующий элемент в производном типе.

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

Сопоставление тип-примитив

DataContractSerializer использует следующие сопоставления для примитивных типов схемы XML.

Сопоставление типов ISerializable

Ниже приведен пример полного объявления схемы сериализации контракта данных.

Необходимо отметить следующее.

ser:char введен для представления символов Юникода типа Char.

valuespace«xs:duration сокращается до упорядоченного набора, чтобы можно было выполнить его сопоставление TimeSpan.

FactoryType используется в схемах, экспортируемых из типов, унаследованных от ISerializable.

Импорт схем, отличных от DataContract

Источник

XBRL: просто о сложном − Глава 6. Погружение в XBRL − Часть 5. Новые измерения

6.5. Новые измерения

В предыдущих разделах мы достигли значительных успехов в представлении отчетной формы из нашего примера в виде отчета XBRL, но полного соответствия так и не получили. Сегодня на одного из наших разработчиков снизошло озарение: А давайте попробуем применить XBRL Dimensions!

При взгляде на Главу 5 становится очевидно, что гендерные и возрастные группы могут быть представлены в виде измерений.

6.5.1. Базовые концепты

Факты о количестве сотрудников будут представлены в разрезе нескольких измерений с использованием разных подстановок (substitutions) nr_employees для разделения измерений (и презентаций).

6.5.2. Таксономия шаблонов (template taxonomy)

Элементы доменов и таксономия шаблонов объединены в общую схему таксономии. Таксономия шаблонов импортирует несколько других схем:

Схема xbrldi не используется в самой таксономии шаблонов, но используется в отчете, который в свою очередь ссылается на таксономию шаблонов. Чтобы максимально снизить зависимость отчета от модуля измерений, его импорт производится в таксономии шаблонов. Также, она ссылается на базовую таксономию, чтобы иметь связь с концептами.

6.5.3. Типизированное измерение

Как мы знаем, существуют два типа измерений – типизированные и явные. В этом разделе мы рассмотрим, как возрастные группы могут быть представлены в виде типизированного измерения.

Прежде всего, нам нужен элемент для определения типа для age_group. Мы будем использовать простой тип с перечислением допустимых значений:

6.5.4. Явное измерение

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

В базе ссылок мы используем роль и определяем локаторы концептов обычным образом.

Измерение имеет взаимосвязь dimension-domain со своим доменом. Элементы домена определяются взаимосвязями domain-member между локаторами концептов в базе ссылок определений.

6.5.5. Гиперкубы

Теперь, когда у нас есть базовая таксономия и таксономия элементов домена, мы можем объединить их гиперкубами в таксономии шаблонов.

Создаем связи между базовыми концептами, гиперкубами и измерениями.

Аналогично для возрастных групп:

Обратите внимание, что в ссылке должна использоваться роль, определенная в таксономии измерений – ageGroupDimension :

6.5.6. Презентации

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

6.5.7. Отчет

Теперь, когда наша таксономия измерений готова, мы можем сделать связанный с ней отчет. Сначала определим контексты для общего количества сотрудников на начало и конец отчетного периода.

Далее определим контексты для значений измерения возрастных групп.

Теперь определяем контексты для значений гендерного измерения.

Обратите внимание, что отчет ссылается на таксономию шаблонов, а не на базовую таксономию.

Теперь мы можем передавать факты, каждый в своём контексте.

6.5.8. Первый взгляд на новые измерения

Наше простое приложение для визуализации отчета не поддерживает измерения, поэтому отчет выглядит следующим образом:

После некоторых ручных корректировок – удаления неиспользуемых столбцов, упорядочивания остальных столбцов и добавления заголовков таблиц – мы можем взглянуть на несколько лучшую версию отчета, которую вы могли бы ожидать от приложения с поддержкой измерений:

Источник