ГОСТ Р 55343-2012/ISO/TS 13584-35:2010. Национальный стандарт Российской Федерации. Системы промышленной автоматизации и интеграция. Библиотека деталей. Часть 35. Ресурсы практической реализации. Интерфейс электронных таблиц библиотеки деталей

(утв. и введен в действие Приказом Росстандарта от 29.11.2012 № 1703-ст)

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2012 г. № 1703-ст

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ

БИБЛИОТЕКА ДЕТАЛЕЙ

ЧАСТЬ 35

ISO/TS 13584-35:2010 Industrial automation systems and integration — Parts library — Part 35: Implementation resources: Spreadsheet interface for parts library (IDT)

ГОСТ Р 55343-2012/ISO/TS 13584-35:2010

Группа Т58

ОКС 25.040.40

Дата введения 1 января 2014 года

Предисловие

1 ПОДГОТОВЛЕН АНО «Международная академия менеджмента и качества бизнеса» на основе собственного аутентичного перевода на русский язык международного документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2012 г. № 1703-ст

4 Настоящий стандарт идентичен международному документу ИСО/ТС 13584-35:2010 «Системы промышленной автоматизации и интеграция. Библиотека деталей. Часть 35. Ресурсы практической реализации. Интерфейс электронных таблиц библиотеки деталей» (ISO/TS 13584-35:2010 «Industrial automation systems and integration — Parts library — Part 35: Implementation resources: Spreadsheet interface for parts library»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА 5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

Введение

Комплекс стандартов ИСО 13584 разработан с целью компьютерного представления данных, содержащихся в библиотеке деталей, а также для обмена этими данными. Целью стандарта является предоставление объективного способа, обеспечивающего передачу данных о деталях библиотек и не зависящего от любого назначения системы, в которой эти данные будут использоваться. Благодаря характеру используемого описания оно удобно не только для обмена файлами, содержащими детали, но и в качестве основы для реализации и совместного использования баз данных для элементов библиотеки деталей.

Комплекс стандартов ИСО 13584 выполнен в виде частей, каждая из которых публикуется отдельно. Части комплекса стандартов ИСО 13584 попадают в одну из следующих частей: концептуальные описания, ресурсы программной реализации, методология описаний, проверка на соответствие, протокол просмотра и обмена данными, стандартизованное содержание. Эти части описаны в стандарте ИСО 13584-1. Настоящий стандарт 13584 является одной из частей, посвященных методологии описаний.

Комплекс стандартов ИСО 13584 имеет общее название «Системы промышленной автоматизации и интеграции. Библиотека деталей» и включает следующие части:

• часть 101. Протокол обмена и просмотра данных. Геометрический протокол обмена и просмотра данных с помощью параметрической программы;
• часть 102. Протокол обмена и просмотра данных. Протокол обмена и просмотра данных на основе спецификации соответствия ИСО 10303.

Структура комплекса стандартов ИСО 13584 представлена в ИСО 13584-1. Нумерация частей комплекса стандартов ИСО 13584 отражает его структуру:

• части 10 — 19 устанавливают концептуальные описания;
• части 20 — 29 устанавливают логические ресурсы;
• части 30 — 39 устанавливают ресурсы программной реализации;
• части 40 — 49 устанавливают методологию описания;

Полный перечень стандартов комплекса ИСО 13584 приведен на официальном сайте ИСО.

1. Область применения

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

В настоящем стандарте также установлено стандартное взаимное отображение данных, содержащих словарь, представленный в формате электронных таблиц, удовлетворяющих требованиям настоящего стандарта, и данных, представленных по ИСО 13584-25 и соответствующих требованиям модели EXPRESS для словарного обмена.

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

Такой набор электронных таблиц, поддерживающих класс, удовлетворяющий установленным требованиям и указанный в настоящем стандарте, может быть использован дополнительно для взаимной трансляции данных формата CSV и структуры физического файла по ИСО 10303-21, основанной на отображении, установленном в настоящем стандарте.

Структура интерфейса электронных таблиц, определенная в настоящем стандарте, распространяется на:

• определения и спецификацию базовой структуры и компоновочного плана интерфейса электронных таблиц библиотеки деталей, не зависящих от содержания данных, обусловленных рассматриваемой структурой;
• метод спецификации элементов данных, принадлежащих классу словаря ссылок, описанных набором электронных таблиц, удовлетворяющих требованиям настоящего стандарта;
• определение и спецификацию мета-словаря, обеспечивающего определение и передачу словаря ссылок, как набора элементов данных, удовлетворяющих требованиям мета-словаря;
• спецификацию взаимного отображения словаря данных, выраженного в формате электронных таблиц, и модели EXPRESS (см. ИСО 13584-25);
• описание базового семантического взаимного отображения словаря данных, выраженного в формате электронных таблиц и определенного в настоящем стандарте, и словаря данных, соответствующего DIN 4002.

Настоящий стандарт не распространяется на:

• спецификацию формата CSV, используемого в качестве инструмента электронных таблиц;
• спецификацию подробностей компоновочного плана представления данных, таких как расцветка и размеры интерфейса электронных таблиц, удовлетворяющих требованиям настоящего стандарта;
• спецификацию модели словаря EXPRESS, удовлетворяющей требованиям различных частей ИСО 13584;
• нормативное определение взаимных отображений одного словаря, соответствующего ИСО 13584, и другого словаря, соответствующего другим стандартам;
• спецификацию метода поддержки настоящего стандарта.

2. Нормативные ссылки

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

ИСО 639-1 Коды для представления названий языков. Часть 1. Двухбуквенный код (ISO 639-1 Codes for the representation of names of languages — Part 1: Alpha-2 code)

ИСО 639-2 Коды для представления названий языков. Часть 2. Трехбуквенный код (ISO 639-2 Codes for the representation of names of languages — Part 2: Alpha-3 code)

МЭК 61360-4 Стандартные типы элементов данных с ассоциированной схемой классификации электрических компонентов. Часть 4: Стандартный ссылочный набор типов элементов данных и классов компонентов (МЭК 61360-4 Standard data element types with associated classification scheme for electric components — Part 4: МЭК reference collection of standard data element types and component classes)

3. Термины и определения

В настоящем стандарте использованы следующие термины с соответствующими определениями:

3.1 прикладное свойство (applicable property): Свойство, определенное для некоторого семейства деталей и присущее любой детали, принадлежащей данному семейству. Пример - Для группового семейства винтов наличие резьбы является прикладным свойством. Данная характеристика присуща любому винту.

[ИСО 13584-24:2003, статья 3.3]

3.2 приложение (application): Использование программного обеспечения или стандарта в промышленной области.

3.3 базовая семантическая единица; БСЕ (basic semantic unit; BSU): Сущность, обеспечивающая абсолютную и универсальную уникальную идентификацию указанного объекта в области приложения. Пример - Классы, типы элементов данных.

[ИСО 13584-42, статья 3.4]

3.4 общая словарная схема; CIID схема (common dictionary schema; CIID schema): Информационная модель ссылочного словаря, основанная на модели данных EXPRESS, определенной в Стандартах МЭК 61360-2 и ИСО 13584-42.

3.5 составное свойство (composite property): Набор свойств, на которые можно ссылаться из некоторого класса (классов) как на единую сущность.

[ИСО 13584-501:2007, статья 3.8]

3.6 конъюнктивный пакет (conjunctive parcels): Набор страниц пакета, используемых совместно для определения библиотеки или ссылочного словаря.

3.7 данные (data): Величины, условные обозначения и символы, с помощью которых выполняются операции на компьютерах и другом автоматическом оборудовании и которые могут храниться или передаваться в форме электрических сигналов, записей на магнитных (магнитно-оптических, бумажных) носителях и т.д.

3.8 тип элемента данных; ТЭД (data element type; DET): Блок данных, для которых указан порядок представления идентификации, описаний и значений. Примечание - В серии стандартов ИСО 13584 значение свойства представляется как тип элемента данных.

[ИСО 13584-42, статья 3.13]

3.9 тип данных (data type): Представление, интерпретация и структура значений, используемые в компьютерных системах и на другом автоматическом оборудовании.

3.10 словарь; словарь данных (dictionary; data dictionary): Набор терминов, соответствующие идентификаторы которых формулируются с помощью канонического синтаксиса и общепринятых определений для создания лексической или описательной среды с целью представления знаний в электронной форме для их коллективного использования информационными системами и сообществами.

3.11 словарные данные (dictionary data): Словарь, представленный в виде строк данных, удовлетворяющих требованиям схемы, определенной коллективно с помощью мета-словаря.

3.12 словарный элемент (dictionary element): Набор атрибутов, составляющих словарное описание указанных объектов области приложения.

Пример 1 — Словарь, соответствующий настоящей части ИСО 13584, дает описания классов, свойств, источников информации и типов данных. Пример 2 — Словарь, соответствующий ИСО 13584-24, дает описания классов, свойств, источников информации, типов данных, таблиц, документов и библиотек программ.

[ИСО 13584-42, статья 3.15]

3.13 словарный пакет (dictionary parcel): Набор электронных таблиц, используемых для детального определения ссылочного словаря как элемента класса, представляемого разделом пакета страниц, содержащим заголовок схемы.

3.14 клиент словарного пакета; клиентская система словарного пакета (dictionary parcel client; dictionary parcel client system): Клиент пакета, который может считывать или вносить записи в словарный пакет, а также отсылать или получать их из серверной системы.

3.15 сервер словарного пакета; словарный сервер (dictionary parcel server; dictionary server): Пакетный сервер, обеспечивающий пользование словарным пакетом через Интернет.

3.16 сущность (entity): Класс информации, определяемый общими свойствами.

[ИСО 10303-11:2004, статья 3.3.6]

3.17 признак (feature): Аспект элемента данных, который выявляется структурой класса и набором свойств и который не может существовать независимо от указанного элемента данных.

Пример 1 — Признак формы — это аспект детали, удовлетворяющий требованиям некоторого уже сложившегося стереотипа формы, ассоциированного с размерными свойствами. Он может быть представлен как элемент класса, имеющего данный стереотип формы. Пример 2 — Выходной патрубок трубопроводной системы — это аспект детали, удовлетворяющий требованиям некоторого ранее определенного функционального стереотипа, ассоциированного с ее свойствами (т.е. именем, ролью). Он может быть представлен как признак.

[ИСО 13584-24:2003, статья 3.41]

3.18 глобально уникальный идентификатор; ID (globally unique identifier; ID): Идентификатор глобальной идентификации источника информации, который обеспечивает глобально уникальную идентификацию понятия без лингвистической интерпретации смысла буквенной последовательности идентификатора. Примечание - Глобально уникальный идентификатор может соответствовать (или не соответствовать) ИСО/МЭК 6523.

3.19 экземпляр, элемент (instance): Набор однокомпонентных (многокомпонентных) значений, идентифицируемых как отдельный компонент класса и концептуально характеризуемый набором свойств, принадлежащих указанному классу.

3.20 международный идентификатор понятия; международный ID понятия (international concept identifier; international concept ID; ICID): Глобально уникальный идентификатор, используемый в пакетном формате для идентификации каждого понятия данных.

3.21 безусловное соотношение (is-a relationship): Наследственное соотношение, определенное в объектно-ориентированной парадигме. Примечание - По ИСО 13584 безусловное соотношение располагается между семейством деталей и групповым семейством деталей, которому принадлежит бывшее семейство.

[ИСО 13584-24:2003, статья 3.61]

3.22 условное соотношение (is-case-of relationship): Соотношение, дающее формальное выражение того факта, что объект удовлетворяет требованиям частичной спецификации, определенной другим объектом. Примечание - По ИСО 13584 все свойства и типы данных, видимые или применимые для некоторых семейств деталей, могут быть импортированы всеми семействами деталей, описанными как условные формирующие семейства. Указанные свойства и типы данных тогда могут использоваться для описания последних указанных семейств.

[ИСО 13584-24:2003, статья 3.62]

3.23 соотношение части и целого (is-part-of): Агрегационное соотношение части и целого. Примечание - По ИСО 13584 соотношение части и целого располагается между семейством составляющих деталей и семейством сборок, которым принадлежат составляющие детали.

[ИСО 13584-24:2003, статья 3.63]

3.24 элемент данных (item): Сущность, выявляемая структурой класса или структурой свойства.

3.25 библиотека (library): Набор данных, состоящий из полного определения ссылочного словаря и спецификации элементов выборки, удовлетворяющих требованиям данного словаря, или часть такого набора данных, соответствующая некоторым классам ссылочного словаря.

3.26 поставщик библиотечных данных; поставщик (library data supplier; supplier): Организация, поставляющая библиотеку в формате, соответствующем ИСО 13584, и несущая ответственность за ее содержание.

[ИСО 13584-1:2001, статья 3.1.10]

3.27 внешний библиотечный файл (library external file): Файл, на который производится ссылка из библиотечного файла доставки и который способствует определению поставщика библиотеки. Примечание - Структура и формат внешнего библиотечного файла указаны в библиотечном файле доставки, который ссылается на указанный внешний файл.

[ИСО 13584-24:2003, статья 3.71]

3.28 библиотечная интегрированная информационная модель (library integrated information model; LIIM): Схема языка EXPRESS, интегрирующая конструктивы ресурсов из различных схем EXPRESS для представления библиотек поставщика с целью их обмена при условии удовлетворения поставленных требований. Примечание - В настоящей части ИСО 13584 определены три библиотечных интегрированных информационных модели для представления различных типов библиотек поставщика.

[ИСО 13584-24:2003, статья 3.72]

3.29 библиотечный пакет (library parcel): Набор электронных таблиц, используемых для определения в деталях набора экземпляров класса и представляемых заголовком данного пакета.

3.30 клиент библиотечного пакета (library parcel client): Клиент пакета, который может считывать или вносить записи в библиотечный пакет и который может посылать их на серверную систему или получать их из серверной системы.

3.31 сервер библиотечных пакетов; серверная система библиотечных пакетов (library parcel server; library parcel server system): Серверная система, работающая с библиотечными пакетами в Интернете.

3.32 мета-словарь (meta-dictionary): Набор мета-классов, каждый из которых характеризуется особым набором свойств, называемых «мета-свойствами»; при этом ссылочный словарь может быть определен и описан как экземпляр такого класса.

3.33 обеспечение мета-объекта (meta object facility): Среда управления мета-данными, набор сервисных услуг мета-данных для развития и обеспечения взаимодействия рассматриваемой модели и систем, управляемых мета-данными.

3.34 мета-свойство (meta-property): Свойство, используемое для характеристики мета-класса и для определения его синтаксической структуры.

3.35 открытый офисный вариант формата XML (Office Open XML): Набор словарей в формате XML, соответствующий ИСО/МЭК 29500 и требованиям схемы W3CXML, необходимый для представления текстов в электронной форме и создания электронных таблиц и презентаций.

3.36 редактор пакета (parcel editor): Система, редактирующая страницы пакета и имеющая возможность отсылать их или получать их по Интернету.

3.37 страница пакета; страница пакетирования; пакет (parcel sheet; parcelling sheet; parcel): Стандартное использование и спецификация электронных таблиц, используемых для спецификации словаря (библиотеки) данных, обмена и регистрации объектов в различных слоях мета-моделирования.

3.38 клиент пакета (parcel client): Клиент системы, который может считывать или вносить записи в страницы пакетирования в целом и который может посылать их в серверную систему или получать их из серверной системы.

3.39 пакетный сервер (parcel server): Серверная система, работающая со страницами пакетирования в целом в Интернете.

3.40 пакетирование (parcelling): Действие по определению, обмену или передаче информации в формате страниц пакетирования, определенных в настоящем стандарте.

3.41 инструмент пакетирования (parcelling tool): Инструмент, обеспечивающий пакетирование страниц в целом, включая PCL-клиентов, PCL-редакторов и PCL-серверы.

3.42 деталь (part): Материал или функциональный элемент, являющийся компонентом различных продуктов.

[ИСО 13584-1:2001, статья 3.1.16]

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

3.44 свойство библиотеки деталей; PLIB-свойство (property of parts library; PLIB-property): Вид свойства, используемого непосредственно в смысле свойства, определенного по ИСО 13584-42, если необходимо его дифференцировать от других вариантов использования свойства, таких как мета-свойства или свойства, используемые для описания взаимных отображений различных библиотечных данных или стандартных каталогов.

3.45 ссылочный словарь (reference dictionary): Словарь, основанный на использовании моделей данных в соответствии с ИСО 13584/МЭК 61360.

4. Сценарий использования интерфейса электронных таблиц

4.1 Представление словаря или библиотеки в виде электронной таблицы

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

Для простоты идентификации указанных двух применений и для установления отличия специализированных электронных таблиц от электронных таблиц широкого пользования применение библиотек деталей для словарного представления называют «форматом словарного пакетирования», а применение библиотек деталей для библиотечного представления — «форматом библиотечного пакетирования» в соответствии с настоящим стандартом.

В указанных форматах пакетирования (используемых либо для словарей, либо для библиотек) нужно компилировать совместно несколько электронных таблиц для представления словаря или библиотеки. Поэтому слово «пакетирование» проистекает из совместного использования обоими форматами определенного числа электронных таблиц. Каждая из них представляет собой семантически различное содержание сущностей языка EXPRESS в синтаксически аналогичном структурном блоке, называемым «пакетом» в настоящем стандарте. Полный сценарий применения интерфейса электронных таблиц для словаря и библиотеки приведен на рисунке 1.

Рисунок 1 — Сценарий применения пакета

4.2 Сценарий использования формата словарного пакетирования

Формат словарного пакетирования можно использовать в следующих типовых случаях:

• D1: считывание набора заготовок словарных пакетов со словарного сервера как словарного шаблона для определения нового ссылочного словаря;
• D2: определение содержания ссылочного словаря;
• D3: регистрация содержания ссылочного словаря на словарном сервере;
• D4: модификация содержания ссылочного словаря;
• D5: считывание ссылочного словаря со словарного сервера частично или целиком;
• D6: передача на интерфейс словарного пакета с другими приложениями программного обеспечения или техническими инструментами.

Из вышеизложенного следует, что пункты D1 — D3 связаны с определением новых ссылочных словарей с помощью программного обеспечения электронных таблиц, а пункты D4 — D6 требуются для повторного использования информации предварительно зарегистрированного ссылочного словаря.

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

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

Приложение G настоящего стандарта может также использоваться для установления взаимного отображения атрибутов настоящего стандарта и стандартов DIN 4002 с помощью альтернативного идентификатора.

4.3 Сценарий применения формата библиотечного пакетирования

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

• L1: считывание набора заготовок библиотечных пакетов с библиотечного сервера как библиотечный шаблон для определения новой библиотеки;
• L2: определение содержания библиотеки;
• L3: регистрация содержания библиотеки на библиотечном сервере;
• L4: модификация содержания библиотеки;
• L5: считывание частично или целиком библиотеки с библиотечного сервера;
• L6: передача на интерфейс библиотечного пакета с другими приложениями программного обеспечения или техническими инструментами.

Из вышеизложенного (см. L6) следует, что передача на интерфейс таких приложений программного обеспечения, как DTP (Подготовка книгоиздательства на экране компьютера), PDM (Управление данными продукта) или ERP (Планирование производственных ресурсов), а также других технических приложений, поддерживающих формат электронных таблиц для указанных входных данных и выходных данных, является особенно важной.

Фактически большая часть коммерческих версий DTP, PDM, а также аналитических технических инструментов имеет встроенный интерфейс входа/выхода для электронных таблиц. Если данные считываются в коммерческое приложение электронных таблиц (доступное на рынке), то преобразование данных из одного формата (варианта применения) в другой для электронной таблицы достаточно просто. Оно может быть выполнено на интуитивном уровне рядовым инженером, не имеющим особых знаний или специальных навыков переработки информации.

Это отличает формат пакетирования от других общепринятых форматов обмена библиотеками деталей. Другими словами, формат пакетирования можно использовать как интерфейс между одним инструментом (приложением), который считывает и вносит записи в формате электронных таблиц, и другим инструментом (приложением), который перерабатывает общепринятые словарные данные (удовлетворяющие требованиям ИСО 13584) или библиотечные данные по ИСО 10303-21 в формате «step» для физического файла.

В данном случае любой столбец, не имеющий идентификатора прикладного свойства (предположительно относящегося к классу, обозначенному идентификатором класса страницы пакета), должен игнорироваться системой, соответствующей настоящему стандарту. Данный признак полезен для широкого диапазона приложений, основанных на настоящем стандарте, так как информация может быть вмонтирована в страницу пакета для последующей переработки. Та же электронная таблица может быть использована различными способами различными приложениями в различных целях. Таким образом, рассматриваемые форматы пакетирования служат не только для обмена данными между системами, удовлетворяющими требованиям ИСО 13584. Они являются интерфейсом между системами, удовлетворяющими требованиям ИСО 13584, и другими системами, удовлетворяющими требованиям других стандартов и протоколов, и могут считывать и вносить записи в электронные таблицы для указанных входных и выходных данных.

5. Структура интерфейса электронной таблицы

5.1 Метод использования мета-словаря

Для гибкого моделирования библиотеки (словаря) с помощью одной базовой структуры электронных таблиц интерфейс электронных таблиц, определенный в настоящем стандарте, использует «мета-словарный метод», где особый акцент делается на отделении слоя моделирования мета-словаря от слоя моделирования ссылочного словаря. Другими словами, синтаксический мета-класс (язык наблюдения) предоставляет синтаксис мета-словарю как целевому языку, определяющему семантику ссылочных словарей.

При этом мета-словарь (язык наблюдения) предоставляет синтаксис ссылочному словарю как целевому словарю, который, в свою очередь, определяет семантику объектов реального мира. Указанное отделение синтаксического слоя моделирования от семантического слоя моделирования является достаточно частым в математической логике и формальной метафизике, но относительно редким при моделировании данных.

Преимущество данного метода в том, что модель данных ссылочного словаря, представленная в настоящем стандарте, может быть гибко обновлена (модифицирована) без изменения нижележащей базовой структуры, а также выстроена и представлена с помощью электронных таблиц. При этом как все конструктивы моделирования, построенные как сущности языка EXPRESS в соответствии с ИСО 13584-42 с особым именем, приведены к набору элементов данных мета-мета-класса, определяющего метасловарь (указанный в крайнем левом блоке), где рассматриваемые мета-классы и мета-свойства идентифицированы глобальным уникальным идентификатором. В соответствии с ИСО/МЭК 6523 большая часть обновлений и изменений рассматриваемой модели данных может быть реализована просто как добавления (удаления) элементов или как модификации значений элементов, определенных в указанном мета-мета-классе. Рассмотренный выше мета-словарный метод схематически представлен на рисунке 2 для облегчения его интуитивного восприятия.

Данные спецификации объекта как экземпляра

Рисунок 2 — Схема, поясняющая мета-словарный метод

5.2 Структура идентификации

В настоящем стандарте имеются ссылки на серию стандартов ИСО/МЭК 11179, в частности на стандарты ИСО/МЭК 11179-3 и ИСО/МЭК 11179-5 как на базовую среду идентификации типов понятий, используемых для описания элементов данных на странице пакета. Каждый элемент данных играет роль, аналогичную роли «упорядоченных элементов данных», определенных по ИСО/МЭК 11179-3 как идентификаторов зарегистрированных элементов данных.

Таким образом, страницы пакета, определенные по ИСО 13584-35, могут быть использованы просто как среда для сбора (отбора) мета-данных или элементов данных ссылочного словаря и их последующей официальной регистрации в соответствующем учреждении в соответствии с требованиями серии стандартов ИСО/МЭК 11179. Кроме того, в настоящем стандарте такой идентификатор применяется и назначается каждому конструктиву мета-данных. Таким образом, его функция в рассматриваемом случае требует дальнейшей дифференциации по отношению к механизму применения IRDI (Международный Идентификатор Регистрации Данных) для упорядоченного элемента данных, описанного по ИСО/МЭК 11179-5.

В настоящем стандарте рассматриваются элементы, идентифицируемые внутри набора мета-данных (мета-модели) как «элементы понятия». Примеры элементов понятий включают не только понятия класса и свойства, но также составляющие их ключевые атрибуты (имя, идентификатор, тип данных, единицы измерения, определения, условные обозначения, примечания и т.д.) вне зависимости от их назначения. И наоборот, такой идентификатор элемента понятия рассматривается в настоящем стандарте как «международный идентификатор понятия» или, для краткости, просто «идентификатор понятия», где все ясно из контекста, и обозначается аббревиатурой ICID. За исключением случаев классификации и идентификации конструктивов мета-модели, функция идентификатора ICID идентична функции идентификатора IRDI. Таким образом, он рассматривается как расширение идентификатора IRDI. В формате пакетирования каждый идентификатор ICID является уникальным при его использовании несколькими организациями. Он представляется нижеследующими кодами:

ICID::=RAI'#'DI'##'VI,

где RAI — идентификатор официального органа регистрации; DI — идентификатор данных; VI — идентификатор версии (в соответствии с ИСО/МЭК 11179-5).

Каждая из переменных RAI, DI, и VI сама может состоять из нескольких элементов данных. В настоящем стандарте два идущих подряд символа «решетка» (т.е. «##») используются для разделения переменных DI и VI, тогда как переменные RAI и DI разделяются одним таким символом «#». Это делает возможным получить краткое условное обозначение идентификатора понятия, убрав либо переменную RAI, либо переменную VI, либо их обе, если и так все ясно из контекста для переменной DI.

Таким образом, запись «P501_P000170##000000001» есть идентификация свойств: идентификатор свойств (называемый «property_BSU» по Стандарту ИСО 13584) имеет вид «P501_P000170», версия № 1, поставщик информации определяется контекстом. При этом запись «0120/1///13584_501_1#P501_P000170» обозначает свойство, где «0120/1///13584_501_1» — код поставщика информации, «P501_P000170» — код идентификатора свойств, Номер (N) версии определяется контекстом.

Данное условие крайне полезно, если пользователь не знает точно текущей версии свойства (класса) в ссылочном словаре, поддерживаемом на словарном сервере, при считывании отсутствующих блоков информации.

5.3 Структура страницы пакетирования

Рисунок 3 иллюстрирует общую структуру страницы пакетирования, не зависящую от типа данных (словарь или библиотека), содержащихся на странице пакетирования. Для простоты данные о поставщике информации и № версии в идентификаторе свойства опущены.

Секция данных

Рисунок 3 — Структура страницы пакетирования

Как видно на рисунке, по горизонтали страницу пакета можно разделить на два раздела: раздел заголовков и раздел данных. По вертикали страницу пакета можно разделить на столбец инструкций и набор столбцов значений. Кроме того, по горизонтали раздел заголовков делится на раздел заголовков классов и раздел заголовков схем. Раздел заголовков классов содержит информацию о данных страницы пакетирования. Поэтому он имеет также название «заголовок класса». Раздел заголовков схем содержит информацию о схеме представления данных электронной таблицы как класса. Таким образом, здесь дана «схема» элементов данных, описанных в разделе данных рассматриваемой страницы пакетирования.

5.4 Расширение имени файла

Если необходимо установить отличие формата пакетирования, удовлетворяющего требованиям настоящего стандарта, от формата электронной таблицы общего пользования, то имя файла библиотечного пакета следует заканчивать расширением имени файла «.pci», обозначающим формат пакетирования библиотек. Для специализированных словарей должно использоваться расширение «.pcd».

5.5 Библиотечное использование формата пакетирования

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

Если некоторые из указанных свойств относятся к перечислимому типу, т.е. либо к типу non_quantitative_STR (неколичественная строка), либо к типу non_quantitative_int (неколичественное целое), то добавленная страница пакетирования, называемая «enumeration parcel (пакет перечисления)», может сопровождать страницу пакета как библиотека элементов данных. Она также может содержать перечень всех возможных кодов и значений перечислимых типов, используемых в библиотечных пакетах.

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

Как указано выше, на каждой странице пакетирования имеется раздел заголовков и раздел данных. Раздел заголовков состоит из строк. Каждая строка начинается со знака решетка «#», за ним следует требуемое слово. Если слово не может быть опознано как требуемое, то данную строку просто следует рассматривать как комментарий.

В каждой строке элементы данных разделены запятой «,». Все значения свойств, ограниченные парой запятых, располагаются в столбце. Если значения данных сами содержат запятую, то эти значения данных должны располагаться между начальной и конечной двойными кавычками, например «10,000», где 10,000 — это значение. Внешняя пара двойных кавычек добавляется просто для дополнительного выделения в данном документе.

Принято также, что каждая строка должна заканчиваться кодом управления подачей строки, используемым в большинстве приложений популярного программного обеспечения электронных таблиц (например, «0d0a» в шестнадцатеричном формате). Код автоматически дополняется большим количеством различных типов приложений электронных таблиц, совместимых с современным программным обеспечением электронных таблиц, имеющимся в открытой продаже <1>.

-------------------------------- Microsoft^{®} MS - EXCEL^{®} <1> Одной такой программой является , разработанная Corporation. Это пример широко распространенного коммерческого продукта. Данная информация в настоящем стандарте приводится для удобства Пользователя, ее использование не требует разрешения официальных органов ИСО.

5.6 Раздел заголовков

5.6.1 Категории инструкций

Каждая строка интерпретируется с помощью семантической функции, описанной в первом столбце значений. В соответствии с вышесказанным инструкции, используемые при работе с информационной системой, удовлетворяют требованиям настоящего стандарта. В соответствии с этими требованиями файл в формате пакетирования должен начинаться с символа «#». Имеются четыре категории инструкций:

• обязательные;
• по выбору — функциональные;
• по выбору — информативные;
• комментарии.

Слова, следующие за символом «#» и относящиеся к одной из вышеуказанных категорий (за исключением категории «Комментарии»), следует рассматривать как резервные, они не могут использоваться для других целей.

5.6.2 Обязательные инструкции

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

5.6.3 Инструкции по выбору — функциональные

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

5.6.4 Инструкции по выбору — информативные

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

5.6.5 Комментарии

Строки, начинающиеся с символа «#», за которым не следуют резервные слова, интерпретируются как комментарии. Комментарий может быть расположен и внутри строки. Это означает, что инструкции категорий «обязательная», «по выбору — функциональная» и «по выбору — информативная», могут иметь комментарии, вставленные после символа «#».

5.6.6 Резервные слова

Резервные слова категорий, указанные в разделе 5.6.1, сведены в таблицы B.1 и B.2.

5.7 Столбец инструкций

5.7.1 Общее правило

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

Правило 1 — как можно больше комментариев!

Любые строки, включая строки с ключевым словом, можно «закомментировать» символом «#», за исключением обязательных строк.

Правило 2 — обязательные инструкции имеют преимущество.

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

Правило 3 — точность описания ключевых слов.

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

Нижеследующие подразделы определяют особые правила написания и значения каждого ключевого слова.

5.7.2 Идентификатор класса ID

Пример 1 — #CLASS_ID:=0112/1///13584_501_1#P501_C000001##000000001. Пример 2 — #CLASS_ID:=0112/1///13584_501_1#P501_C000001.

5.7.3 Предпочтительное имя класса

Пример - #CLASS_NAME.EN:=Environment measurement instrument (Инструмент для измерения параметров окружающей среды).

5.7.4 Определение класса

Пример - #CLASS_DEFINITION.EN:=набор усилителей напряжения, каждый из которых может быть описан той же группой типов элементов данных.

5.7.5 Примечание для класса

Пример - #CLASS_NOTE.EN:=Данный класс соответствует классу, определенному стандартами МЭК/CDD.

5.7.6 Альтернативный идентификатор класса ID

Пример - #ALTERNATE_CLASS_ID:=147/101001#XJA418.

5.7.7 Язык источника

Пример 1 — #SOURCE_LANGUAGE:=EN-US (Язык источника — американский английский).

Пример 2 — #SOURCE_LANGUAGE:=FR (Язык источника — французский). Пример 3 — #SOURCE_LANGUAGE:=JA (Язык источника — японский).

5.7.8 Идентификатор пакета

Пример - #PARCEL_ID:=2006-06-25 08:19:49.

5.7.9 Идентификатор класса, удовлетворяющий требованиям пакета

Пример - #PARCEL_CC:=9.

5.7.10 Поставщик по умолчанию

Пример - #DEFAULT_SUPPLIER:=0112/1///13584_501_1.

5.7.11 Идентификатор свойства

Таблица 1

Описание кодов свойств

Примечание 1 — Если тип данных свойства — это level_TYPE, то столбец размещается на каждом уровне, определенном типом данных. Такой код свойства имеет вид: «property_code» + «sep_id» + «levels». Уровни идентифицируются трехбуквенными словами: «MIN», «NOM», «TYP», «MAX». Разделителем здесь является точка «.».

Примечание 2 — Если типом данных свойства является переводимая строка translatable_string, то столбец формируется для каждого языка. Код свойства имеет вид: «property_code» + «sep_id» + «language_code». Код языка идентифицирует язык в соответствии с ИСО 639. Значения кодов языка: «EN» для английского языка (в целом), «FR» для французского языка, «RU» для русского языка, «DE» для немецкого языка, «en GB» для английского языка Великобритании, «en US» для американского английского и т.д.

Примечание 3 — При использовании условных обозначений уровней 4 и 5 идентификатор поставщика по умолчанию должен декларироваться перед использованием типов описаний кодов свойств, соответствующих уровням 4 и 5. Подробности см. в разделе «#DEFAULT_SUPPLIER». Примечание 4 — Уровень 2 рекомендуется использовать только для поддержания совместимости с традиционными словарями в соответствии с ИСО 13584-42 (издание 1) и с МЭК 61360-2 (издания 1 и 2). Для любых других целей использование уровня 2 строго запрещено.

Пример - В данном примере использовано условное обозначение уровня 3 (т.е. указание версий свойств опущено):

#PROPERTY_ID,0140/TOPAS#P000001,0140/TOPAS#P001089.MAX,

0140/TOPAS#P001089.MIN,0140/TOPAS#000894.EN, 0114/TOPAS#P000894.FR,

Соответствующее описание в виде электронной таблицы представлено на рисунке 4.

Рисунок 4 — Пример представления идентификатора свойства

5.7.12 Предпочтительное имя свойства

Пример - #PROPERTY NAME.EN,CONSORTIUM STANDARD,PH

MEASURING,PH MEASURING,COMPANY NAME,COMPANY NAME,

#PROPERTY_NAME.FR,NORME D'ASSOCIATION,MESURE PH, MESURE PH,NOM ENTREPRISE,NOM ENTREPRISE.

Вид электронной таблицы для этого примера представлен на рисунке 5.

Рисунок 5 — Пример представления предпочтительного имени

5.7.13 Определение

Пример - #DEFINITION, «ссылочный стандарт консорциума компаний, ассоциации или организации, исключая международный стандарт и национальный стандарт», «диапазон измерений pH для измерительного инструмента», «название компании — изготовителя продукта».

Вид электронной таблицы представлен на рисунке 6.

Рисунок 6 — Пример представления определения

5.7.14 Примечание

Пример - #NOTE, «ссылочный стандарт консорциума компаний, ассоциации или организации, исключая международный стандарт и национальный стандарт», «диапазон измерения pH измерительным инструментом», «название компании, являющейся изготовителем продукта».

5.7.15 Тип данных

Пример - #DATATYPE,STRING_TYPE,LEVEL(MIN,MAX) OF

REAL_MEASURE_TYPE,LEVEL(MIN,MAX) OF

REAL_MEASURE_TYPE,TRANSLATED_STRING, TRANSLATED_STRING.

Вид электронной таблицы представлен на рисунке 7.

Рисунок 7 — Пример представления типа данных

Примечание - Типы данных могут быть сконструированы из примитивов. Пример примитива дан в Приложении Г.

5.7.16 Единицы измерения

Пример - #UNIT,,pH,pH,,,

Вид электронной таблицы представлен на рисунке 8.

Рисунок 8 — Пример представления единицы измерения

5.7.17 Требование

Пример - #REQUIREMENT,KEY,,,,,

MANDATORY

Рисунок 9 — Пример представления ключа

5.7.18 Альтернативные единицы измерения

Вид электронной таблицы представлен на рисунке 10.

Рисунок 10 — Пример представления единиц измерения

5.7.19 Идентификаторы альтернативных единиц измерения

Вид электронной таблицы представлен на рисунке 11.

Рисунок 11 — Пример представления единиц измерения

5.7.20 Альтернативный идентификатор свойства

Пример - #PROPERTY_ID,MDC_P001_5,MDC_P002_1,MDC_P004_1.DE,MDC_P005.DE, #ALTERNATE_ID,C01,C02,A01(DE),A04(DE).

Вид электронной таблицы представлен на рисунке 12.

Рисунок 12 — Пример представления альтернативного идентификатора свойства

5.7.21 Идентификатор единицы измерения

Пример - #UNIT_ID,, 0112/1///13584_35_1#Pxxx_PFU001,0112/1///13584_35_1#Pxxx_PFU001.

Вид электронной таблицы представлен на рисунке 13.

Рисунок 13 — Пример представления идентификатора единицы измерения

5.7.22 Формат значения свойства

Пример - #VALUE_FORMAT,M..14,M..255,M..255.

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

Рисунок 14 — Пример представления формата значения

5.7.23 Кодирование идентификатора

Пример - #ID_ENCODE, ICID, ISO 29002.

Рисунок 15 иллюстрирует порядок представления кодирования идентификатора для каждого свойства, указанного соответствующим идентификатором свойства.

Рисунок 15 — Пример представления спецификации кодирования идентификатора

5.7.24 Кодирование идентификатора по умолчанию

Пример - #DEFAULT_ID_ENCODE:=ISO 29002.

Рисунок 16 иллюстрирует порядок представления кодирования идентификатора для каждого свойства, если метод кодирования по умолчанию #DEFAULT_ID_ENCODE соответствует требованиям ИСО 29002. #ID_ENCODE назначен для ICID рассматриваемой версии, и словарем является содержание библиотеки.

Рисунок 16 — Пример представления спецификации кодирования идентификатора

5.8 Раздел элементов данных

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

В настоящем стандарте каждая строка в разделе данных обозначает множество значений свойств, коллективно характеризующих элемент данных (например, перечень пар «свойство-значение» для одной детали (продукта), принадлежащей некоторому классу). Если в первом столбце строки (а именно, в столбце инструкций внутри раздела данных) стоит символ «#» в начале последовательности букв (значений), то строку следует рассматривать как комментарий. Пользователь может вставлять столько комментариев, сколько хочет. Данная особенность также может быть использована для комментариев каких-либо существующих значений элементов данных.

В настоящем стандарте использованы условные обозначения типов данных, соответствующие ИСО 13584-42. Детальное сравнение и соответствие условных обозначений типов данных, используемых по настоящему стандарту и по ИСО 13584-42, рассмотрены в приложении D.

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

5.8.2 Перечислимые (неколичественные) типы данных

Для таких типов данных, как данные с неколичественным типом кода non_quantitative_code_TYPE и данные с неколичественным целочисленным типом кода non_quantitative_int_TYPE, только один код значения (из некоторого перечня кодов значений, предварительно определенных для каждого указанного типа данных) должен быть внесен в раздел данных как значение элемента данных. Смысл кода как значение не вносится. На рисунке 17 дан пример типового представления приложения электронных таблиц.

Рисунок 17 — Пример представления типов данных ENUM_INT_TYPE и ENUM_CODE_TYPE

Примечание - Например, в описании «ENUM_CODE_TYPE(EXX_001(red,blue,yellow))» величина «EXX_001» ID — это идентификатор списка перечисления, а «red (красный)», «blue (голубой)» и «yellow (желтый)» — коды значений, доступных для выбора. Перечень кодов значений дан только для информации. Значения в строке «#DATA_TYPE» могут быть опущены, так же как и выражение «ENUM_CODE_TYPE(EXX_001)».

5.8.3 Типы уровней

Для каждого элемента с типом уровня (MIN., MAX., TYP., NOM.), используемого в библиотечном файле обмена, должен использоваться один столбец. Если некоторые элементы не используются во всех составляющих файла, то столбцы для этих элементов не нужны. Элементы уровневого типа идентифицируются расширением (через точку) с трехбуквенным кодом, добавляемым после кода идентификатора свойства, размещенного в строке #PROPERTY_ID. На рисунке 18 приведен пример типового представления приложения электронных таблиц, использующего только два уровня «.MIN» и «.MAX» из четырех возможных.

Рисунок 18 — Пример представления типов уровней LEVEL_TYPE

Примечание - JAPAN Corporation и FRENCH Ltd. и их эквиваленты на французском языке используются просто как пример, их названия вымышлены. Ни JAPAN Corporation, ни FRENCH Ltd. в действительности не существует.

5.8.4 Тип строки

Для каждого свойства STRING_TYPE, используемого в библиотечном файле обмена, должен быть выделен один столбец. Если необходимо как-то обозначить язык выражения смысла значения типа строки, то для этого применяется двухбуквенный код языка в соответствии с ИСО 639 для языка источника #SOURCE_LANGUAGE (см. 5.7.7).

5.8.5 Транслируемый тип строки

Для каждого языка представления свойства транслируемого типа строки TRANSLATABLE_STRING_TYPE, используемого в библиотечном файле обмена, должен быть выделен один столбец. Элемент языка представления типа TRANSLATABLE_STRING_TYPE описывается расширением (через точку) с помощью двухбуквенного кода, добавленного после кода идентификатора свойства, размещенного в строке #PROPERTY_ID. На рисунке 19 дан типовой пример представления приложения электронных таблиц.

Рисунок 19 — Пример представления типа данных TRANSLATABLE_STRING_TYPE

Примечание - Фирмы JAPAN Corporation и FRENCH Ltd., а также их эквиваленты на французском языке используются просто как пример, их названия вымышлены. Ни JAPAN Corporation, ни FRENCH Ltd. никогда не существовали в реальном мире.

5.8.6 Булевский тип

Для свойств булевского типа значениями могут быть только «TRUE (истина)» или «FALSE (ложь)». На рисунке 20 дан типовой пример представления приложения электронных таблиц.

Рисунок 20 — Пример представления БУЛЕВСКОГО ТИПА

5.8.7 Тип экземпляра класса (тип ссылки на класс)

В библиотечном файле обмена — см. «Main file (основной файл)» значение элемента указанного типа данных должно содержать только один идентификатор класса class_ID и условия ссылки в виде перечня пар «свойство-значение». Тип элемента класса можно также рассматривать как «тип ссылки на класс», который может быть указан вместо class_instance_TYPE. На рисунке 21 дан типовой пример представления вышесказанного в виде приложения электронных таблиц.

Рисунок 21 — Пример представления типа ссылки на тип CLASS_INSTANCE_TYPE

Примечание 1 — При описании механизма ссылки на тип class_instance_type прежде всего следует отметить идентификатор ICID ссылочного класса. Перечень пар «свойство-значение» идет за идентификатором ICID и размещается в скобках.

Примечание 2 — 0140/TOPAS#C000888 — это идентификатор ICID одного из подклассов того класса, для которого идентификатор ICID — это 0140/TOPAS#C000999. Примечание 3 — Возможен краткий вариант условного обозначения идентификатора поставщика supplier_ID. Если задать «#DEFAULT_SUPPLIER:=0140/TOPAS/», то условное обозначение идентификатора ICID вроде «0140/TOPAS#C000999» может выглядеть как «P501_C000999».

5.8.8 Агрегатированный тип

Правила описания агрегатированных типов:

• элементы данных агрегатированных типов размещаются в скобках вида «{}» или «()»;
• фигурные скобки «{}» указывают, что среди рассматриваемых элементов данных нет установленного порядка; таким образом, это данные типа SET или BAG;
• обычные скобки «()» указывают, что среди элементов данных установлен фиксированный порядок; таким образом, это данные типа LIST или ARRAY;
• элементы данных разделяются запятыми; пробелы перед и между условными обозначениями выделяют свойства типа строки STRING;
• если элементы данных сами включают скобки вида «{», «}», «(», или «)», то их следует писать внутри пары двойных кавычек;
• если элементы данных агрегатированных типов уже включают двойные кавычки, то они должны быть размещены внутри пары двойных кавычек.

Ниже даны характерные примеры описаний, совместимые с вышеуказанными правилами:

Пример 1 -

ЗАДАНИЕ ТИПА СТРОКИ STRING_TYPE

Текстовые инструкции, соответствующие настоящему стандарту:

#PROPERTY_ID,TOPAS Pxxx,

#PROPERTY_NAME.EN,COLOR,

#DATATYPE,«SET(1,4) OF STRING_TYPE», ,«{red,white,blue,black}»,

{red,white,blue,black}

Рисунок 22 — Пример представления задания типа строки STRING_TYPE

Пример 2 -

ПЕРЕЧЕНЬ ТИПОВ СТРОКИ STRING_TYPE

Текстовое определение инструкции соответствует настоящему стандарту:

#PROPERTY_ID,TOPAS Pxxx,

#PREFNAME.EN,COLOR,

#DATATYPE,«LIST(1,5) OF STRING_TYPE», ,«{red,white,blue,black}»,

На рисунке 23 вышеуказанный Пример 2 представлен в виде приложения электронных таблиц.

Рисунок 23 — Пример представления перечня типов строки STRING_TYPE

Пример 3 -

ПЕРЕЧЕНЬ ТРАНСЛИРУЕМЫХ СТРОК TRANSLATED_STRING

Текстовое определение инструкции, соответствующее настоящему стандарту:

#PROPERTY_ID,TOPAS Pxxx.EN,TOPAS Pxxx.JA,

#PREFNAME.EN,Traded product,Traded product,

#PROPERTY_NAME.FR,Produits treates,Produits treates,

#DATATYPE,«LIST(1,4) OF TRANSLATABLE_STRING»,«LIST(1,4) OF TRANSLATABLE_STRING», ,«{motor,computer,display,memory}»,«{moteur,ordinateur,ecran,memoire}»,

На рисунке 24 вышеуказанный Пример 3 представлен в виде приложения электронных таблиц.

Рисунок 24 — Пример представления перечня транслируемых строк

Порядок следования символов должен соответствовать порядку следования букв на используемом языке. Так, слово motor («электромотор» на английском языке) соответствует слову moteur (на французском языке). См. таблицу 2.

Таблица 2

Пример соответствия порядка следования букв на различных языках

Пример 4 -

ЗАДАНИЕ УРОВНЕЙ ТИПА РЕАЛЬНОГО ИЗМЕРЕНИЯ REAL_MEASURE_TYPE

Рассмотрим два набора, состоящих из трех элементов каждый: 1) (максимальное входное напряжение 240 В, номинальное входное напряжение 120 В, минимальное входное напряжение 100 В); 2) (максимальное входное напряжение 300 В, номинальное входное напряжение 200 В, минимальное входное напряжение 110 В). Ниже приводится их спецификация.

