ГОСТ Р ИСО 21090—2016
TS.NPFIT.NHS_NUMBER
ED.AU.KESTRAL.DOCUMENT
Атрибут тонкости идентификатора пациента (NHS Number
flavor, фиксированный корень имени), опубликованный в доку
ментации по программе NPFIT в Великобритании.
Правила формата документов, допустимого для австралий
ской фирмы Kestral.
Для атрибутов тонкостей типов данных, определенных в настоящем стандарте, пространство
имен указывать не требуется.
Приложения не должны отвергать экземпляр типа данных на том основании, что в атрибуте
flavorld указан идентификатор атрибута тонкости, неизвестный приложению. Приложения могут отвер
гать экземпляр типа данных, который ссылается на атрибут тонкости, не относящийся к этому типу, но не
обязаны это делать.
Атрибуты тонкости, определенные в настоящем стандарте, не обязаны быть реализованными
элементами обработки информации, объявляющими непосредственное или косвенное соответствие
настоящему стандарту, и использоваться в соответствии с этими элементами.
6.7.7 Примеры
Для большинства типов данных приведены примеры, предназначенные для иллюстрации различ
ных аспектов, связанных с использование этих типов.
Все примеры приведены в виде XML-фрагментов в соответствии с формой, документированной
в приложении А. Примеры составлены в предположении, что содержащий их документ или элемент
XML использует набор символов UTF-8. Для явного указания типа данных в большинстве примеров
использована спецификация типа xs»:type. но это не требуется, если тип данных полностью определен
контекстом использования или XML-схемой.
При обсуждении примеров могут даваться ссылки на содержание, опубликованное не ИСО или
HL7. а другими разработчиками стандартов. Это содержание не является нормативной частью настоя
щего стандарта.
7 Типы данных
7.1 Общие свойства
7.1.1 Неизменность
Эти типы данных концептуально неизменны. Для типов данных не вводится понятие жизненного
цикла, у них нет операций, позволяющих изменить существующий тип данных. Однако в настоящем
стандарте типы данных определены как классы с атрибутами, что позволяет значению типа данных
изменяться после его создания.
Хотя это может оказаться полезны для реализации, в намерение разработчиков настоящего стан
дарта не входило определение типов данных, допускающих изменение семантики. В спецификациях,
использующих типы данных, определенные в настоящем стандарте, следует исходить из постулата не
изменности типов данных. В частности, разработчики должны усердно предотвращать эффекты совме
щения имен, которые могут возникать в случаях, когда свойствам типа данных разрешается изменяться
после того, как этот тип данных введен в действие.
7.1.2 Равенство
Существуют два аспекта равенства, а именно: «являются ли эти два значения данных одним и тем
же экземпляром?» и «представляют ли эти два значения данных одно и то же семантическое понятие?».
Для отражения этих двух аспектов равенства в языках UML/OCL использовано два свойства. Пер
вое обозначается как «=» и означает, что эти два значения являются одним и тем же экземпляром, а
второе обозначается «equals» и означает, что эти типы представляют одно и то же понятие. Для при
митивных типов данных языка OCL. например integer, эти два свойства имеют одно и то же значение.
Для классов языка UML значения этих свойств могут различаться.
В настоящем стандарте для каждого типа данных приведены критерии равенства. Они определя
ют вторую форму равенства, а именно представляют ли эти два значения данных одно и то же понятие?
Эти определения равенства тщательно сконструированы, чтобы удовлетворять критерию, согласно ко
торому операция равенства должна быть рефлексивной, симметричной и транзитивной:
рефлексивность: «х equals х» должно быть истинно;
симметричность: если «х equals у» истинно, то «у equals х» должно быть истинно;
транзитивность: если «х equals у» истинно и «у equals
2
» истинно, то «х equals
2
» должно быть
истинно.
13