nillable true что значит
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. Первый взгляд на новые измерения
Наше простое приложение для визуализации отчета не поддерживает измерения, поэтому отчет выглядит следующим образом:
После некоторых ручных корректировок – удаления неиспользуемых столбцов, упорядочивания остальных столбцов и добавления заголовков таблиц – мы можем взглянуть на несколько лучшую версию отчета, которую вы могли бы ожидать от приложения с поддержкой измерений:
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.
Журнал ВРМ 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 для элементов массива, значение которых может быть нулевым
Заключение
Почему он называется nillable?
ОТВЕТЫ
Ответ 1
Что мне интересно, почему nil был выбран, а не более распространенным (в информатике) null
Это зависит от того, из какой части компьютерной науки вы пришли!
Ответ 2
Nil имеет те же корни языка, что и null. Нил происходит от латыни для нихиля, что означает «ничего». «Null», в то время как связано, происходит от латыни для «none» (буквально «ne», «не» и «ullus» означает «что-либо» ). Хотя они похожи по смыслу, они имеют несколько незначительные различия.
В практическом использовании «нуль» является гораздо более распространенным, а «ноль» чаще встречается в Европе. Большинство людей, как правило, используют их взаимозаменяемо в терминах разработки программного обеспечения, но, по моему опыту, использование языка «ноль» более распространено.
Ответ 3
Он исходит из nil, который является другим термином для null, используемым в XML. Я не думаю, что есть какая-то конкретная причина, которая предпочтительнее других в разных языках программирования. Это просто выражение. Он также используется в некоторых видах спорта, чтобы выразить 0. http://en.wikipedia.org/wiki/Nil
Ответ 4
Если память обслуживается, она называется «nillable», потому что (некоторые из) людей SQL в комнате стали беспокоиться о возможной путанице между соответствующей концепцией в XSD и соответствующей концепцией в SQL. Они угрожали лечь на дорогу, чтобы остановить предложение, если имя не было изменено. Таким образом, WG изменила название.
(По ортографическому вопросу я думаю, что nilable пригласит произношение с длинным «i», я считаю, что и американский, и британский английский регулярно удваивают окончательные одиночные согласные после короткой подчеркнутой гласной. Cf. ‘tag’, ‘tagging’, ‘tagged’, ‘taggable’.)
Ответ 5
Этот термин используется XML WSDL. Если nillable true, мы также можем использовать значение null в параметре. Я использовал это, и это сработало для меня.
XSD элемент element
Элемент element определяет элемент.
Синтаксис элемента
Атрибуты элемента
Атрибут | Описание |
---|---|
id | Не обязательный. Определяет уникальный идентификатор для элемента |
name | Не обязательный. Определяет имя элемента. Этот атрибут требуется, если родительским элементом является элемент schema |
ref | Не обязательный. Ссылается на имя другого элемента. Атрибут ref может включать префикс пространства имен. Этот атрибут нельзя использовать, если родительским элементом является элемент schema |
type | Не обязательный. Определяет либо имя встроенного типа данных, либо имя элемента simpleType или complexType |
substitutionGroup | Не обязательный. Определяет имя элемента, который может быть замещен этим элементом. Этот атрибут нельзя использовать, если родительским элементом является не элемент schema |
default | Не обязательный. Определяет значение элемента по умолчанию (может использоваться только если содержимое элемента простого типа или текст) |
fixed | Не обязательный. Определяет фиксированное значение элемента (может использоваться только если содержимое элемента простого типа или текст) |
form | Не обязательный. Определяет форму элемента. Значение «qualified» указывает на то, что этот элемент должен уточняться префиксом пространства имен. Значение «unqualified» указывает на то, что этот элемент не требует уточнения префиксом пространства имен. Значением по умолчанию является значение атрибута elementFormDefault атрибута элемента schema. Этот атрибут нельзя использовать, если родительским элементом является элемент schema |
maxOccurs | Не обязательный. Определяет, сколько раз максимально может появляться элемент в родительском элементе. Значением может быть любое целое число >= 0, если же нужно снять лимит на использование, то следует указать ключевое слово «unbounded». Значение по умолчанию 1. Этот атрибут нельзя использовать, если родительским элементом является элемент schema |
minOccurs | Не обязательный. Определяет, сколько раз минимально может появляться элемент в родительском элементе. Значением может быть любое целое число >= 0. Значение по умолчанию 1. Этот атрибут нельзя использовать, если родительским элементом является элемент schema |
nillable | Не обязательный. Определяет, можно ли элементу присваивать явное нулевое значение nil. Значение true позволяет элементу устанавливать атрибут nil в значение true. Атрибут nil определен как часть пространства имен XML схемы. Значение по умолчанию false |
abstract | Не обязательный. Определяет, можно ли использовать этот элемент в документе. Значение true определяет, что элемент не может использоваться в документе. Вместо этого, на месте данного элемента должен появляться другой элемент, атрибут substitutionGroup которого содержит имя с префиксом (QName) этого элемента. Значение по умолчанию false |
block |