Текстовое определение инструкции, соответствующей настоящему стандарту:

,«{(100,120,240),(110,200,300)}»,

:

Рисунок 25 — Пример представления набора уровней значения свойства

Примечание - Обязательный порядок описания уровней: MIN, NOM, TYP, MAX. Любой элемент в данной последовательности может быть пропущен.

Пример 5 -

ЗАДАНИЕ НАБОРОВ ТИПОВ СТРОКИ SET OF SET OF STRING_TYPE

Текстовое определение, соответствующее настоящему стандарту:

#PROPERTY_ID,TOPAS Pxxx,

#PROPERTY NAME.EN,COLOR,

#DATATYPE,«SET(1,2) SET(1,2) OF STRING_TYPE», ,«{{AAA,BBB),{AAA,XXX}}»,

:

Рисунок 26 — Пример представления наборов типов строки

5.8.9 NAMED_TYPE (Именованный тип)

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

5.8.10 Тип элемента сущности

Тип размещения используется для определения положения геометрических точек в 2D- или 3D-пространстве. Ниже указаны три возможных типа:

• Axis1_placement_TYPE (тип размещения по оси № 1);
• Axis2_placement_2D_TYPE (тип двухмерного размещения по оси № 2);
• Axis2_placement_3D_TYPE (тип трехмерного размещения по оси № 2).

