ГОСТ Р 54878-2011; Страница 8

или поделиться

Ещё ГОСТы из 41757, используйте поиск в верху страницы

ГОСТ Р ИСО/МЭК 11179-5-2012 Информационная технология. Регистры метаданных (РМД). Часть 5. Принципы наименования и идентификация Information technology. Metadata registries (MDR). Part 5. Naming principles and identification (Настоящий стандарт содержит руководство по наименованию и идентификации следующих администрируемых элементов: понятий элементов данных, концептуальных областей, элементов данных и областей значений. В настоящем стандарте описаны части и структура идентификации. Идентификация понимается в узком смысле, достаточном только для однозначной идентификации указанных администрируемых элементов в пределах регистра. В настоящем стандарте также описано присвоение имен в регистре метаданных (РМД), включая принципы и правила, по которым могут быть разработаны соглашения о наименовании, и приведены примеры соглашений о наименовании. Описанные в настоящем стандарте принципы и правила наименования применяются прежде всего к именам понятий элементов данных, концептуальных областей, элементов данных и областей значений) ГОСТ Р МЭК 62264-1-2010 Интеграция систем управления предприятием. Часть 1. Модели и терминология Enterprise-control system integration. Part 1. Models and terminology (Настоящий стандарт распространяется на принципы организации интерфейсов между функциями управления технологическими процессами и другими функциями предприятия. Рассматриваемые интерфейсы относятся к уровням 3 и 4 иерархической модели, определяемой настоящим стандартом. Цель такого рассмотрения состоит в уменьшении рисков, затрат и ошибок, сопутствующих реализации указанных интерфейсов. Настоящий стандарт может быть использован для сокращения трудозатрат, связанных с внедрением новых коммерческих программных продуктов, обеспечивающих взаимодействие производственных и управляющих систем и упрощающих их интеграцию. Настоящий стандарт распространяется на:. a) наглядное представление совокупности производственных операций и границ системы управления;. b) рассмотрение структуры основных активов предприятия, вовлеченных в производственный процесс;. c) определение перечня функций, обеспечивающих сопряжение функциональной структуры управляющей системы с функциональной структурой предприятия;. d) описание информации, которую одновременно используют и в производственной системе предприятия, и в системе управления) ГОСТ МЭК 60335-2-26-2008 Бытовые и аналогичные электрических приборы. Безопасность. Часть 2-26. Дополнительные требования к часам Household and similar electrical appliances. Safety. Part 2-26. Particular requirements for clocks (Настоящий стандарт устанавливает требования безопасности к электрическим часам (далее - приборы), номинальное напряжение которых не превышает 250 В)

Страница 8

Страница 1

Untitled document

ГОСТ Р 54878—2011/ISO/TS 20625:2002

6.1.2 Вариант 2

При необходимости «разговорные» теги могут формироваться из подходящего комментария. В этом

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

ющего атрибута (см. также 6.9) или любогодругого средства документирования.

Пример -

<xsd:element name ="M_ORDERS’>

<xsd:complexТуре>

<xsd:sequence>

<xsd:element ref="din:Order_number’/>

<xsd:element ref="din:Order_date7>

<xsd:element ref="din:Delivery_date7>

<xsd:element ref="din:Buyer"/>

<xsd:element ref=’din:Seller’/^

<xsd:element ref="din:Currency" minOccurs-"0" maxOccurs="5’f>

<xsd:element ref=’din:Line_item_details’ minOccurs="1’

maxОсейrs="10~/>

<xsd:element ref=’din:Total_order_value"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name ="Name’>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base ="string1..10’>

<xsd:attribute name="EDIPath" type="xsd:stringm

fixed="ORDERS.SG2.NAD.C080.3036(0120:040:01)’/>

<!• - The attribute EDIPath contains the reference to the original EDI

standard - ->

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

6.2 Принцип 2: Структура

6.2.1 Одни и те же EDI-теги или имена должны формировать сгруппированные элементы (см. также

принцип, описанный в6.10).

6.2.2 Если желательно разграничивать различные семантические элементы одного и тогоже контей

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

или присваивать им различные имена.

6.2.3 Схема может содержатьдополнительные «сшитые» между собой элементы для групп сообще

ний или их обмена (сопоставимые с UN/EDIFACT UNG-UNE и UNB-UNZ).

6.2.4 Любое использование ED1-контейнера данных (типа сообщения, группы сегментов, сегментов

и т. п.) может представляться как независимый XML-элемент. Существующая EDI-структура является ис

точником для XML-структуры. поэтому XML-схема должна обладать структурой, сопоставимой со структу

рой EDI MIG. Набор обобщенных XML-элементов не должен превышать набор EDI-элемеитов.

П р и м е ч а н и е — Способ, с помощью которого автор описывает MIG-инструкцию, должен отвечать

требованиям соответствующего бизнес-процесса, поэтому и схема должна соответствующим образом структури

роваться. Если, например, MIG-инструкция содержит ’дату документа" и "запрашиваемую дату поставки" в двух

различных экземплярах DTM-сегмента. то соответственно должны формироваться и раздельные XML-элвменты.

Кроме того, если они документируются в одном и том же экземпляре DTM-сегмента. то будет формироваться

только один XML-элемвнг.