5.9 Словарное использование формата пакетирования

5.9.1 Словарь как элемент мета-словаря

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

Такой словарь, описанный как набор элементов группового словаря, может быть транспортирован как полезная загрузка, соответствующая пакетной электронной таблице. Здесь и далее такой словарь называется «словарь данных». При этом указанный групповой словарь, определяющий синтаксис этого словаря данных, здесь и далее называется «мета-словарь». Каждый класс мета-словаря называется «мета-классом», чтобы отличить его от обычного класса ссылочного словаря. Он содержит набор полезных данных мета-класса в мета-словаре. Аналогично, каждое свойство, используемое мета-классами для описания атрибутов словарных элементов ссылочных словарей, должно называться «мета-свойством», чтобы установить различие между свойством мета-класса в мета-словаре и свойством класса ссылочного словаря. Электронная таблица, представляющая один из восьми мета-классов, имеет некоторые мета-свойства мета-класса в Разделе заголовков схемы и может быть использована для ссылок в целом как «словарный пакет». Типовая конфигурация словарного пакета показана на рисунке 27.

Раздел заголовков

Рисунок 27 — Конфигурация словарного пакета

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

• словарь;
• поставщик;

• документ;
• тип данных NAMED_TYPE (поименованного типа).

Кроме указанных выше семи нормативных мета-классов по выбору могут быть поставлены нижеследующие мета-классы:

• объект;
• UoM (единица измерения);
• терминология.

Среди семи указанных выше стандартизованных страниц пакетирования первые четыре пакета являются обязательными при обмене словаря в формате пакетирования. Более того, если страница пакета свойств включает так называемые свойства «перечислимого типа» или, точнее, неколичественного «non_quantitative» типа, как они называются в серии стандартов ИСО 13584, то пакет перечисления обычно сопровождает пакет свойств (для пояснения смысла каждого кода перечисления, а именно, для текстового пояснения кодов, используемых для указанных типов свойств).

Пакет мета-класса объекта может быть добавлен для идентификации и спецификации каждой строки элементов данных. По сути, это объект данных, расположенный в разделе данных пакета. Содержание данного пакета расширяется для отслеживания корректировки данных в будущих изданиях настоящего стандарта.

Пакет для единицы измерения «Мета-класс единицы измерения» может быть дополнен Пользователем по его усмотрению. Это означает, что набор мета-свойств для мета-класса рассматриваемой единицы измерения UoM не стандартизован в настоящем стандарте, но мета-классы и ссылочная структура пакета единиц измерения здесь рассматриваются. Если идентификатор каждой единицы измерения определен и объем дополнительной информации о единице измерения превышает объем, установленный ИСО 13584/МЭК 61360 для рассматриваемой модели данных, то любая спецификация мета-класса единицы измерения удовлетворяет необходимым требованиям. Информация о единице измерения в разделе заголовков ниже строки «#UNIT» в настоящем стандарте имеет только справочный характер, и любой пропуск информации не должен изменить поведение системы. Дело в том, что идентификатор свойства в конечном счете определяет все спецификации свойств, включая единицы измерения. Если пакет единиц измерения UoM задан пользователем, то он должен включать всю информацию, необходимую для заполнения ячеек с атрибутами единиц измерения свойств, описанных в мета-классе рассматриваемого свойства.

5.9.2 Идентификация конъюнктивных пакетов

Если необходимо идентифицировать конъюнктивные пакеты, т.е. страницы пакетирования, которые совместно описывают ссылочный словарь как элементы данных, то это выполняется путем идентификации идентификатора каждого пакета. Если значения идентификаторов пакетов, указанных в соответствующих пакетах, те же самые, то пакеты рассматриваются как конъюнктивные. Идентификатор пакета — это идентификатор типа строки STRING_TYPE, если ни двойные кавычки, ни запятые не использованы в буквенной последовательности идентификатора. Однако в отличие от обозначений BSU тире («-») и двоеточия («:») в данной последовательности допустимы. Поэтому для идентификатора пакета в строке #PARCEL_ID может быть дана временная отметка типа «2006-06-25 08:19:49» в соответствии с ИСО 8601.

5.9.3 Роли и определения словарных пакетов

Роли и определения словарных пакетов сведены в таблицу 3. Идентификаторы ICID мета-класса являются нормативной частью информации, определенной настоящим стандартом.

Таблица 3

Мета-классы, составляющие мета-словарь

5.9.4 Свойства мета-словаря

5.9.4.1 Обзор мета-классов

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

То, что определено в разделе данных каждого мета-класса, не является мета-свойствами. Это конструктивы данных, используемых в стандартах онтологии, например в МЭК 61360-2 или ИСО 13584-42. Поэтому мета-класс классов содержит перечень всех классов в ссылочном словаре данных (в разделе данных), мета-класс свойств содержит перечень всех свойств в том же словаре.

5.9.4.2 Мета-свойства мета-класса словаря

Словарный пакет определяет нижеследующий перечень атрибутов ИСО 13584 как мета-свойства мета-класса, определяющего словарный пакет:

• словарный код;
• № версии;
• № пересмотра;
• предпочтительное имя. (на соответствующем языке);
• синонимическое имя;
• краткое имя. (на соответствующем языке);
• иконка имени;
• примечание. (на соответствующем языке);
• пометка. (на соответствующем языке);
• поставщик;
• идентификатор документа источника LIIM (LIIM = Интегрированная библиотечная информационная модель);
• статус LIIM;

• уровень LIIM;
• глобальный язык;
• язык источника.

Нижеследующие атрибуты словарной сущности в данном пакете не моделируются. Они моделируются как элементы данных пакета поставщика:

• ссылочные поставщики.

Нижеследующие атрибуты словарных сущностей в данном пакете не моделируются. Они моделируются как элементы данных пакета класса:

• содержащиеся классы.

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

• полный атрибут;
• обновление;
• соглашение обновления;
• ссылочные словари;
• протокол внешнего файла;
• базовый протокол;
• поддерживаемая версия;
• апостериорные семантические соотношения.

Детальные спецификации всех мета-свойств пакета суммируются в приложении Д.

5.9.4.3 Мета-свойства мета-класса классов

Пакет класса определяет нижеследующий перечень атрибутов мета-свойств мета-класса, соответствующих ИСО 13584 и определяющих пакет класса:

• код;
• № версии;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;
• предпочтительное имя. (на соответствующем языке);
• синонимическое имя;
• краткое имя. (на соответствующем языке);
• иконка имени;
• DEFINITION. (определение на соответствующем языке);
• документ источника определения;
• примечание. (на соответствующем языке);
• пометка. (на соответствующем языке);
• упрощенный чертеж;
• суперкласс;
• тип класса;
• поставщик;
• условный атрибут;
• применимое свойство;
• применимый тип;

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

Нижеследующие атрибуты словарных сущностей в данном пакете не моделируются. Они классифицируются как элементы данных пакета свойств:

• видимые свойства.

Нижеследующие атрибуты словарных сущностей в данном пакете не моделируются. Они моделируются как элементы пакета типа данных:

• видимый тип.

Детальные спецификации всех мета-свойств пакета суммируются в приложении Д.

5.9.4.4 Мета-свойства мета-класса свойств

Пакет свойств определяет нижеследующий перечень атрибутов мета-свойств мета-класса, соответствующих ИСО 13584 и определяющих пакет свойств:

• код;
• № версии;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;
• предпочтительное имя. (на соответствующем языке);
• синонимическое имя;
• краткое имя. (на соответствующем языке);
• иконка имени;
• DEFINITION. (определение на соответствующем языке);
• документ источника определения;
• примечание. (на соответствующем языке);
• пометка. (на соответствующем языке);
• графика;
• тип элемента данных свойства;
• класс определений;
• тип данных;
• структура единиц измерения;
• единицы измерения в текстовом формате;
• единицы измерения в формате SGML;
• формат значения;
• предпочтительный буквенный символ в текстовом формате;

• формула в текстовом формате;
• формула в формате SGML;
• условие;
• классификация ТЭД;
• код для единиц измерения.

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

• ненулевое ограничение;
• классификационная метка свойства.

Детальные спецификации всех мета-свойств пакета приведены в приложении Д.

5.9.4.5 Мета-свойства мета-класса поставщиков

Пакет поставщика определяется нижеследующим перечнем атрибутов мета-свойств мета-класса, удовлетворяющих требованиям ИСО 13584 и определяющих пакет поставщика:

• код поставщика;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;
• идентификатор организации;
• название организации;
• описание организации;
• внутреннее размещение;
• № улицы;
• улица;
• почтовый ящик;
• город;
• регион;
• почтовый код;
• страна;
• № факса;
• № телефона;
• E-mail (электронная почта);
• № телекса.

Детальные спецификации всех мета-свойств пакета приведены в приложении Д.

5.9.4.6 Мета-свойства мета-класса перечислений

Пакет перечислений определяет нижеследующий перечень атрибутов мета-свойств мета-класса, удовлетворяющих требованиям МЭК 61360 и ИСО 13584 и определяющих пакет перечислений:

• перечень кодов перечислений;
• документ источника значения.

Кроме атрибутов, определенных в МЭК 61360 или ИСО 13584, ниже определяются дополнительные атрибуты:

• код;
• перечень кодов перечислений для представления;
• № версии;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;

• иконка имени;
• определение;
• примечание;
• пометка;
• класс определений.

Мета-класс перечислений является обязательным, если в мета-классе свойств используется какой-либо перечислимый тип.

Детальные спецификации всех мета-свойств пакета приведены в приложении Д.

5.9.4.7 Мета-свойства мета-класса типов данных

Пакет типа данных определяет нижеследующий перечень атрибутов, соответствующих ИСО 13584, как мета-свойства мета-класса, определяющие некоторый пакет типа данных:

• код;
• № версии;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;
• предпочтительное имя. (на соответствующем языке);
• синонимическое имя;
• краткое имя. (на соответствующем языке);
• иконка имени;
• класс определений;
• структура единиц измерения;
• единицы измерения в текстовом формате;
• единицы измерения в формате SGML;
• формат значения;
• код единицы измерения.

Детальные спецификации всех мета-свойств пакета суммируются в приложении Д.

5.9.4.8 Мета-свойства мета-класса документов

Пакет документов определяет нижеследующий перечень атрибутов, удовлетворяющих требованиям ИСО 13584, как мета-свойства мета-класса, определяющие пакет документов:

• код;
• № версии;
• № пересмотра;
• дата оригинального определения;

• синонимическое имя;
• краткое имя. (на соответствующем языке);
• иконка имени;
• DEFINITION. (определение на соответствующем языке);
• пометка. (на соответствующем языке);
• класс определений;
• идентификатор организации в документе;
• название организации в документе;
• описание организации в документе;
• удаленное размещение. (на соответствующем языке);
• кодирование условными обозначениями. (на соответствующем языке);
• файл основного содержания.;
• кодирование основного содержания.;
• электронная корреспонденция MIME-типа с основным содержанием.;
• формат обмена основным содержанием.;
• формат RFC для основного содержания.;
• имя файла http-типа с основным содержанием..

Детальные спецификации всех мета-свойств пакета даны в приложении Д.

5.9.4.9 Мета-свойства мета-класса объектов

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

• идентификатор объекта данных;
• отметка времени.

Детальные спецификации всех мета-свойств пакета приведены в приложении E.

5.9.4.10 Мета-свойства мета-класса единиц измерения

Мета-класс единиц измерения должен иметь по крайней мере нижеследующий набор мета-свойств для корректного моделирования атрибутов, связанных с единицами измерения свойств объекта:

• код;
• № версии;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;
• предпочтительное имя. (на соответствующем языке);
• синонимическое имя;
• краткое имя. (на соответствующем языке);
• иконка имени;
• DEFINITION. (определение на соответствующем языке);

• структура единиц измерения;
• единицы измерения в текстовом формате;
• единицы измерения в формате SGML.

Детальные спецификации всех мета-свойств пакета приведены в приложении Д.

5.9.4.11 Мета-свойства мета-класса терминологий

Мета-класс терминологий должен иметь нижеследующий набор мета-свойств для корректного моделирования специальных терминов, имеющихся в словаре:

• код;
• № версии;
• № пересмотра;
• дата оригинального определения;
• дата текущей версии;
• дата текущего пересмотра;
• предпочтительное имя. (на соответствующем языке);
• синонимическое имя;
• краткое имя. (на соответствующем языке);
• DEFINITION.<lang (определение на соответствующем языке);
• документ источника определения;
• примечание. (на соответствующем языке);
• пометка. (на соответствующем языке);
• класс определений;
• предпочтительный буквенный символ в текстовом формате;
• предпочтительный буквенный символ в формате SGML.

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

Наличие мета-класса терминологий является обязательным, если мета-класс перечислений присутствует в конъюнктивных пакетах. Термины напоминают сами свойства. Их отличие — в отсутствии значений. Однако термины используются при описании элементов данных в словарях и других документах аналогичного назначения.

6. Механизм структурного расширения

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

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

Пользователь настоящего стандарта может (по своему усмотрению) добавить частную инструкцию или поле атрибута свойства. Расширение должно начинаться с символа «#», не должно заканчиваться символом «#» и не должно конфликтовать с резервным ключевым словом, определенным в настоящем стандарте.

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

6.2 Пример

Если необходимо указать имя реляционной базы данных, в которую вносятся библиотечные данные, то Пользователь может расширить формат стандартной библиотечной страницы пакетирования путем добавления переработанной инструкции. Например: «#TARGET_TBL» или «#CONTENT_ID» для указания имени целевой реляционной таблицы, например «#TARGET_TBL:=flash_memory001» или «#CONTENT_ID:=motor001».

Так как любая строка, начинающаяся с символа «#», не конфликтующего с ключевым словом, должна восприниматься как комментарий, то другие системы, имеющие интерфейс электронных таблиц, соответствующий спецификациям настоящего стандарта, должны обрабатывать указанные строки как комментарии и это не должно привести к возникновению проблем в указанных системах. В данном случае рассматриваемому классу соответствия электронных таблиц должно быть задано соответствующее целое число, например два (2), с последующей инструкцией: «#PARCEL_CC:=2», чтобы разрешить получающей системе проверку возможности конфликта ее дополнительного расширения с ее собственным локальным расширением.

7. Классы соответствия для пакетирования электронных таблиц

Интерфейс электронных таблиц, определенный в настоящем стандарте, может определять структуру электронной таблицы, используемой либо для обмена библиотечными данными, либо для обмена словарными данными. Если указанный интерфейс используется для обмена библиотечными данными, то рассматриваемый класс соответствия, предназначенный для библиотечного обмена по ИСО 13584-25, соответствует классу соответствия CC(11) с расширением, используемым сущностью class_extension для хранения некоторого упорядоченного набора элементов данных вместо элементов данных библиотечного класса dic_class_element.

Если данный интерфейс используется для обмена словарными данными или определениями, то ожидаемый класс соответствия для словарного обмена по ИСО 13584-25 является классом соответствия (CC)4. Он соответствует классу соответствия (CC)5 в настоящем стандарте.

Уровень класса соответствия по ИСО 13584 должен быть указан как класс соответствия пакета после ключевого слова «#PARCEL_CC» в разделе заголовков. Структура электронной таблицы, определенной в настоящем стандарте, имеет в целом нижеследующие классы соответствия, суммированные в таблице 4 (помечены буквами CC).

Таблица 4

Классы соответствия по ИСО 13584-35

Приложение A (справочное)

РЕГИСТРАЦИЯ ИНФОРМАЦИОННОГО ОБЪЕКТА

A.1 Идентификация документа

Для однозначной идентификации информационного объекта в открытой системе настоящему стандарту присвоен идентификатор объекта:

{ISO standard 13584 part (35) version (1)} Смысл данного обозначения определен ИСО/МЭК 8824-1, описание см. в ИСО 13584-1.

Приложение B (справочное)

ФАЙЛ МЕТА-СЛОВАРЯ

Физический файл, содержащий последний выпуск мета-словаря, должен быть доступен по адресу:

http://sp.tc184-sc4.org/SC4Projects/WG2/Shared%20Documents/Parts/ИСО%2013584-035/

Вышеуказанный адрес может также содержать ассоциированные документы, поясняющие определения класса и свойства последнего формального выпуска словаря. Данный файл становится доступным по вышеуказанному адресу после того, как настоящий стандарт переходит в ранг технических условий ISO-TS.

Приложение C (справочное)

РЕЗЕРВНЫЕ СЛОВА

Резервные слова для пакетов, определенные в настоящем стандарте, сведены в таблицу C.1.

Таблица C.1

Ключевые слова инструкций в заголовках классов

Таблица C.2

Ключевые слова инструкции в заголовке схемы

Приложение D (справочное)

ПРИМЕР ОПИСАНИЯ ТИПА ДАННЫХ

Таблица D.1

Пример описания типа данных

Примечание 1 — b1 — значение агрегатированного типа aggregate_TYPE атрибута «bound 1» (граница № 1), b2 — значение атрибута «bound_2» (граница № 2).

Примечание 2 — cmn — значение атрибута «cardinal_min» (главный минимум), cmx — значение атрибута «cardinal_max» (главный максимум).

Примечание 3 — enum_id — глобальный идентификатор перечислимого перечня.

Примечание 4 — code1, code2 — значения кодов value_code для словарного значения dic_value. Указанные значения могут появиться в разделе заголовков для справки. Примечание 5 — Если тип данных комплексный, то он присоединяется к простому типу с помощью ключевого слова «OF».

В таблице E.1 суммированы мета-свойства нормативного мета-класса. Мета-классы словарей, поставщиков, классов и свойств являются обязательными. Все они должны быть в наличии, если словарный обмен производится в формате словарного пакета. Для обновленного и полного перечисления мета-свойств в форме страницы пакетирования читателю рекомендуется обратиться к указателям ресурсов URL, приведенным в Приложении B.

Таблица E.1

Мета-свойства мета-класса словаря

Большая часть свойств мета-класса выражена по типу строки STRING_TYPE. Таким образом, где только возможно, необходимо длину условных обозначений указывать форматом (например, MDC_P024). Например, формат «M..0» обозначает строку любой длины, тогда как формат «M..14» показывает, что длина строки не превышает 14 символов. Если для представления свойства нужен соответствующий язык, то он указывается расширением «». Расширение представляет собой двухбуквенный код по ИСО 639.

Таблица E.2

Мета-свойства мета-класса классов

Таблица E.3

Мета-свойства мета-класса свойств

Таблица E.4

Мета-свойства мета-класса поставщиков

Таблица E.5

Мета-свойства мета-класса перечислений

Таблица E.6

Мета-свойства мета-класса типов данных

Таблица E.7

Мета-свойства мета-класса документов

Приложение F (справочное)

МЕТА-СВОЙСТВА МЕТА-КЛАССОВ ПО ВЫБОРУ

В данном приложении приведен пример расширения стандартного формата пакетирования для учета различных условий и требований путем переработки и уточнения структуры данных по ИСО 13584. Так, элементы мета-класса единиц измерения (как раздел данных пакета единиц измерения UoM) не являются неотъемлемой частью стандарта. Это обеспечивает механизм расширения формата пакетирования для пакета единиц измерения UoM. Если язык, используемый для представления свойства, указывается расширением «», то данное расширение замещается двухбуквенным кодом по ИСО 639.

Таблица F.1

Мета-свойства мета-класса объектов

Таблица F.2

Мета-свойства мета-класса единиц измерения

Таблица F.3

Мета-свойства мета-класса терминологий