ГОСТ Р 59167-2020 (ИСО/МЭК 19987:2017). Национальный стандарт Российской Федерации. Информационные технологии. Стандарт информационных сервисов EPC (EPCIS)

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

Утвержден и введен в действие

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Предисловие

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 355 «Технологии автоматической идентификации и сбора данных» совместно с ТК 022 «Информационные технологии»

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

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО/МЭК 19987:2017 «Информационные технологии. Стандарт информационных сервисов EPC (EPCIS)» (ISO/IEC 19987:2017 «Information technology — EPC Information Services (EPCIS) Standard», MOD) путем включения раздела «Введение», переименования раздела 1 в «Область применения», перевода раздела «13 Ссылки» в «Библиографию», введения нумерации таблиц и рисунков, а также ссылок на пронумерованные таблицы и рисунки, замены ссылок на международные документы на порядковые номера, приведенные в «Библиографии». В дополнительном приложении ДА приведен перечень сокращений, использованных в настоящем стандарте. Изменения, включенные в текст стандарта, выделены в тексте курсивом и подчеркиванием. Сноски в тексте настоящего стандарта, выделенные курсивом, приведены для пояснения его содержания. Подробная информация об изменениях и пояснения по необходимости их внесения приведены в дополнительном приложении ДБ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе „Национальные стандарты“, а официальный текст изменений и поправок — в ближайшем выпуске ежегодного информационного указателя „Национальные стандарты“. В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя „Национальные стандарты“. Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)»

Введение

Настоящее введение содержит следующие структурные элементы, приведенные в [&1&]:

• аннотацию к документу [&2&],
• протокол изменений в [2],
• отказ от ответственности.

Аннотация к документу [&2&]

Отказ от ответственности

В соответствии с Положением о политике в сфере интеллектуальной собственности GS1 стремится избежать неопределенности в отношении претензий, связанных с интеллектуальной собственностью. С этой целью от участников Рабочей группы, разработавшей настоящий стандарт информационных сервисов EPC (EPCIS), требуется согласие на предоставление членам GS1 безвозмездной лицензии или лицензии на обоснованных и недискриминационных условиях (RAND) в отношении необходимых притязаний в соответствии с определением данного термина, приведенным в Положении GS1 о политике в сфере интеллектуальной собственности. Кроме того, обращается внимание на возможность возникновения ситуации, при которой применение одного или нескольких элементов настоящего документа может оказаться в сфере действия патента или иного права интеллектуальной собственности, не предусматривающего необходимого притязания. Подобный патент или право интеллектуальной собственности не является предметом данных лицензионных обязательств GS1. Согласие на предоставление лицензий, предоставляемых в соответствии с Положением GS1 о политике в сфере интеллектуальной собственности, также не распространяется на права интеллектуальной собственности и любые притязания третьих сторон, которые не являлись участниками настоящей Рабочей группы.

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

НАСТОЯЩИЙ ДОКУМЕНТ ПРЕДОСТАВЛЯЕТСЯ «КАК ЕСТЬ» БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ, ВКЛЮЧАЯ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ, ПАТЕНТНОЙ ЧИСТОТЫ, ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ, ИЛИ КАКИХ-ЛИБО ИНЫХ ГАРАНТИЙ, ПРОИСТЕКАЮЩИХ ИЗ НАСТОЯЩЕГО ДОКУМЕНТА. GS1 снимает с себя всякую ответственность за любые убытки, проистекающие из использования или ненадлежащего использования настоящего стандарта, включая фактические, непрямые, косвенные и компенсаторные убытки, а также включая ответственность за нарушение каких-либо прав интеллектуальной собственности, связанное с использованием информации, содержащейся в настоящем документе, или основанное на использовании настоящего документа.

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

GS1 и логотип GS1 являются зарегистрированными товарными знаками GS1 AISBL.

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

Настоящий документ соответствует стандарту GS1 [&2&], который определяет версию 1.2 информационных сервисов EPC (EPC Information Services, EPCIS). Целью EPCIS является предоставление возможности различным приложениям создавать данные о событиях, обеспечивающих прозрачность, и обмениваться ими как внутри предприятий, так и между ними. В конечном счете создание этого общего ресурса направлено на то, чтобы дать возможность пользователям получать общий доступ к физическим и цифровым объектам в рамках соответствующего контекста ведения хозяйственной деятельности.

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

Изначально стандарт EPCIS задумывался как часть более широких попыток расширения сотрудничества между торговыми партнерами путем предоставления общего доступа к детализированной информации о физических или цифровых объектах. Название EPCIS отражает начальные усилия в развитии электронного кода продукции (Electronic Product Code — EPC). Однако следует заметить, что EPCIS не требуют использования номеров электронного кода продукции, так же как и носителей данных радиочастотной идентификации (Radio-Frequency Identification — RFID). EPCIS версии 1.2 даже не требует идентификации на уровне экземпляра (для которого и был изначально разработан электронный код продукции). Стандарт EPCIS применяется для всех ситуаций, в которых данные о событиях, обеспечивающих прозрачность, должны быть получены и размещены в общий доступ, а наличие аббревиатуры «EPC» в наименовании стандарта имеет только историческое значение.

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

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

Настоящий стандарт EPCIS предназначен для совместного использования со стандартом базовой деловой лексики GS1 по &ГОСТ Р 59168& <1>, содержащим определения значений данных, которые могут быть использованы для наполнения структур данных, определенных настоящим стандартом EPCIS. Использование стандартизованной лексики, предоставляемой стандартом БДЛ по &ГОСТ Р 59168&, имеет решающее значение для взаимодействия и для обеспечения выполнения запросов данных путем сокращения числа вариантов того, каким образом различные предприятия выражают общее намерение. Таким образом, при построении данных EPCIS приложения должны в максимально возможной степени использовать стандарт БДЛ по &ГОСТ Р 59168&.

<1> ГОСТ Р 59168-2020 (ИСО/МЭК 19988:2017) «Информационные технологии. Стандарт базовой деловой лексики» является модифицированным по отношению к ИСО/МЭК 19988:2017 [5]. В тексте ИСО/МЭК 19987:2017 [1] вместо ссылок на [5] используется фраза «стандарт базовой деловой лексики GS1» (см. [6]), в то же время [5] соответствует [6] (стандарту базовой деловой лексики GS1 версии 1.2).

Справочное Руководство по внедрению EPCIS и CBV (БДЛ) &[7]& предоставляет дополнительную информацию по построению систем, обеспечивающих прозрачность, с применением EPCIS и CBV (БДЛ), включая подробные сведения о моделировании конкретных деловых ситуаций с использованием данных EPCIS/CBV (БДЛ) и способах обмена такими данными между торговыми партнерами.

2 Взаимосвязь с архитектурой системы GS1

Настоящий раздел в основном состоит из выдержек из документов &[8]& и &[9]& и показывает взаимосвязь стандарта EPCIS с другими стандартами GS1.

2.1 Обзор стандартов GS1

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

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

• стандарты, которые предоставляют средства для идентификации («identify») объектов реального мира, так что они могут становиться объектами электронной информации, которая сохраняется и/или передается конечными пользователями. Стандарты GS1 для идентификации включают стандарты, которые определяют уникальные идентификационные кодовые обозначения (так называемые идентификационные ключи GS1);
• стандарты, которые предоставляют средства автоматического сбора данных («capture»), нанесенные непосредственно на физические объекты, перекидывая мост из мира физических объектов в мир электронной информации. Стандарты сбора данных GS1 включают определения носителей данных штрихового кода и радиочастотной идентификации, которые позволяют прикреплять идентификаторы непосредственно к физическому объекту, а также стандарты, определяющие совместимые интерфейсы устройств считывания, печати и других компонентов аппаратного и программного обеспечения, которые связывают носители данных с приложениями для ведения хозяйственной деятельности;
• стандарты, которые предоставляют средства для обмена данными («share»), как между торговыми партнерами, так и внутри предприятий, обеспечивая основу для электронных бизнес-транзакций, электронной прозрачности физического или цифрового мира, а также других информационных приложений. Стандарты GS1 для обмена информацией включают в себя настоящий стандарт EPCIS, который является стандартом для данных о событиях, обеспечивающих прозрачность. Другими стандартами в группе «обмена данными» являются стандарты для мастер-данных и данных бизнес-транзакций, так же как и стандарты поиска, которые помогают определить, где находятся соответствующие данные по всей цепи поставок, а также доверительные стандарты, которые помогают создать условия для обмена данными с надлежащей безопасностью.

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

2.2 EPCIS во взаимосвязи с уровнями «сбора данных» и «обмена данными»

На &рисунке 1& показана взаимосвязь между настоящим стандартом EPCIS и другими стандартами GS1 в группах «сбор данных» и «обмен данными». (Группа стандартов «идентификация» охватывает данные на всех уровнях этой архитектуры и поэтому не показана.)

&Рисунок 1&

Как показано на &рисунке 1&, интерфейс сбора данных EPCIS (EPCIS Capture Interface) служит мостом между стандартами «сбора данных» и «обмена данными». Интерфейс запросов EPCIS (EPCIS Query Interface) предоставляет данные о событиях, обеспечивающих прозрачность, как для внутренних приложений, так и для обмена с торговыми партнерами.

В центре приложения по сбору данных (Data Capture Application) находится рабочий процесс сбора данных (Data Capture Workflow), контролирующий этап бизнес-процесса, в рамках которого происходит сбор данных. Этот процесс, как правило, имеет собственную логику, специфичную для конкретного приложения. Под рабочим процессом сбора данных на &рисунке 1& показан канал передачи данных между рабочим процессом и носителями данных GS1: символами штрихового кода и радиочастотными метками. Зеленые прямоугольные блоки на &рисунке 1& обозначают стандарты GS1, положения которых могут быть использованы в качестве требований к интерфейсам носителей данных. В верхней части &рисунка 1& расположены интерфейсы между рабочим процессом сбора данных и крупномасштабными корпоративными приложениями. Многие из этих интерфейсов являются специфичными для конкретного приложения или конкретного предприятия, даже с использованием данных GS1 в качестве компоновочных блоков. Тем не менее интерфейс EPCIS является одним из стандартов GS1. Следует обратить внимание, что интерфейсы в верхней части схемы, в том числе и EPCIS, не зависят от носителя данных, используемого в нижней части &рисунка 1&.

Целью данных интерфейсов, а также причиной использования многоуровневой архитектуры для сбора данных является обеспечение разграничения между различными уровнями абстракции. С позиции корпоративного приложения (т.е. верхнего синего прямоугольного блока на &рисунке 1&) приложение сбора данных целиком защищает корпоративное приложение (Enterprise-level Application) от детализации того, как именно происходит сбор данных. Через интерфейсы прикладного уровня (зеленые прямоугольные блоки в верхней части &рисунка 1&) корпоративное приложение взаимодействует с рабочим процессом сбора данных с помощью данных, которые не зависят от носителя данных и в которых все детали взаимодействия между компонентами сбора данных включены в эти данные. На более низком уровне рабочий процесс сбора данных способен различать взаимодействие со сканерами штрихового кода, устройствами опроса радиочастотных меток, с процессом ручного ввода и т.д., но интерфейсы передачи (зеленые прямоугольные блоки в средней части &рисунка 1&) защищают рабочий процесс сбора данных от детализации работы низкоуровневого аппаратного обеспечения, сведений о том, как именно функционируют носители данных. Низкоуровневые интерфейсы (зеленые прямоугольные блоки внизу &рисунка 1&) отображают внутренние подробные сведения о носителе данных. Стандарт EPCIS и уровень «обмена данными» в общем случае отличаются от элементов на уровне сбора данных в трех ключевых аспектах:

1. Сервисы EPCIS имеют дело с накопленными данными (в дополнение к текущим данным). Уровень сбора данных, напротив, ориентирован исключительно на обработку собранных данных в реальном времени.

2. Сервисам EPCIS часто приходится иметь дело не только с исходными данными, полученными от носителей данных, таких как символы штрихового кода и радиочастотные метки, но также с ситуациями, когда процесс сбора данных приобретает дополнительный смысл, связанный с физическим или цифровым миром, а также с конкретными этапами в операционных или аналитических бизнес-процессах. Уровни сбора данных по своей сути носят чисто наблюдательный характер. Несмотря на то, что событие EPCIS содержит большую часть тех же данных группы стандартов «идентификация», что и событие «фильтрации и накопления данных» (Filtering & Collection) или сканирование символа штрихового кода, оно находится на семантически более высоком уровне, поскольку включает в себя понимание контекста ведения хозяйственной деятельности, в котором были получены данные с идентификаторами. Кроме того, не существует никаких требований в отношении непосредственной связи события EPCIS с конкретным физическим носителем данных. Например, событие EPCIS может свидетельствовать о том, что скоропортящийся предмет торговли только что превысил срок годности. Такое событие может целиком генерироваться программным обеспечением.

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

2.3 Стандарт EPCIS во взаимосвязи с торговыми партнерами

Стандарты GS1 на уровне «обмена данными» относятся к трем категориям данных, которые разделены между конечными пользователями (&см. таблицу 1&).

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

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

&Рисунок 2&

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

2.4 Стандарт EPCIS во взаимосвязи с другими компонентами архитектуры системы GS1

Ниже приведено описание того, за что ответственен каждый элемент архитектуры системы GS1, проиллюстрированной на рисунках в предыдущих разделах. Дополнительную информацию можно найти в документе &[9]&, из которого заимствованы вышеприведенная схема и большая часть текста, а также в документе &[8]&, из которого заимствована большая часть нижеследующего текста подраздела 3.4:

• Устройства считывания штрихового кода и радиочастотных меток. Производят опрос радиочастотных меток в момент их нахождения в зоне считывания, а также сканирование символов штрихового кода после запуска процесса считывания.
• Интерфейс низкоуровневого протокола устройства считывания радиочастотной идентификации (Low-Level RFID Reader Protocol (LLRP) Interface). Определяет порядок контроля и передачи первичных данных радиочастотных меток от устройств считывания радиочастотной идентификации к устройству, выполняющему роль фильтрации и накопления данных. События в этом интерфейсе имеют следующий формат: «устройство считывания A обнаружило номер EPC X в момент времени T».
• Фильтрация и накопление. Эта функция фильтрует и накапливает сведения о первичных актах считывания радиочастотных меток через интервалы времени, ограниченные событиями, определяемыми приложением EPCIS сбора данных (например, срабатывание датчика движения). Для считывания символов штрихового кода подобной функции, как правило, не существует, так как устройства считывания символов штрихового кода обычно производят единичное считывание при запуске.
• Интерфейс фильтрации и накопления данных (событий уровня приложения, Application-Level Events — ALE). Определяет порядок контроля и передачи отфильтрованных и накопленных данных радиочастотных меток от функции фильтрации и накопления данных к функции рабочего процесса сбора данных. События в этом интерфейсе имеют следующий формат: «на логическом устройстве считывания L, в интервале времени между T1 и T2, были обнаружены следующие номера EPC», где список номеров EPC не имеет дубликатов и отфильтрован по критерию, определенному приложением EPCIS сбора данных. В случае символов штрихового кода подобные данные направляются к функции рабочего процесса сбора данных непосредственно от устройства считывания символов штрихового кода в форме строки элемента (Element String) GS1.
• Рабочий процесс сбора данных. Управляет функционированием элементов архитектуры нижнего уровня, а также предоставляет контекст хозяйственной деятельности путем координации с другими источниками информации, участвующими в выполнении конкретного этапа бизнес-процесса. Рабочий процесс сбора данных может, например, координировать конвейерную систему с событиями типа «фильтрация и накопление данных» и актами считывания символов штрихового кода, может проверить наличие исключительных условий и принять меры по исправлению ситуации (например, перенаправление дефектных объектов в область доработки), может представлять информацию для человека-оператора, и т.д. Рабочий процесс сбора данных воспринимает этап или этапы бизнес-процесса, во время которых происходит сбор данных о событиях EPCIS. Эта функция может быть сложной, предполагающей объединение нескольких событий фильтрации и накопления данных и/или актов считывания символов штрихового кода с одним или несколькими событиями хозяйственной деятельности, как это происходит при погрузке партии товара, или может быть такой же простой, как в бизнес-процессе инвентаризации, где могут применяться устройства считывания, которые сканируют объекты, поступающие на полку или покидающие ее. Здесь событие уровня фильтрации и накопления данных, или акты считывания символов штрихового кода, и событие уровня EPCIS могут быть настолько похожи, что на уровне рабочего процесса сбора данных требуется незначительная обработка, и рабочий процесс сбора данных просто конфигурирует и маршрутизирует события от интерфейса фильтрации и накопления данных и/или устройств считывания символов штрихового кода непосредственно через интерфейс сбора данных EPCIS в репозиторий EPCIS или в приложение для хозяйственной деятельности. В рамках настоящего стандарта рабочий процесс сбора данных, основные выходные данные которого состоят из событий EPCIS, называют «приложением EPCIS сбора данных» (EPCIS Capturing Application).
• Интерфейс EPCIS. Представляет собой интерфейс, через который производится передача данных EPCIS к функциям на уровне предприятий, включая репозитории EPCIS (EPCIS Repositories), приложения EPCIS доступа (EPCIS Accessing Applications), а также обмен данными с партнерами. События в таких интерфейсах выражают, например, таким образом: «В месте нахождения X, в момент времени T, были проверены следующие объекты (коробки), содержащиеся в объединяющем их объекте (поддоне)». В этом случае присутствуют три интерфейса EPCIS. Интерфейс сбора данных определяет доставку событий EPCIS от приложений сбора данных к другим функциям, которые используют данные в реальном времени, включая репозитории EPCIS, а также производит принудительную передачу данных (режим «push» («принудительная доставка»)) в режиме реального времени к приложениям доступа и к торговым партнерам. Интерфейс управления запросами EPCIS (EPCIS Query Control Interface) определяет средства получения последовательности данных EPCIS для приложений доступа и торговых партнеров, как правило, путем взаимодействия с репозиторием EPCIS. Интерфейс управления запросами EPCIS предоставляет два режима взаимодействия. В режиме «по требованию» или в синхронном режиме клиент делает запрос через интерфейс управления запросами EPCIS и сразу же получает ответ. В режиме «длительный запрос» или асинхронном режиме клиент устанавливает подписку для периодического запроса. Каждый раз после выполнения периодического запроса его результаты асинхронно (или принудительно, режим «push» («принудительная доставка»)) доставляются получателю через интерфейс обратных вызовов по запросам EPCIS» (EPCIS Query Callback). Интерфейс обратных вызовов по запросам EPCIS может также использоваться для немедленной передачи информации. Это соответствует стрелке «возможный параллельный путь для принудительной доставки в режиме реального времени» на &рисунке 1&. Обязательные требования к трем интерфейсам EPCIS определены в настоящем стандарте.
• Приложение EPCIS доступа. Отвечает за выполнение всех бизнес-процессов предприятия, таких как управление складом, отгрузка и приемка, временной анализ пропускной способности и так далее, опираясь на данные, связанные с номером EPC.
• Репозиторий EPCIS. Фиксирует события уровня EPCIS, генерируемые одним или несколькими приложениями EPCIS сбора данных, а также делает их доступными для дальнейших запросов с помощью приложений EPCIS доступа.
• Партнерское приложение. Системы торгового партнера, которые выполняют те же функции, что и приложения EPCIS доступа, но извне по отношению к сети партнерской стороны. Партнерским приложениям может быть предоставлен доступ к той части информации, которая доступна из приложения EPCIS сбора данных или внутри репозитория EPCIS.

Интерфейсы внутри данного множества разработаны для изолирования высоких уровней архитектуры от необязательных подробных сведений о том, как реализованы более низкие уровни. Один из способов понять это — рассмотреть, что происходит, если произведены определенные изменения:

• Низкоуровневый протокол устройства считывания радиочастотной идентификации (LLRP) и строка элемента GS1 изолируют более высокие уровни от необходимости знать, какие протоколы радиочастотной идентификации или символики штрихового кода используются, а также какие марки/модели устройств считывания были выбраны. Если вместо них устанавливаются другие устройства считывания, то информация, посылаемая через их интерфейсы, остается той же самой.
• В ситуациях, когда используется радиочастотная идентификация, интерфейс фильтрации и накопления данных изолирует более высокие уровни от выбора реализации физического уровня, выполненной в отношении того, как радиочастотные метки обнаруживаются и накапливаются и как определяются временные границы событий. Так, если одно устройство считывания радиочастотной идентификации с четырьмя антеннами заменяется на группу из пяти устройств считывания типа «smart antenna» («умная антенна»), оснащенных единственной антенной, события на уровне фильтрации и накопления данных остаются теми же.
• Сервисы EPCIS защищают корпоративные приложения от необходимости понимания деталей выполнения отдельных этапов бизнес-процесса. Например, типовым событием EPCIS является следующее: «В месте нахождения X, в момент времени T, были проверены следующие коробки, находившиеся на следующем поддоне». В реализации хозяйственной деятельности конвейерного типа это может соответствовать одному событию уровня фильтрации и накопления данных, в котором данные актов считывания накапливаются в течение интервала времени, начало и конец которого регулируются событием пересечения объектом зоны контроля электронных оптических датчиков, установленных на конвейере и объединенных с устройством считывания. В то же время в другой реализации могут быть привлечены три физически крепких человека, которые будут перемещать объекты и использовать мобильные ручные устройства считывания для считывания радиочастотных меток. На уровне фильтрации и накопления данных эти события выглядят иначе (каждое срабатывание ручного мобильного устройства считывания похоже на отдельное событие фильтрации и накопления данных), и обработка, выполненная приложением EPCIS сбора данных, также отличается (возможно привлечение интерактивного пульта управления, который персонал использует для проверки работы). Однако событие EPCIS остается все тем же для обеих реализаций.

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

3 Принципы спецификации EPCIS

Факторы, приведенные в двух предыдущих разделах, показывают, что требования, предъявляемые к стандартам на уровне EPCIS, значительно сложнее, чем на уровне сбора данных архитектуры системы GS1. Историческая природа данных EPCIS предполагает, что для интерфейсов EPCIS требуется более богатый набор методов доступа, чем для интерфейсов событий уровня приложения (ALE) или радиочастотной идентификации (RFID) и устройств считывания символов штрихового кода. Включение эксплуатационного контекста или контекста бизнес-процесса в EPCIS подразумевает то, что спецификации EPCIS имеют дело с более богатым набором типов данных, и, кроме того, они должны быть гораздо более открытыми для расширения с учетом широкого спектра бизнес-процессов, существующих в мире. Функционирование сервисов EPCIS в разнообразной среде подразумевает, что в стандарте EPCIS уровни проработаны настолько тщательно, что даже тогда, когда сервисы EPCIS используются между внешними системами, которые значительно отличаются в деталях работы, должна существовать согласованность и функциональная совместимость на уровне представления абстрактных структур данных, а также значений этих данных.

В ответ на эти требования стандарт EPCIS представляет собой рамочную спецификацию и более узкие и детальные спецификации, которые ее наполняют. Указанная рамочная спецификация должна быть:

• Многоуровневой. В частности, структура и значение данных в абстрактном смысле задаются отдельно от конкретных деталей услуг доступа к данным и привязок к конкретным протоколам интерфейса. Это допускает вариации в конкретных деталях с течением времени и между предприятиями, сохраняя при этом общий смысл самих данных. Это также допускает повторное использование спецификаций данных EPCIS в других подходах, отличных от ориентированного на сервисы подхода настоящей спецификации. Например, определения данных могут быть повторно использованы в рамках электронного обмена данными.
• Расширяемой. Основные спецификации предоставляют не только базовый набор типов данных и операций, но также предусматривают некоторые средства, с помощью которых базовый набор может быть расширен для целей, характерных для данной отрасли или области применения. Расширения отвечают не только собственным требованиям, которые предусматривают использование, насколько это возможно, большего числа стандартных структур, но и позволяют стандартам развиваться и расширяться с течением времени естественным путем.
• Модульной. Механизмы образования уровней и механизмы расширяемости позволяют устанавливать требования к различным частям общей структуры EPCIS в разных документах, а также обеспечивать согласованность в рамках всей структуры. Это способствует расширению процесса стандартизации (так же, как и процесса реализации).

Остальная часть настоящего стандарта определяет структуру EPCIS. Она также описывает базовый набор типов данных и интерфейсов данных, заполняющих данную структуру. Сопровождающий стандарт базовой деловой лексики GS1 по &ГОСТ Р 59168& предоставляет дополнительные определения данных в дополнение к предусмотренным настоящим стандартом.

4 Терминология и условные обозначения

В рамках настоящего стандарта термины ДОЛЖЕН (SHALL), НЕ ДОЛЖЕН (SHALL NOT), СЛЕДУЕТ (рекомендуется) (SHOULD), НЕ СЛЕДУЕТ (не рекомендуется) (SHOULD NOT), МОЖЕТ (разрешается) (MAY), НЕ ОБЯЗАТЕЛЬНО ДОЛЖЕН (не требуется) (NEED NOT), МОЖЕТ (способен) (CAN) и НЕ МОЖЕТ (не способен) (CANNOT) будут интерпретироваться согласно [&10&, приложение G]. В случае использования вышеуказанным образом данные термины будут всегда приведены в записи ПРОПИСНЫМИ БУКВАМИ; в случае записи строчными буквами их следует понимать в обычном значении слов.

Все разделы настоящего документа, за исключением разделов 2, &3 <1>& и 4, являются нормативными, кроме случаев, когда в тексте документа прямо указано иное.

<1> В [1] приведена ошибочная ссылка на «раздел 33».

В настоящем документе используются следующие соглашения о типографских обозначениях:

• записи ПРОПИСНЫМИ БУКВАМИ используются для специальных терминов, приведенных из вышеуказанной спецификации &[10]&;
• шрифт Courier используется для выделения идентификаторов на языке программирования, унифицированном языке моделирования (UML) и расширяемом языке разметки (XML), а также в тексте XML-документов.

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

5 Структура спецификации EPCIS

Спецификация EPCIS является многоуровневой, расширяемой и модульной.

5.1 Уровни

Структура спецификации EPCIS представлена на нескольких уровнях, как показано &на рисунке 3&.

&Рисунок 3&

Уровни (&представленные на рисунке 3&) описаны ниже:

• Уровень абстрактной модели данных (Abstract Data Model Layer). Уровень абстрактной модели данных определяет общую структуру данных EPCIS. Это единственный уровень, который не расширяется никакими другими механизмами, кроме как пересмотром самой спецификации EPCIS. Уровень абстрактной модели данных определяет общие требования к созданию определений данных в рамках уровня определения данных.

• Сервисный уровень (Service Layer). Сервисный уровень определяет служебные интерфейсы, через которые взаимодействуют клиенты EPCIS. В данной спецификации описаны два модуля сервисного уровня. Модуль основных операций сбора данных (Core Capture Operations Module) определяет служебный интерфейс (интерфейс сбора данных EPCIS), через который приложения сбора данных доставляют типы основных событий (Core Event Types) заинтересованным сторонам. Модуль основных операций с запросами (Core Query Operations Module) определяет служебные интерфейсы: интерфейс EPCIS управления запросами и интерфейс EPCIS обратных вызовов по запросам, которые используют приложения EPCIS доступа для получения предварительно собранных данных. Определения интерфейсов сервисного уровня даны абстрактно с использованием языка UML.
• Привязки (Bindings). Привязки определяют конкретные реализации уровня определения данных и сервисного уровня. Для любого определения данных или сервисного модуля может быть определено множество привязок. В данной спецификации для трех модулей, указанных в определении данных и сервисных уровнях, заданы в общей сложности девять привязок. Определения данных в модуле определения данных типов основных событий получают привязку к схеме XML. Интерфейс EPCIS для сбора данных в модуле основных операций сбора данных получает привязки к очереди сообщений (Message Queue) и HTTP. Интерфейс EPCIS для управления запросами в модуле основных операций с запросами (Core Query Operations Module) получает привязку к протоколу SOAP через HTTP с помощью языка описания веб-сервисов WSDL, а также вторую привязку для протокола AS2. Интерфейс обратных вызовов по запросам в модуле основных операций с запросами получает привязки к протоколам HTTP, HTTPS и AS2.
• Стандарт базовой деловой лексики GS1 (GS1 Core Business Vocabulary Standard). Стандарт базовой деловой лексики (БДЛ) по &ГОСТ Р 59168& является дополнением к настоящему стандарту EPCIS. Он определяет конкретные лексические элементы, которые могут быть использованы для заполнения определений данных, указанных на уровне определения данных EPCIS. В то время как EPCIS может применяться без БДЛ, используя только конфиденциальные или частные значения данных, для приложений EPCIS гораздо выгоднее максимально использовать стандарт БДЛ &по ГОСТ 59168&.

5.2 Расширяемость

Многоуровневая методика спецификации способствует расширяемости, поскольку один уровень может быть повторно использован более чем в одном варианте реализации на другом уровне. Например, в то время, как данная спецификация включает в себя привязку XML к модулю определения данных типов основных событий, другая спецификация определяет привязку к такому же модулю с другим синтаксисом, например к файлу CSV <1>.

<1> CSV (от англ. Comma-Separated Values — значения, разделенные запятыми) — текстовый формат, предназначенный для представления табличных данных.

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

• создание производного класса (Subclassing). Данные на уровне определения данных задают с использованием языка UML, который позволяет представить определение новых данных с помощью создания подкласса существующего определения. Подкласс — это новый тип данных, который включает в себя все поля существующего типа, дополняя его новыми полями. Экземпляр подкласса может использоваться в любом контексте, в котором предполагалось использовать экземпляр порождающего класса;
• точки расширения (Extension Points). Определения данных и служебные спецификации включают также точки расширения, которые поставщики могут использовать для расширения функциональности без создания подклассов.

5.3 Модульность

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

Поскольку спецификации EPCIS являются модульными, требований в отношении того, что границы модуля спецификаций в рамках реализаций EPCIS должны быть фиксируемыми или явными, не существует. Примером может служить конкретный программный продукт, который представляет собой основанную на протоколах SOAP/HTTP реализацию ассоциативного сервиса коробка — поддон и сервиса каталога продукции, передающего данные, указанные в соответствующих модулях определения данных. Этот продукт может соответствовать целым шести различным модулям из стандарта EPCIS: модулю определения данных, описывающему данные каталога продукции, модулю определения данных, который задает объединение коробка — поддон, спецификации для соответствующих сервисов, а также соответствующих привязок SOAP/HTTP. Но исходное кодовое значение изделия может не обеспечивать прослеживания этих границ, и на самом деле конкретная схема базы данных, используемая для изделия, может внести дезорганизацию в данные таким образом, что данные каталога продукции и данные объединения коробка — поддон оказываются неразрывно переплетены. Однако, пока конечный результат соответствует спецификациям, данная реализация допускается.

6 Уровень абстрактной модели данных

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

6.1 Данные о событии и мастер-данные

В целом стандарт EPCIS имеет дело с двумя видами данных: данные о событиях (event data) и мастер-данные (master data). Данные о событиях возникают в ходе выполнения бизнес-процессов, собираются через интерфейс EPCIS сбора данных (EPCIS Capture Interface) и становятся доступными для запроса через интерфейсы EPCIS запросов (EPCIS Query Interfaces). Мастер-данные являются дополнительными данными, которые обеспечивают необходимый контекст для интерпретации данных о событиях. Они доступны для запроса через интерфейс EPCIS управления запросами (EPCIS Query Control Interface), но средства, с помощью которых мастер-данные поступают в систему, не указаны в стандарте EPCIS.

Уровень абстрактной модели данных не пытается определить значение терминов «данные о событиях» или «мастер-данные», а лишь предоставляет точные определения структур данных, которые используются спецификацией стандарта EPCIS. Ответственность за моделирование информации о хозяйственной деятельности, связанной с объектами реального мира, такими как данные о событиях и мастер-данные, несет уровень определения данных, а также отраслевые соглашения и соглашения конечных пользователей, которые основываются на данном документе.

Примечание - В то время как для целей настоящей спецификации термины «данные о событиях» и «мастер-данные» означают не более чем «данные, которые соответствуют представленной здесь структуре», структуры, определенные на уровне абстрактной модели данных, предназначены для обеспечения надлежащего представления для данных, обычно требующих обмена через EPCIS. Неформально эти два типа данных можно понимать следующим образом. Объем данных о событиях растет по мере роста количества бизнес-транзакций, а также соотносится с ситуациями, которые происходят в конкретные моменты времени. Примером данных о событиях является: «В 13:23 15 марта 2004 года номер EPC X был обнаружен в месте нахождения L». Объем мастер-данных обычно не увеличивается только лишь с ростом числа бизнес-транзакций (хотя мастер-данные имеют тенденцию возрастать одновременно с увеличением размера организации), как правило, они не привязаны к конкретным моментам времени (хотя мастер-данные могут медленно изменяться с течением времени), а также обеспечивают интерпретацию элементов данных о событиях. Примером мастер-данных является: «Место нахождения L относится к распределительному центру, расположенному по адресу 123 Elm Street, Anytown, USA». Все данные в наборе вариантов использования, рассмотренных при создании стандарта EPCIS, могут быть смоделированы как совокупность данных о событиях и мастер-данных такого рода.

Структура данных о событиях и мастер-данных EPCIS показана на &рисунке 4&. (Следует обратить внимание, что это только пример: специфические лексические элементы и имена атрибутов мастер-данных, показанных на этом рисунке, не определены в настоящей спецификации.)

&Рисунок 4&

Составные части абстрактной модели данных EPCIS определены ниже:

- Данные о событии (Event Data): набор событий.

• Событие (Event): структура, состоящая из типа события и одного или нескольких упомянутых полей события.
• Тип события (Event Type): имя, ограниченное пространством имен qname (qualified name — составное имя) и показывающее, которой из нескольких возможных структур (заданных на уровне определения данных) соответствует данное событие.

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

• Мастер-данные (Master data): набор лексиконов вместе с атрибутами мастер-данных, связанных с элементами этих лексиконов.
• Лексикон (Vocabulary): поименованный набор идентификаторов. Имя лексикона принадлежит пространству имен qname и может использоваться как имя типа для поля события. Идентификаторы внутри лексикона называются лексическими элементами. Лексикон представляет собой набор альтернативных значений, которые могут отображаться в виде значений конкретных полей события. Лексиконы в EPCIS используются для моделирования таких наборов, как набор имен доступных мест нахождения, набор доступных имен этапов бизнес-процессов и так далее.
• Лексический элемент (Vocabulary Element): идентификатор, который именует одну из альтернатив, моделируемых с помощью лексикона. Значение поля события может быть лексическим элементом. Лексические элементы представлены как унифицированные идентификаторы ресурсов (URIs). Каждый лексический элемент может быть связан с атрибутами мастер-данных.
• Атрибуты мастер-данных (Master data attributes): неупорядоченный набор пар имя/значение, связанный с индивидуальным лексическим элементом. Имя, как часть этой пары, принадлежит пространству имен qname. Значение, как часть той же пары, может быть значением произвольного типа. Специальным атрибутом (возможно, пустым) является список потомков (children), причем каждый из потомков (child) является еще одним лексическим элементом этого же лексикона (см. 6.5).

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

В то время как интерфейс EPCIS сбора данных и интерфейсы EPCIS запросов не предоставляют приложению никаких средств для явного запроса на удаление события, репозитории EPCIS МОГУТ применять правила хранения данных, при которых по истечении некоторого периода времени устаревшие события EPCIS становятся недоступными.

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

6.1.1 Передача мастер-данных в EPCIS

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

Настоящий стандарт EPCIS устанавливает четыре механизма передачи мастер-данных, описание которых приведено в таблице &2&:

6.2 Категории лексики

• Типовая лексика (Standard Vocabulary): типовая лексика представляет собой набор лексических элементов, определения и значения которых должны быть согласованы торговыми партнерами, которые будут обмениваться данными о событиях с использованием этой лексики. Например, уровень определения мастер-данных EPCIS (EPCIS Core Data Definition Layer) определяет лексикон, называемый «бизнес-этапы» (business step), элементами которого являются идентификаторы, обозначающие такие понятия, как «отгрузка», «приемка» и так далее. Один из торговых партнеров может создать событие с бизнес-этапом «отгрузка», а другой партнер, получив это событие посредством запроса, сможет интерпретировать его в силу предшествующего соглашения о смысловом значении лексического элемента «отгрузка».

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

• Пользовательская лексика (User Vocabulary): пользовательская лексика представляет собой набор лексических элементов, определение и значение которых находятся под контролем одной организации. Например, уровень определения мастер-данных EPCIS определяет лексикон, называемый «производственное место назначения» («business location»), элементами которого являются идентификаторы, обозначающие такие объекты, как «организация Acme Corp., распределительный центр № 3». Организация Acme Corp. может генерировать событие с местом нахождения, где проводится хозяйственная деятельность «организация Acme Corp., распределительный центр № 3», а другой партнер, получив это событие посредством запроса, может интерпретировать его, либо соотнеся с другими событиями, имеющими то же место нахождения, либо сравнивая с атрибутами мастер-данных, связанных с этим местом нахождения, либо используя оба указанных способа.

Элементы пользовательской лексики главным образом определяются отдельными организациями конечных пользователей, действующими независимо. Мастер-данные, связанные с элементами пользовательской лексики, как правило, определяют те же организации и обычно распространяют среди торговых партнеров посредством интерфейса EPCIS для запросов или других механизмов обмена/синхронизации данных. Новые лексические элементы в рамках какого-либо пользовательского лексикона вводятся исключительно по усмотрению конечного пользователя, и торговые партнеры должны быть готовы реагировать соответствующим образом. Обычно правила построения новых пользовательских лексических элементов устанавливаются организациями с большим числом конечных пользователей, и в любом случае они должны следовать правилам, указанным в 6.4.

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

Стандарт базовой деловой лексики GS1 (БДЛ) &ГОСТ Р 59168& предоставляет типовые лексические элементы для многих видов лексиконов, используемых в типах событий EPCIS. В частности, &ГОСТ Р 59168& определяет лексические элементы для следующих видов типовых лексиконов EPCIS: бизнес-этап (Business Step), состояние (Disposition), тип документа бизнес-транзакции (Business Transaction Type), а также тип начального/конечного пункта (Source/Destination Type). &ГОСТ Р 59168& также определяет шаблоны для построения лексических элементов для следующих видов пользовательской лексики EPCIS: объектов (EPC), объектов на уровне классов (EPCClass), мест нахождения (Location) [мест считывания (Read Point) и производственных мест назначения (Business Location)], идентификаторов документов бизнес-транзакции (Business Transaction ID), идентификаторов (ID) начальных/конечных пунктов (Source/Destination ID) и идентификаторов преобразований (Transformation ID).

6.3 Механизмы расширения

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

• Новый тип события. Новый тип события может быть добавлен на уровне определения данных. Добавление нового типа события требует расширения каждой привязки определения данных, а также может потребовать расширения интерфейсов для сбора данных и интерфейсов для запросов и их привязок.
• Новое поле события. Новое поле может быть добавлено к существующему типу события на уровне определения данных. Привязки, интерфейс для сбора данных и интерфейсы для запроса, определенные в настоящей спецификации, предназначены для обеспечения такого типа расширения без необходимости внесения изменений в саму спецификацию. (То же самое может быть неверно для других привязок или языков запросов, определенных вне указанной спецификации.)
• Новый вид лексики. Новый вид лексики (&лексикон&) может быть добавлен в набор существующих видов лексики. Никаких изменений в привязках или интерфейсах не требуется.
• Новый атрибут мастер-данных. Имя нового атрибута может быть определено для существующего лексикона. Никаких изменений в привязках или интерфейсах не требуется.
• Новый атрибут мастер-данных на уровне экземпляра/серии (МДЭС от Instance/Lot Master Data, ILMD). Имя нового атрибута может быть определено для использования в мастер-данных на уровне экземпляра/серии (см. 7.3.6). Никаких изменений в привязках или интерфейсах не требуется.
• Новый лексический элемент. Новый элемент может быть добавлен к существующему лексикону.

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

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

&Таблица 3&

6.4 Представление идентификаторов

Уровень абстрактной модели данных (Abstract Data Model Layer) представляет несколько видов идентификаторов, включая имена типов событий (Event Type), имена полей событий (Event Field), имена лексиконов (Vocabulary), лексических элементов (Vocabulary Elements), имена атрибутов мастер-данных (master data Attribute). Поскольку все эти пространства имен открыты для расширения, данная спецификация устанавливает некоторые правила, касающиеся конструкции этих имен, с тем чтобы независимые организации могли создавать расширения, не опасаясь коллизии имен.

Лексические элементы являются субъектом следующих правил. Во всех случаях лексический элемент представлен в виде унифицированного идентификатора ресурса (URI), общий синтаксис которого определен в &[11]&. Типами идентификаторов URI, допустимыми в качестве лексических элементов, являются следующие идентификаторы URI, у которых есть организация-владелец:

- представления идентификатора URI для номеров EPC согласно [&12&, раздел 6]. Организацией — владельцем конкретного идентификатора EPC URI является организация, которой был присвоен префикс предприятия GS1 <1> (или иное агентство выдачи в зависимости от конкретной схемы EPC);

<1> Единственной организацией, уполномоченной GS1 на присвоение префиксов предприятий GS1 на территории Российской Федерации, является Ассоциация автоматической идентификации «ЮНИСКАН/ГС1 РУС» (ГС1 РУС).

• абсолютные унифицированные указатели ресурсов (Uniform Resource Locator, URL) согласно &[13]&. Организацией — владельцем конкретного указателя URL является организация, которая владеет доменным именем в сети Интернет в рамках принадлежащей ей части указателя URL;
• унифицированные имена ресурсов (Uniform Resource Names, URN) согласно &[14]& в пространстве имен oid (object identifier, идентификатор объекта), которые начинаются с номера частного предприятия (Private Enterprise Number, PEN). Организацией — владельцем для идентификаторов OID-URN является организация, которой был присвоен номер PEN;
• унифицированные имена ресурсов согласно &[14]& в пространстве имен epc или epcglobal, кроме тех идентификаторов URI, которые используются для представления номеров электронного кода продукции (EPC) согласно &[12]&. Организацией-владельцем этих имен URN является GS1.

Имена типов событий и имена полей событий представлены как составные имена из пространства имен (qname), состоящие из идентификатора URI и имени. Это имеет прямое представление в привязках XML, что удобно для расширения.

6.5 Иерархические лексиконы

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

Иерархические связи между лексическими элементами представляются через мастер-данные. В частности, идентификатор элемента-родителя, помимо его атрибутов мастер-данных, несет список его идентификаторов элементов-потомков. Каждый идентификатор элемента-потомка ДОЛЖЕН принадлежать тому же лексикону, что и идентификатор элемента-родителя. В приведенном выше примере элемент, называемый «организация Acme Corp. розничный магазин № 3», будет иметь список элементов-потомков, включающий в себя элемент «организация Acme Corp. розничный магазин № 3 дверь № 5».

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

Данный элемент МОЖЕТ быть элементом-потомком более чем одного элемента-родителя. Это позволяет использовать несколько способов группировки лексических элементов. Например, места нахождения могут группироваться как по географическому признаку, так и по функциональному. Однако элемент НЕ ДОЛЖЕН приходиться элементом-потомком самому себе, прямо или косвенно.

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

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

7 Уровень определения данных

Настоящий раздел содержит нормативные спецификации модулей на уровне определения данных (Data Definition Layer).

7.1 Общие правила формирования спецификации модулей уровня определения данных

В настоящем подразделе приводятся общие правила формирования спецификации на уровне определения данных. Эти правила в дальнейшем применяются в 7.2 для определения модуля типов основных событий (Core Event Types Module). Эти правила могут также применяться организациями, намеревающимися разместить свою спецификацию поверх указанной.

7.1.1 Содержимое

В общем случае спецификация модуля определения данных имеет следующие компоненты, которые наполняют структуру абстрактной модели данных, указанной в разделе 6:

• типы значений (Value Types): определения типов данных, которые используют для описания значений полей событий (Event Fields) и атрибутов мастер-данных (master data attributes). Модуль типов основных событий определяет простые типы значений, которые доступны для использования всеми модулями определения данных. Каждый определяемый лексикон также неявным образом является типом значений;
• типы событий (Event Types): определения типов событий, каждое из которых задает название типу события (которое должно быть уникальным для всех типов событий), а также список типовых полей событий для этого типа. Тип события может быть определен как подкласс существующего типа события, а это означает, что новый тип события включает все поля событий существующего типа событий плюс любые дополнительные поля событий, предусмотренных в рамках его спецификации;
• поля событий (Event Fields): определения полей событий внутри типов событий, каждое из которых указывает имя для поля (которое должно быть уникальным среди всех полей данного типа событий) и тип данных для значений этого поля. Определения полей событий внутри модуля определения данных могут быть частью новых типов событий, внесенных этим модулем, или могут расширить типы событий, определенные в других модулях;
• виды лексики (Vocabulary Types): определения видов лексики, каждое из которых задает имя лексикона (которое должно быть уникальным среди всех лексиконов), список типовых атрибутов мастер-данных для элементов этого лексикона и правила построения новых лексических элементов для этого лексикона. (Любые правила, установленные для построения лексических элементов в виде лексикона, должны соответствовать общим правилами, приведенным в 6.4.);

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

- лексические элементы (Vocabulary Elements): Определения лексических элементов, каждое из которых указывает имя (которое должно быть уникальным среди всех элементов в рамках лексикона и соответствовать общим правилам для лексических элементов, указанным в 6.4, так же, как какие-либо конкретные правила, указанные в определении вида лексики), а также дополнительно определяют мастер-данные (конкретные значения атрибутов) для этого элемента.

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

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

7.1.2 Описание

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

&Рисунок 5&

В схеме &на рисунке 5& приведено определение данных для двух типов событий, EventType1 и EventType2 (Тип_Событий_2). Эти типы событий используют четыре типа значений: Type1 (Тип_1), Type2 (Тип_2), DataClass3 (Класс_Данных_3) и DataClass4 (Класс_Данных_4). Типы Type1 (Тип_1) и Type2 (Тип_2) являются простыми типами, в то время как типы DataClass3 (Класс_Данных_3) и DataClass4 (Класс_Данных_4) являются сложными типами, структура которых также установлена в UML.

Тип события EventType1 в этом примере имеет четыре поля. Поля Field1 (Поле_1) и Field2 (Поле_2) имеют простые типы Type1 (Тип_1) и Type2 (Тип_2) соответственно. Тип EventType1 (Тип_Событий_1) имеет другое поле Field3 (Поле_3) с типом DataClass3 (Класс_Данных_3). Наконец, тип EventType1 (Тип_Событий_1) имеет другое поле Field4 (Поле_4), которое содержит список из 0 или более экземпляров типа DataClass4 (Класс_Данных_4) (нотация «0..*» означает «больше или равно нулю»).

Данная схема также показывает определение данных для EventType2 (Тип_Событий_2). Стрелка с открытым треугольным наконечником показывает, что тип EventType2 (Тип_Событий_2) является подклассом типа EventType1 (Тип_Событий_1). Это означает, что тип EventType2 (Тип_Событий_2) на самом деле имеет пять полей: четыре поля, наследуемые от типа EventType1 (Тип_Событий_1), плюс пятое поле field5 (Поле_5) типа Type1 (Тип_1).

В рамках описаний языка UML обозначение <> (<<точка расширения>>) определяет место, где реализации ДОЛЖНЫ предусматривать расширяемость за счет добавления новых элементов данных. (Когда один тип имеет точку расширения, а другой тип определен как подкласс первого типа и также имеет точку расширения, то это не означает, что второй тип имеет две точки расширения, скорее это просто указывает на то, что второй тип также открыт для расширения.) Механизмы расширяемости ДОЛЖНЫ предусматриваться как для собственных расширений поставщиками продуктов, совместимых с EPCIS, так и для расширений, определенных стандартом GS1, посредством будущих версий настоящей спецификации или посредством новых спецификаций.

В случае стандартных привязок точки расширения XML реализованы в схеме XML в соответствии с методологией, описанной в 9.1.

Все определения типов событий ДОЛЖНЫ включать точку расширения, чтобы обеспечить расширяемость, описанную в 6.3 («новые поля событий»). Типы значений МОГУТ включать точку расширения.

7.1.3 Семантика

Каждое событие (экземпляр типа события) кодирует несколько утверждений, которые в совокупности определяют семантику события. Некоторые из этих утверждений говорят о том, что было верно в момент времени, когда было зафиксировано событие. Другие утверждения говорят о том, что, как предполагается, будет верным после наступления события до тех пор, пока оно не будет аннулировано последующим событием. Они называются соответственно ретроспективная семантика (retrospective semantics) события и перспективная семантика (prospective semantics) события. Например, если предмет (widget) № 23 перемещается в здание № 5 через дверь № 6 в 23:23, то ретроспективное утверждение звучит так: «предмет № 23 зафиксирован у двери № 6 в 23:23», тогда как перспективное утверждение звучит так: «предмет № 23 находится в здании № 5». Ключевым отличием является то, что ретроспективное утверждение ссылается на конкретный момент времени в прошлом («предмет № 23 зафиксирован...»), в то время как перспективное утверждение является утверждением о текущем состоянии объекта («предмет № 23 находится в ...»). Перспективное утверждение предполагает, что если предмет № 23 когда-либо покинет здание № 5, то будет записано другое событие EPCIS, чтобы заменить предшествовавшее событие.

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

Раздвоение на ретроспективное/перспективное играет важную роль в определении места нахождения по EPCIS в 7.3.4.

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

7.2 Модуль типов основных событий — обзор

Модуль определения данных типов основных событий (Core Event Types) определяет типы событий, которые представляют собой события сбора данных EPCIS (EPCIS data capture events). Эти события, как правило, генерируются приложением EPCIS сбора данных и предоставляются инфраструктуре EPCIS посредством операций, указанных в 8.1. Эти события возвращаются также в ответ на операции запроса, которые извлекают события в соответствии с критерием запроса.

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

• типы событий: это типы событий, как показано ниже на схеме на языке UML и определено в 7.4.1 - 7.4.6;

• типы лексики: это типы, определенные в 7.3.3 - 7.3.5 и обобщенные в 7.2;
• атрибуты мастер-данных: включены как часть определений типов лексики. Предполагается, что отраслевые вертикальные рабочие группы будут определять дополнительные атрибуты мастер-данных для лексиконов, определенных в настоящем стандарте;
• лексические элементы: не предусмотрены в рамках данной спецификации. Предполагается, что отраслевые вертикальные рабочие группы будут определять лексические элементы для лексикона BusinessStep (Бизнес-этап) (см. 7.3.5), лексикона Disposition (Состояние) (см. 7.3.5.2), а также лексикона BusinessTransactionType (Тип_Документа_Бизнес-Транзакции) (см. 7.3.5.3.1).

Данный модуль определяет шесть типов событий: одно общее базовое событие и пять подклассов (один из которых является нежелательным в стандарте EPCIS 1.1 &[4]&, которые могут представлять собой события, возникающие в работе цепи поставок в широком спектре отраслей:

• EPCISEvent (Событие_EPCIS) (см. 7.4.1) является общим базовым классом для всех типов событий как в этом модуле, так и в других;
• ObjectEvent (Событие_с_Объектом) (см. 7.4.1.2) представляет собой событие, которое произошло для одного или нескольких физических или цифровых объектов;
• AggregationEvent (Событие_с_Агрегацией_Объектов) (см. 7.4.3) представляет собой событие, произошедшее для одного или нескольких объектов, которые физически собраны вместе (физически соединены, чтобы быть в одном месте и в одно время, как, например, коробки, собранные на одном поддоне);
• QuantityEvent (Событие_с_Количеством_Объектов) (см. 7.4.4) представляет собой событие, связанное с определенным количеством объектов, разделяющих общий класс EPC, но в котором не указаны ключевые идентификаторы отдельных объектов. Согласно &[4]& (версии 1.1 стандарта EPCIS) это событие является устаревшим. Вместо него следует использовать событие типа ObjectEvent (Событие_с_Объектом) (см. 7.4.1.2) с одним или несколькими элементами QuantityElements (Элементы_Количества) (см. 7.3.3.3);
• TransactionEvent (Событие_с_Документом_Транзакции) (см. 7.4.5) представляет собой событие, в котором один или несколько объектов становятся связанными или разъединенными с одним или несколькими указанными документами бизнес-транзакций;
• TransformationEvent (Событие_с_Преобразованием) (см. 7.4.6) представляет собой событие, в котором входные объекты потребляются полностью или частично, а выходные объекты производятся таким образом, чтобы любой из входных объектов мог способствовать созданию всех выходных объектов.

Схема на языке UML, представляющая указанные типы событий следующим образом, приведена &на рисунке 6&.

Примечание — На схеме &на рисунке 6& некоторые имена сокращены из-за пространственных ограничений; например, на схеме используется имя типа BizLocationID, тогда как фактически данный тип называется BusinessLocationID (Идентификатор_Производственного_Места_Назначения). Нормативные названия полей и их типов см. в тексте настоящего стандарта.

Красным цветом выделен класс или атрибут, который является новым в версии стандарта EPCIS 1.2

0.. 1 = «нуль или один»

0...* = «нуль или более»

1...* = «один или более»

&Рисунок 6&

Каждый из типов основных событий (не считая общий тип EPCISEvent (Событие_EPCIS)) имеет поля, которые представляют собой четыре ключевых параметра любого события EPCIS: (1) объект(ы) или другие сущности, которые являются субъектом события; (2) дата и время; (3) место нахождения, в котором произошло событие; (4) контекст хозяйственной деятельности. Эти четыре параметра можно легко запомнить, как «что», «когда», «где/куда» и «на каком основании» (соответственно). Параметр «что» меняется в зависимости от типа событий (например, для типа ObjectEvent (Событие_с_Объектом) параметр «что» представляет собой один или несколько номеров EPC; для типа AggregationEvent (Событие_с_Агрегацией) параметр «что» представляет собой идентификатор-родитель (ID) или список номеров-потомков EPC). Параметры «где/куда» и «на каком основании» имеют как ретроспективный, так и перспективный аспекты (см. 7.1.3), представленные различными полями.

В таблице &4& приведены поля типов событий, которые относятся к четырем основным параметрам:

&Таблица 4&

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

В таблице &5& приведены виды лексики, определенные в этом модуле. Столбец «Идентификатор URI» предоставляет формальное имя для лексикона, которое используется тогда, когда необходимо ссылаться на имя лексикона через интерфейс EPCIS.

7.3 Модуль типов основных событий — составные части

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

7.3.1 Простые типы

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

&Таблица 6&

Тип значений EPC определяется как простой тип значений для использования в событиях при обращении к номерам EPC, которые не являются частью вида лексики. Например, номер EPC в формате номера SGTIN, используемый для обозначения экземпляра предмета торговли в поле epcList (список_EPC) события типа ObjectEvent (Событие_с_Объектом), является экземпляром простого типа значений EPC. Но номер EPC в формате номера SGLN <1>, используемый как идентификатор места считывания (см. 7.3.4) в поле ReadPoint (Место_Считывания) события типа ObjectEvent (Событие_с_Объектом), является лексическим элементом, а не экземпляром простого типа значений EPC.

<1> SGLN — структура данных GS1, соответствующая глобальному номеру места нахождения GLN, с включением или без опционального расширения, используемая для идентификации физического места нахождения.

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

7.3.2 Тип Action (действие)

Тип Action (Действие) свидетельствует о том, как событие относится к жизненному циклу описываемого объекта. Например, тип событий AggregationEvent (Событие_с_Агрегацией) (см. 7.4.3) используется для событий сбора данных, относящихся к группам объектов, таких как коробки, собранные на поддоне. На протяжении своей жизни поддон с грузом участвует во многих этапах бизнес-процессов, каждый из которых может генерировать событие EPCIS. Поле action (действие) каждого события свидетельствует о том, как сама группа объектов изменилась во время события: были ли к группе добавлены объекты, были ли объекты удалены из группы, или группа была зафиксирована без изменений в ее составе. Поле action (действие) не зависит от значения поля bizStep (бизнес-этап) (типа BusinessStepID (Идентификатор_Бизнес-Этапа)), которое идентифицирует конкретный этап бизнес-процесса, в котором произошло данное действие.

Тип Action (Действие) является перечисляемым типом, имеющим три возможных значения (&см. таблицу 7&).

&Таблица 7&

Приведенное ниже описание для каждого типа события, которое включает значение Action (Действие), говорит более точно, как интерпретируется значение Action (Действие) в контексте этого события.

Следует отметить, что три приведенных выше значения являются единственно возможными значениями для типа Action (Действие). В отличие от других типов, описанных ниже, тип Action (Действие) не является видом лексики, а также НЕ ДОЛЖЕН расширяться отраслевыми группами.

7.3.3 Параметр «что»

Данный подраздел описывает типы данных, используемые в параметре «что» («What») типов событий, указанных в 7.3.5.4.

7.3.3.1 Идентификация на уровне экземпляра в сравнении с идентификацией на уровне класса

Параметр «что» события EPCIS определяет, какие физические или цифровые объекты участвовали в событии. EPCIS предусматривает идентификацию объектов двумя способами:

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

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

Пример - В системе GS1 примерами идентификаторов на уровне экземпляра являются номер GTIN+серийный номер, номер SSCC, идентификатор GRAI с серийным номером, идентификатор GIAI, номер GSRN, и идентификатор GDTI с серийным номером. Примерами идентификаторов на уровне класса являются номер GTIN, номер GTIN+номер партии, идентификатор GRAI без серийного номера и идентификатор GDTI без серийного номера.

7.3.3.2 Номер EPC

Номер электронного кода продукции (Electronic Product Code — EPC) является структурой идентификатора на уровне экземпляра, определенной в стандарте данных радиочастотных меток EPC &[12]&. В параметре «что» события EPCIS значение элемента epc ДОЛЖНО быть в формате идентификатора URI согласно &[11]&, обозначающем уникальный идентификатор на уровне экземпляра для объекта. Если уникальным идентификатором является номер электронного кода продукции, то элементом списка ДОЛЖЕН быть универсальный идентификатор ресурса (URI) с «чистым ключевым идентификатором» для EPC, как указано в [&12&, раздел 6]. Реализации МОГУТ принимать идентификаторы в формате URI, кроме номеров EPC, в качестве значения элемента epc.

7.3.3.3 Структура QuantityElement (Элемент_Количество)

Структура QuantityElement (Элемент_Количество) определяет объекты, идентифицируемые специальным идентификатором на уровне класса, либо с заданным полем quantity, либо с незаданным полем quantity (количество). Структура QuantityElement (Элемент_Количество) приведена &в таблице 8&.

EPCClass (EPC_на_уровне_Класса) является лексиконом, элементы которого обозначают классы объектов. EPCClass (EPC_на_уровне_Класса) является пользовательской лексикой, как это указано в 6.2. На любой номер EPC, структура которого включает в себя понятие класса объектов, можно ссылаться как на EPCClass (номер EPC на уровне класса объектов). Требования для номеров EPC в формате номера SGTIN подробно изложены ниже.

EPCClass (EPC_на_уровне_Класса) может относиться к классу для фиксированной или переменной величины. Класс для фиксированной величины имеет дело с экземплярами, которые могут быть подсчитаны. Например, номер GTIN, который относится к коробкам с продукцией фиксированного размера. Класс для переменной величины имеет дело с экземплярами, которые не могут быть подсчитаны, и потому их количество определяется как физическая мера. Например, номер GTIN, относящийся к медной проволоке, которая продается по длине, ковровому покрытию, которое продается по площади, маслу, которое продается по объему, или свежей плодоовощной продукции, которая продается на вес. В таблице &9& указано, как поля quantity (количество) и uom (единица_измерения) используются в каждом случае:

7.3.3.3.1 UOM (единица измерения)

Как указано выше, поле uom (единица_измерения) структуры QuantityElement (Элемент_Количество) присутствует тогда, когда QuantityElement (Элемент_Количество) использует физическую величину для определения количества указанного EPCClass (EPC_на_уровне_Класса). Если поле uom (единица_измерения) присутствует, его значение ДОЛЖНО быть двух- или трехзначным кодовым значением для физической единицы, указанной в столбце «Общее кодовое значение» («Common Code») Рекомендации 20 СЕФАКТ ООН (UN/CEFACT), см. &[16]&. Кроме того, это кодовое значение ДОЛЖНО соответствовать кодовому значению, содержащемуся в строке в &[3]&, удовлетворяющей следующим критериям:

• столбец «Количество» («Quantity») содержит одно из следующих значений: длина (length), площадь (area), объем (volume) или масса (mass);
• столбец «Статус» («Status») не содержит знак «X» (значение удалено) или знак «D» (значение устарело).

Для оценки по первому критерию значение количества должно появиться как законченная фраза. Например: значение «метр» (MTR, metre) допустимо, поскольку диапазон значений количества включает длину (length) (среди других значений, таких как ширина (breadth), высота (height) и т.д.). &Однако значение «килограмм на метр (kilogram per metre)» (KL) недопустимо, поскольку здесь приведено значение в килограммах, поделенное на длину в метрах, а не просто длина (length).&

7.3.3.3.2 Значения EPCClass (номера EPC на уровне классов объектов) для номеров GTIN

Если лексический элемент в лексиконе EPCClass (EPC_на_уровне_Класса) представляет класс номеров SGTIN EPC, обозначаемый конкретным номером GTIN, то он ДОЛЖЕН представлять собой идентификатор URI в форме, указанной в [&12&], а также в более ранних версиях этого документа, начиная с версии 1.3:

urn:epc:idpat:sgtin:CompanyPrefix.ItemRefAndIndicator.*,

где составляющая CompanyPrefix (Префикс_Предприятия) является префиксом предприятия GS1 в номере GTIN (включая ведущие нули), а составляющая ItemRefAndIndicator (Ссылочный_Номер_Предмета_и_Индикатор) состоит из цифры индикатора, за которой следуют цифры ссылочного номера предмета номера GTIN.

Лексический элемент лексикона EPCClass (EPC_на_уровне_Класса) в этой форме обозначает класс объектов, номера EPC которых являются номерами SGTIN (urn:epc:id:sgtin:...), имеющими те же поля — CompanyPrefix (Префикс_Предприятия) и ItemRefAndIndicator (Ссылочный_Номер_Предмета_и_Индикатор), а также имеющими какой-либо серийный номер (или вообще не имеющими серийного номера).

7.3.3.3.3 Значения EPCClass (номера EPC на уровне классов объектов) для номера GTIN + номера партии/серии

Если лексический элемент в лексиконе EPCClass (EPC_на_уровне_Класса) представляет класс номеров SGTIN EPC, обозначаемый конкретным номером GTIN вместе с номером партии/серии, он ДОЛЖЕН представлять собой идентификатор URI в форме, указанной в [&12&, раздел 6]:

urn:epc:class:lgtin:CompanyPrefix.ItemRefAndIndicator.Lot,

где составляющая CompanyPrefix (Префикс_Предприятия) является префиксом предприятия GS1 в номере GTIN (включая ведущие нули), а составляющая ItemRefAndIndicator (Ссылочный_Номер_Предмета_и_Индикатор) состоит из цифры индикатора номера GTIN, за которым следуют цифры ссылочного номера предмета номера GTIN, и Lot (партия/серия) является номером конкретной партии/серии.

Лексический элемент EPCClass (EPC_на_уровне_Класса) в этой форме обозначает класс объектов, номера EPC которых являются номерами SGTIN (urn:epc:id:sgtin:...), имеющими те же поля CompanyPrefix (Префикс_Предприятия) и ItemRefAndIndicator (Ссылочный_Номер_Предмета_и_Индикатор) и принадлежащими к конкретной партии/серии, независимо от серийного номера (если таковой имеется).

7.3.3.4 Краткий перечень типов идентификаторов (справочная информация)

В данном подразделе приводится краткий перечень идентификаторов, которые могут быть использованы в параметре «что» событий EPCIS. Требования к идентификаторам приведены в стандарте данных радиочастотных меток EPC &[12]& и базовой деловой лексики по &ГОСТ Р 59168& (&см. таблицу 10&).

&Таблица 10&

7.3.4 Параметр «где/куда» — место считывания и производственное место назначения

Настоящий подраздел определяет четыре типа, имеющих отношение к понятию информации о месте нахождения в том виде, как это понятие используется в стандарте EPCIS. Два типа из этих четырех являются способами обращения к «устройствам считывания», или устройствам, которые воспринимают наличие оснащенных радиочастотными метками EPC объектов, с использованием технологии радиочастотной идентификации (RFID) или других средств. Эти типы в действительности не считаются типами «мест нахождения» для целей EPCIS. Они включены в настоящую спецификацию в основном для их противопоставления истинным типам места нахождения (хотя некоторые приложения могут ориентироваться на их использование как полей расширения в процессе наблюдения с целью аудита). Оставшиеся два типа являются действительными типами места нахождения и определены как виды лексики (лексиконы) EPCIS.

В &таблице 11& приведены следующие типы устройств считывания/мест нахождения:

&Таблица 11&

Как указано в 6.2, ReadPointID (Идентификатор_Места_Считывания) и BusinessLocationID (Идентификатор_Производственного_Места_Назначения) являются лексиконами пользовательской лексики. Некоторые отрасли, возможно, отдадут предпочтение использованию номеров EPC в качестве лексических элементов. В этом случае ДОЛЖНЫ использоваться чистые ключевые идентификаторы в формате идентификатора URI, как указано в &[12]&.

Пример — В отраслях, которые руководствуются Общими спецификациями GS1, типы readPointID (Идентификатор_Места_Считывания) и businessLocationID (Идентификатор_Производственного_Места_Назначения) могут иметь вид идентификаторов SGLN-URI по [&12&, пункт 6.3.3], а тип physicalReaderID (Идентификатор_Физического_Устройства_Считывания) может иметь вид идентификатора SGTIN-URI по [&12&, пункт 6.3.1].

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

Примечание - Разрешение использовать идентификаторы URI не в формате EPC для мест нахождения дает организациям большую свободу для повторного использования существующих способов именования мест нахождения.

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

Примечание - В настоящей спецификации логические и физические устройства считывания исключены из описаний событий EPCIS. Информация о физическом устройстве считывания в общем случае не является полезной информацией для обмена между партнерами. Например, если устройство считывания неисправно и меняется на другое устройство считывания идентичной марки и модели, идентификатор физического устройства считывания изменяется. Эта информация не представляет большого интереса для торговых партнеров. Аналогично идентификатор логического устройства считывания может измениться, если организация, ответственная за сбор данных, вносит изменения в порядок выполнения конкретного бизнес-процесса, что, опять-таки, зачастую не представляет интерес для партнера.

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

7.3.4.1 Пример различия между местом считывания и производственным местом назначения (для справки)

&На рисунке 7 приведен пример, представляющий различия между местом считывания и производственным местом назначения.&

На рисунке &7& показан типичный пример использования, в рамках которого имеются помещения с фиксированными дверными проемами на границах помещений. В данном случае места считывания соответствуют дверным проемам (с устройствами радиочастотной идентификации), а производственные места назначения соответствуют помещениям. Следует обратить внимание, что места считывания и производственные места назначения не находятся во взаимно-однозначном соответствии. Единственной ситуацией, когда места считывания и производственные места назначения могут иметь соответствие один к одному, является нетипичный случай комнаты с единственной дверью, например маленькая кладовая.

7.3.4.2 Различие между типами устройств считывания и типами мест нахождения (для справки)

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

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

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

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

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

5. в случае мобильных устройств считывания данное устройство может считывать радиочастотные метки, которыми снабжены объекты, находящиеся в нескольких местах нахождения, при этом для определения конкретного места нахождения, связанного с данным событием считывания, могут использоваться «позиционированные» радиочастотные метки или иные средства;

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

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

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

7.3.5 Параметр «на каком основании»

Данный подраздел определяет типы данных, используемые в параметре «на каком основании» («Why») типов событий, указанных в 7.3.5.4.

7.3.5.1 Бизнес-этап (Business Step)

Вид лексики BusinessStepID (Идентификатор_Бизнес-Этапа) является лексиконом, элементы которого обозначают этапы бизнес-процесса. Примером служит идентификатор, обозначающий «отгрузку» («shipping»). Поле бизнес-этапа события определяет контекст ведения хозяйственной деятельности в рамках события: во время выполнения какого этапа бизнес-процесса было вызвано событие, данные о котором подлежат сбору. Лексикон BusinessStepID (Идентификатор_Бизнес-Этапа) является примером типовой лексики, как указано в 6.2.

Примечание - Использование расширяемого лексикона для идентификаторов бизнес-этапов позволяет стандартам GS1 (включая базовую деловую лексику GS1 по &ГОСТ Р 59168&) определять некоторые общие термины, такие как «отгрузка» («shipping») или «приемка» («receiving»), в то же время позволяя отраслевым группам и индивидуальным конечным пользователям определять свои собственные термины. Мастер-данные предоставляют дополнительную информацию.

Данная спецификация определяет атрибуты мастер-данных для идентификаторов бизнес-этапов.

7.3.5.2 Состояние (Disposition)

Вид лексики DispositionID (Идентификатор_Состояния) — это лексикон, элементы которого обозначают состояние объекта при проведении хозяйственной деятельности. Примером является идентификатор, который обозначает состояние «отозван» («recalled»). Поле состояния какого-либо события определяет условие ведения хозяйственной деятельности объектов события, следующих за событием. Предполагается, что состояние останется действительным до тех пор, пока другое событие не укажет на изменение состояния. Промежуточные события, которые не определяют поле состояния, не оказывают никакого влияния на предполагаемое состояние объекта. Лексикон DispositionID (Идентификатор_Состояния) является примером типовой лексики, как указано в 6.2.

Примечание - Использование расширяемого лексикона для идентификаторов состояния позволяет стандартам GS1 (включая в большей степени базовую деловую лексику GS1 по &ГОСТ Р 59168&) устанавливать некоторые общие термины, такие как «отозван» («recalled») или «в транзите» («in transit»), в то же время позволяя отраслевым группам и индивидуальным конечным пользователям определять свои собственные термины. Мастер-данные могут предоставлять дополнительную информацию.

Данная спецификация не определяет атрибуты мастер-данных для идентификаторов состояния.

7.3.5.3 Документ бизнес-транзакции (Business transaction)

Вид лексики BusinessTransaction (Документ_Бизнес_Транзакции) определяет конкретный документ бизнес-транзакции. Примером документа бизнес-транзакции является конкретный заказ на поставку. Информация о документе бизнес-транзакции может быть включена в события EPCIS для фиксирования приобщения события в конкретном документе бизнес-транзакции.

Документ бизнес-транзакции описан в стандарте EPCIS с помощью структурированного типа, состоящего из пары идентификаторов, как приведено &в таблице 12&.

В следующих подразделах определены два вида лексики: BusinessTransactionTypeID (Идентификатор_Типа_Документа_Бизнес-транзакции) и BusinessTransactionID (Идентификатор_Документа_Бизнес-Транзакции).

7.3.5.3.1 Тип документа бизнес-транзакции (Business transaction type)

Вид лексики BusinessTransactionTypeID (Идентификатор_Типа_Документа_Бизнес-Транзакции) — это лексикон, элементы которого обозначают конкретные типы документов бизнес-транзакций. Примером является идентификатор, обозначающий «заказ на поставку» («purchase order»).

Лексикон BusinessTransactionTypeID (Идентификатор_Типа_Документа_Бизнес-Транзакции) является примером типовой лексики, как указано в 6.2.

Примечание - Использование расширяемого лексикона для идентификаторов типа документа бизнес-транзакции позволяет стандартам GS1 определять некоторые общие термины, такие как «заказ на поставку» («purchase order»), и в то же время предоставляет возможность отраслевым группам и индивидуальным конечным пользователям определять свои собственные термины. Мастер-данные могут предоставлять дополнительную информацию.

Данная спецификация не определяет атрибуты мастер-данных для идентификаторов типов документов бизнес-транзакций.

7.3.5.3.2 Идентификатор документа бизнес-транзакции (Business transaction ID)

Вид лексики BusinessTransactionID (Идентификатор_Документа_Бизнес-Транзакции) — это лексикон, элементы которого обозначают документы бизнес-транзакции. Примером является идентификатор, обозначающий «Acme Corp. purchase order number 12345678» (Заказ на поставку номер 12345678 организации Acme Corp.). Лексикон BusinessTransactionID (Идентификатор_Документа_Бизнес-Транзакции) является пользовательской лексикой, как указано в 6.2.

Примечание - Для обеспечения расширяемости, а также в качестве удобного для организаций способа различения одного типа документа транзакции от другого, используются идентификаторы URI. Например, если организация Acme Corp. имеет заказы на поставку (один тип документа бизнес-транзакции), идентифицируемые с помощью восьмизначного номера, а также поставки (другой тип документа бизнес-транзакции), идентифицируемые с помощью шестизначной строки, и, кроме того, транспортное предприятие PostHaste использует 12-значные идентификаторы отслеживания, тогда с течением времени с конкретным номером EPC могут быть связаны следующие идентификаторы документов бизнес-транзакций:

Пример

http://transaction.acme.com/po/12345678

http://transaction.acme.com/shipment/34ABC8

urn:posthaste:tracking:123456789012

(В этом примере предполагается, что предприятие PostHaste зарегистрировало пространство имен URN «posthaste» в организации IANA (Internet Assigned Numbers Authority — «Администрация адресного пространства Интернет»). Приложение EPCIS доступа может запросить сервисы EPCIS и обнаружить все три идентификатора документов транзакций. Использование идентификаторов URI дает приложению путь к пониманию того, какой из идентификаторов представляет интерес.

7.3.5.4 Начальный пункт и конечный пункт (Source и Destination)

Source (Начальный_Пункт) или Destination (Конечный_Пункт) используются для обеспечения дополнительного контекста ведения хозяйственной деятельности, когда событие EPCIS является частью перемещения в процессе хозяйственной деятельности, то есть процесса, в котором происходит передача прав собственности, ответственности и/или владения физическими или цифровыми объектами.

Во многих случаях перемещение в процессе хозяйственной деятельности требует выполнения нескольких отдельных бизнес-этапов и поэтому нескольких событий EPCIS (например, доставка с последующим получением или более сложная последовательность этапов, такая как погрузка -> отправка -> транспортирование -> прибытие -> разгрузка -> приемка). ReadPoint (Идентификатор_Места_Считывания) и BusinessLocation (Идентификатор_Производственного_Места_Назначения) в параметре «где/куда» («where») этих событий EPCIS указывают известное физическое место нахождения каждого из этапов этого процесса. Source (Начальный_Пункт) и Destination (Конечный_Пункт), напротив, могут быть использованы для указания сторон и/или мест нахождения, которые являются предполагаемыми конечными пунктами перемещения в процессе хозяйственной деятельности. В многоэтапном перемещении в процессе хозяйственной деятельности некоторые или все события EPCIS могут иметь данные Source (Начальный_Пункт) и Destination (Конечный_Пункт), а информация будет одинаковой для всех событий в данном перемещении.

Source (Начальный_Пункт) и Destination (Конечный_Пункт) предоставляют стандартизированный способ представить участвующие стороны и/или физические места нахождения, вовлеченные в перемещение в процессе хозяйственной деятельности, дополняя информацию о документе бизнес-транзакции (например, заказы на поставку, счета-фактуры и т.п.), на которую могут ссылаться с помощью элементов лексикона BusinessTransaction (Документ_Бизнес_Транзакции).

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

Два вида лексики SourceDestTypeID (Идентификатор_Типа_Начального_Пункта_Конечного_Пункта) и SourceDestID (Идентификатор_Начального_Пункта_Конечного_Пункта) определены ниже.

7.3.5.4.1 Тип начального пункта/конечного пункта (Source/Destination)

Вид лексики SourceDestTypeID (Идентификатор_Типа_Начального_Пункта_Конечного_Пункта) — это лексикон, элементы которого обозначают конкретные типы начального пункта и конечного пункта при перемещении в процессе хозяйственной деятельности. Примером является идентификатор, который обозначает «сторону-собственник» («owning party»). Лексикон SourceDestTypeID (Идентификатор_Типа_Начального_Пункта_Конечного_Пункта) является примером типовой лексики, как указано в 6.2.

Примечание - Использование расширяемого лексикона для идентификаторов типов начальных и конечных пунктов позволяет стандартам GS1 устанавливать некоторые общие термины, такие как «сторона-владелец», и в то же время предоставляет возможность отраслевым группам и индивидуальным конечным пользователям определять свои собственные термины. Мастер-данные могут предоставлять дополнительную информацию.

Данная спецификация определяет атрибуты мастер-данных для идентификаторов типов начальных и конечных пунктов.

7.3.5.4.2 Идентификатор начального пункта/конечного пункта (Source/Destination ID)

Вид лексики SourceDestID (Идентификатор_Начального_Пункта_Конечного_Пункта) — это лексикон, элементы которого обозначают конкретные начальные и конечные пункты. Примером является идентификатор, который обозначает организацию «Acme Corporation (в качестве стороны владельца)». Лексикон SourceDestID (Идентификатор_Начального_Пункта_Конечного_Пункта) является примером пользовательской лексики, как указано в 6.2.

7.3.6 Мастер-данные экземпляра/партии (МДЭП)

Мастер-данные экземпляра/партии (МДЭП, ILMD) — это данные, описывающие конкретный экземпляр физического или цифрового объекта, или конкретной серии/партии объектов, которые производятся сериями/партиями. МДЭП состоят из набора описательных атрибутов, предоставляющих информацию об одном или нескольких конкретных объектах или партиях объектов. Они похожи на обычные мастер-данные, которые также состоят из набора описательных атрибутов, предоставляющих информацию об объектах. Однако в то время, как атрибуты мастер-данных имеют одинаковые значения для большого класса объектов (например, для всех объектов, имеющих данный номер GTIN), значения атрибутов МДЭП могут быть различными для гораздо меньших групп объектов (например, одной серии или партии) и могут быть различными для каждого объекта (то есть различными для каждого экземпляра объекта).

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

МДЭП, как обычные мастер-данные, остаются статичными в течение всей жизни объекта. Например, дата истечения срока годности скоропортящегося предмета торговли или вес предмета переменной величины не изменяются в течение всей жизни этого предмета торговли, причем различные предметы торговли, имеющие один и тот же номер GTIN, могут иметь различные значения даты истечения срока годности и веса. МДЭП не подлежат использованию для представления информации, которая изменяется в течение жизни объекта, например текущая температура объекта в процессе его перемещения по цепи поставки.

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

Когда объект создается, для данного объекта определяются МДЭП. Поэтому МДЭП могут быть включены только в события типа ObjectEvent (Событие_с_Объектом) с полем ADD (ДОБАВЛЕНИЕ) (см. 7.4.1.2) и в события TransformationEvent (Событие_с_Преобразованием) (см. 7.4.6). В случае с TransformationEvent (Событие_с_Преобразованием) МДЭП применяется к выходным данным преобразования, а не к входным.

Структура МДЭП, определенная в данном стандарте EPCIS, состоит из набора поименованных атрибутов, со значениями любого типа. В привязках XML (см. 9.5) схема XML предоставляет неограниченный список элементов XML, имеющих любое имя элемента и содержание. Другие документы, дополняющие стандарт EPCIS, могут определять конкретные элементы данных МДЭП, см. 6.3. Таким образом, МДЭП похожи на расширения EPCIS на уровне события, но отличаются тем, что МДЭП применяются в течение всего времени жизни объектов, в то время как расширение EPCIS на уровне события применяется только к этому конкретному событию.

7.4 Модуль типов основных событий. События

7.4.1 Событие_EPCIS (EPCISEvent)

Тип событий EPCISEvent (Событие_EPCIS) — это общий базовый тип для всех событий EPCIS. Все более конкретные типы событий в следующих подразделах являются подклассами EPCISEvent (Событие_EPCIS).

Этот общий базовый тип имеет только следующие поля, &приведенные в таблице 14&.

&Таблица 14&

7.4.1.1 Объяснение для поля eventTimeZoneOffset (смещение_Часового_Пояса_События) (справочная информация)

Наличие поля eventTimeZoneOffset (смещение_Часового_Пояса_События) не обязательно для понимания того, в какой момент времени произошло событие. Причина в том, что поле eventTime (время_События) имеет тип Time (Время), определяемый в 7.3 как «дата и время в формате, независимом от часового пояса». Например, в привязке XML (см. 9.5) поле eventTime (время_События) представляется как элемент типа xsd:dateTime, а в 9.5 далее оговаривается, что представление XML должно содержать спецификатор часового пояса. Поэтому представление XML для поля eventTime (время_События) однозначно идентифицирует момент времени в абсолютном формате, и отсутствует необходимость в информации о значении поля eventTimeZoneOffset (смещение_Часового_Пояса_События) для понимания истинного значения времени.

Назначением поля eventTimeZoneOffset (смещение_Часового_Пояса_События) является обеспечение дополнительного контекста ведения хозяйственной деятельности для события, а именно идентификации того, каким фактически было смещение часового пояса в том месте и времени, когда было зафиксировано событие. Эта информация может быть полезной, чтобы определить, например, произошло ли событие в рабочие часы, и представить событие персоналу в формате, соответствующем местному времени, и т.д. Информация о смещении местного часового пояса не обязательно доступна из поля eventTime (время_События), потому что не существует требований к тому, что спецификатор часового пояса в представлении XML поля eventTime (время_События) должен быть смещением местного часового пояса, в котором было зафиксировано событие. Например, событие, происходящее в 8:00 утра по восточному стандартному времени США (US Eastern Standard Time), может иметь поле XML eventTime (время_События), имеющее вид 08:00-05:00 (используя восточное стандартное время США), или 13:00Z (по всемирному координированному времени UTC), или даже 07:00-06:00 (используя центральное стандартное поясное время США (US Central Standard Time). Более того, документ &[18]& не требует от процессоров XML сохранять и представлять приложениям спецификатор часового пояса, который был частью поля xsd:dateTime, и, таким образом, спецификатор часового пояса в поле eventTime (время_События) может быть и вовсе не доступен приложениям. Аналогичные соображения будут применяться для других (не XML) привязок модуля типов основных событий. Например, гипотетическая двоичная привязка может представлять значения Time (Время) как миллисекундное смещение относительно полуночи по всемирному координированному времени UTC на 1 января 1970 года — опять же, однозначно идентифицирующее момент в абсолютном времени, но не предоставляющее никакой информации о местном часовом поясе. По этим причинам поле eventTimeZoneOffset (смещение_Часового_Пояса_События) предусмотрено как дополнительное поле события.

7.4.1.2 Элемент ErrorDeclaration (Заявление_об_Ошибке)

Наличие в событии элемента ErrorDeclaration (Заявление_об_Ошибке) указывает на то, что данное событие имеет особую семантику: в отличие от нормальной семантики, которая содержит утверждение о том, что какие-либо события произошли, или о том, что какие-либо факты являются верными после того, как событие произошло, семантика данного события содержит утверждение о том, что предшествующие утверждения являются ошибочными. Событие, содержащее элемент ErrorDeclaration (Заявление_об_Ошибке), ДОЛЖНО быть во всех остальных отношениях идентичным предшествующему событию, при этом «во всех остальных отношениях» означает, что все поля события, за исключением элемента ErrorDeclaration (Заявление_об_Ошибке) и значения поля recordTime (время_Записи), в точности совпадают с предшествующим событием. (Следует заметить, что включает поле eventID (идентификатор_События): значение поля eventID (идентификатор_События) заявления об ошибке будет равно значению поля eventID (идентификатор_События) предшествующего события или будет нулевым, если значение поля eventID (идентификатор_События) предшествующего события является нулевым. Это представляет собой единственный случай, когда одно и то же отличное от нуля значение поля eventID (идентификатор_События) может присутствовать в двух событиях.) Семантика события, содержащего элемент ErrorDeclaration (Заявление_об_Ошибке), заявляет о том, что все утверждения, подразумеваемые предшествующим событием, считаются ошибочными с момента, указанного в поле declarationTime. Предшествующее событие никаким образом не модифицируется, и в ответ на последующие запросы будет поступать как предшествующее событие, так и заявление об ошибке.

Элемент ErrorDeclaration (Время_Заявления) содержит следующие поля (&см. таблицу 15&).

Элемент ErrorDeclaration (Заявление_об_Ошибке) НЕ ДОЛЖЕН использоваться, если имеется возможность смоделировать действительную ситуацию в виде обычного события (то есть с использованием события, которое не содержит элемент ErrorDeclaration (Заявление_об_Ошибке).

7.4.1.3 Примеры использования заявлений об ошибках (справочная информация)

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

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

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

Пример 1: Предприятие X фиксирует событие EPCIS, утверждающее, что продукция с серийными номерами 101, 102, 103 была отгружена предприятию Y. Предприятие Y по получении груза обнаружило в дополнение к продукции с серийными номерами 101, 102, 103 продукцию с серийным номером 104. В процессе взаимодействия с Предприятием X было установлено, что продукция с серийным номером 104 действительно была отгружена и что событие отгрузки было ошибочным. Корректирующие действия: Предприятие X фиксирует новое событие EPCIS, утверждающее, что продукция с серийным номером 104 была отгружена, с контекстной информацией, как у изначального события.

Пример 2: Предприятие X фиксирует событие EPCIS, утверждающее, что продукция с серийными номерами 101, 102, 103 была отгружена предприятию Y. Предприятие Y по получении груза обнаружило только продукцию с серийными номерами 101, 102. В процессе взаимодействия с предприятием X было установлено, что продукция с серийным номером 103 не была отгружена и осталась в наличии у предприятия X. Достигается соглашение об отмене счета, выставленного за продукцию с серийным номером 103. Корректирующие действия: Предприятие X фиксирует новое событие EPCIS, признающее недействительной поставку продукции с серийным номером 103.

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

В некоторых случаях представляется невозможным (или крайне нежелательным) корректировать историю объекта посредством создания нового события EPCIS с обычной семантикой (то есть с семантикой, описанной в 7.4.1 - 7.4.6).

Пример 3: Предприятие X фиксирует событие EPCIS, утверждающее, что продукция X с серийным номером 101 была уничтожена. Данное событие является событием с объектом (Object Event) в соответствии с 7.4.2 со значением действия = DELETE (УДАЛЕНИЕ). Впоследствии обнаруживается, что продукция с серийным номером 101 все еще находится на хранении, а не уничтожена. Для исправления истории нельзя использовать обычное событие, поскольку семантика значения действия DELETE (УДАЛЕНИЕ) для события объекта говорит о том, что «данный объект не может появляться в последующих событиях».

Пример 4: Предприятие X фиксирует событие EPCIS, утверждающее, что были отгружены несколько изделий, и при этом указывающее в параметре «на каком основании» заказ № 123. Предприятие Y получает товар и фиксирует событие получения. Уже после этого выясняется, что ссылка на заказ в событии отгрузки неверна: там указан заказ № 456 вместо № 123. Эту ошибку можно было бы исправить посредством обычных событий EPCIS: Предприятие X может зафиксировать событие «отмены поставки» и создать новое событие «поставки» с указанием правильного номера заказа. Но такой способ коррекции является нежелательным с точки зрения всеобъемлющего прослеживания, особенно с учетом того, что уже имело место событие получения.

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

В примере 3 событие заявления об ошибке подразумевает, что продукция X с серийным номером 101 не была уничтожена. В примере 4 событие заявления об ошибке подразумевает, что поставка в соответствии с заказом № 123 не имела места, а дополнительное («корректирующее») событие будет утверждать, что произошла поставка в соответствии с заказом № 456. Этот способ подобен моделированию примера 4 с использованием события «отмены поставки», но вместо утверждения о том, что отгрузка была осуществлена в соответствии с заказом № 123 и потом аннулирована, событие заявления об ошибке просто заявляет, что утверждение по заказу № 123 было ошибочным.

Событие заявления об ошибке формируется посредством добавления части ErrorDeclaration (Заявление_об_Ошибке). Так, по отношению к событию C1 структура события заявления об ошибке C2, целью которого является утверждение об ошибочности утверждений, вытекающих из C1, будет аналогична по содержанию C1, но с добавлением элемента ErrorDeclaration. Например, заявление об ошибке в отношении события «уничтожения» в примере 3 тоже является событием с объектом (Object Event) со значением действия = DELETE (УДАЛЕНИЕ), но с добавлением элемента ErrorDeclaration (Заявление_об_Ошибке). В целом для того, чтобы объявить событие C ошибочным, фиксируют новое событие, идентичное событию C, но с добавлением элемента ErrorDeclaration (Заявление_об_Ошибке) (и отличающимся от C временем фиксирования события).

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

7.4.1.4 Установление соответствия заявления об ошибке первоначальному событию (справочная информация)

Как уже было указано в 7.4.1.2, событие заявления об ошибке по содержанию идентично первоначальному (ошибочному) событию, отличаясь лишь наличием самого элемента ErrorDeclaration (Заявление_об_Ошибке) и временем фиксирования. Одно из преимуществ такого подхода состоит в том, что, когда приложение EPCIS доступа обнаруживает заявления об ошибке, нет необходимости в восстановлении первоначального (ошибочного) события, так как вся информация, содержащаяся в том событии, также присутствует в событии заявления об ошибке, которое уже имеется в наличии у приложения EPCIS доступа.

Тем не менее возможны ситуации, при которых приложению EPCIS доступа или приложению EPCIS сбора данных требуется подтвердить существование первоначального (ошибочного) события посредством запроса. Единственным способом подтверждения того, что некоторое событие является первоначальным событием, соответствующим заявлению об ошибке, является подтверждение соответствия всех элементов данных этих событий (кроме элемента ErrorDeclaration (Заявление_об_Ошибке) и времени фиксирования). Рекомендации по формированию запросов в таких ситуациях содержатся в &[7]&.

7.4.2 Событие_с_Объектом (ObjectEvent) (подкласс EPCISEvent)

Тип событий ObjectEvent (Событие_с_Объектом) предназначен для сбора информации о событии, имеющем отношение к одному или нескольким физическим или цифровым объектам, обозначенным идентификаторами на уровне экземпляра (EPC) или на уровне класса (EPC Class). Большинство значений ObjectEvent (Событие_с_Объектом) предусмотрено для представления фактических результатов отслеживания объектов, но, строго говоря, их можно использовать для любого события, о котором приложение сбора данных намеревается заявить, что событие касалось указанных объектов, включая, например, фиксирование факта того, что ожидаемое отслеживание не произошло.

В то время как в ObjectEvent (Событие_с_Объектом) может присутствовать более одного идентификатора EPC на уровне экземпляра и/или на уровне класса EPC Class, отношений или связей между этими объектами не подразумевается, кроме случая, когда в реальном мире произошли одинаковые события.

Поле action (действие) для ObjectEvent (Событие_с_Объектом) описывает отношения событий к жизненному циклу объектов и их идентификаторов, указанных в событии (&см. таблицу 16&).

Поля определены в &таблице 17&:

&Таблица 17&

• событие, описанное с помощью поля bizStep (бизнес-этап) (и любых других полей), имело место в отношении объектов, идентифицированных полями epcList (список_EPC) и quantityList (список_Количество) в момент времени, указанный в поле eventTime (время_События), в месте нахождения, указанном в поле readPoint (место_Считывания);
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) номера EPC в поле epcList (список_EPC) были введены для использования (присвоены в первый раз);
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) в поле quantityList (список_Количество) было создано определенное количество экземпляров на уровне класса EPC (или неизвестное количество для каждого элемента QuantityElement (Элемент_Количество), в котором значение поля quantity (количество) не задано);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ)) номера EPC в поле epcList (список_EPC) были выведены из эксплуатации (удалены для будущего использования);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ)) определенное число экземпляров на уровне класса EPC в поле quantityList (список_Количество) прекратило существование (или неизвестное количество для каждого элемента QuantityElement (Элемент_Количество), в котором значение поля quantity (количество) не задано);
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ) и задано непустое значение поля bizTransactionList (список_Документов_Бизнес-транзакций)) существует связь между документами бизнес-транзакций, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций), и объектами, указанными в поле epcList (список_EPC) и поле quantityList (список_Количество);
• (если значением поля action (действие) является OBSERVE (ОТСЛЕЖИВАНИЕ) и задано непустое значение поля bizTransactionList (список_Документов_Бизнес-транзакций) данное событие произошло в контексте документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ) и задано непустое значение поля bizTransactionList (список_Документов_Бизнес-транзакций)) данное событие произошло в контексте документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значение поля sourceList (список_Начальных_Пунктов) не пустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, начальная точка которого определяется источниками, перечисленными в поле sourceList (список_Начальных_Пунктов);
• (если значение поля destinationList (список_Конечных_Пунктов) не пустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, конечная точка которого определяется конечными пунктами, перечисленными в поле destinationList (список_Конечных_Пунктов).

Перспективная семантика:

• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) объекты, обозначенные идентификаторами на уровне экземпляра в поле epcList (список_EPC), могут появиться в последующих событиях;
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) объекты, обозначенные идентификаторами на уровне класса в поле quantityList (список_Количество), могут появиться в последующих событиях;
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ)) объекты, обозначенные идентификаторами на уровне экземпляра в поле epcList (список_EPC), не должны появиться в последующих событиях;
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ)) общее число объектов, обозначенных идентификаторами на уровне класса в поле quantityList (список_Количество), которые могут появиться в последующих событиях, было уменьшено с помощью значений, заданных в поле quantityList (список_Количество) (или с помощью неизвестного значения количества для каждого элемента QuantityElement (Элемент_Количество), в котором значение поля quantity (количество) не задано);
• (если значение поля disposition (состояние) задано) условие ведения хозяйственной деятельности для объектов, определенных полями epcList (список_EPC) и quantityList (список_Количество), является таким, каким оно задано полем disposition (состояние);

• (если значение поля bizLocation (производственное_Место_Назначения) задано) объекты, определенные полями epcList (список_EPC) и quantityList (список_Количество), находятся в производственном месте назначения, указанном в поле bizLocation (производственное_Место_Назначения);
• (если значение поля bizLocation (производственное_Место_Назначения) не задано) производственное место назначения объектов, определенных полями epcList (список_EPC) и quantityList (список_Количество), неизвестно;
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ) и значение поля ilmd (МДЭС) не пустое) объекты, определенные полями epcList (список_EPC) и quantityList (список_Количество), описываются атрибутами в поле ilmd (МДЭС);

7.4.3 Событие_с_Агрегацией (AggregationEvent) (подкласс EPCISEvent)

Тип событий AggregationEvent (Событие_с_Агрегацией) описывает события, которые применяются к объекту, объединенному с другим объектом. В таком событии имеется набор «содержащихся» объектов, которые были объединены внутри «содержащего» их объекта, что означает определение агрегации как таковой.

Данный тип событий предназначен для использования для «агрегаций», т.е. объединения, в котором существуют сильные физические взаимосвязи между содержащим и содержащимися объектами. При этом все они будут занимать одно и то же место нахождения в одно и то же время до тех пор, пока не будут разъединены. Примером агрегации является случай, когда коробки загружаются на поддон и перемещаются как единое целое. Тип событий AggregationEvent (Событие_с_Агрегацией) не предназначен для более слабых объединений, таких как два поддона, являющиеся частью одной и той же партии, но в которой эти поддоны не всегда могут находиться в одном и том же месте и в одно и то же время (в таких обстоятельствах может подойти тип событий TransactionEvent (Событие_с_Документом_Транзакции). В зависимости от бизнес-этапа может быть задано больше конкретных семантических значений.

Поле action (действие) события типа AggregationEvent (Событие_с_Агрегацией) описывает отношение события к жизненному циклу агрегации (&см. таблицу 18&).

Тип событий AggregationEvent (Событие_с_Агрегацией) включает поля, которые ссылаются на единственный «объект-родитель» (часто это — «содержащий» объект) и один или несколько «объектов-потомков» (часто это — «содержащиеся» объекты). Если поле action (действие) имеет значение ADD (ДОБАВЛЕНИЕ) или DELETE (УДАЛЕНИЕ), то требуется родительский идентификатор, но он не обязателен, если поле action (действие) имеет значение OBSERVE (ОТСЛЕЖИВАНИЕ).

Примечание - Если поле action (действие) имеет значение ADD (ДОБАВЛЕНИЕ), то используется идентификатор объекта-родителя, и поэтому существует способ сослаться на объединение в последующих событиях, если значением поля action (действие) является DELETE (УДАЛЕНИЕ). Идентификатор объекта-родителя является необязательным, если поле action (действие) имеет значение OBSERVE (ОТСЛЕЖИВАНИЕ), потому что объект-родитель не всегда известен во время непосредственного отслеживания. Например, процесс приемки поддона для определения номеров EPC может опираться на радиочастотные метки, нанесенные на коробки, собранные на поддоне, но на самом поддоне радиочастотная метка может отсутствовать (или если она есть, но не считывается).

Тип событий AggregationEvent (Событие_с_Агрегацией) предназначен для указания агрегаций среди объектов, поэтому потомки идентифицируются с помощью номеров EPC и/или классов EPC. Объект-родитель, тем не менее, необязательно является физическим или цифровым объектом, отделенным от самой агрегации, и поэтому объект-родитель идентифицируется с помощью произвольного идентификатора в формате URI, который МОЖЕТ быть номером EPC, но МОЖЕТ быть и другим идентификатором, заимствованным из подходящего частного лексикона.

Примечание — Например, во многих производственных операциях обычно груз проходит несколько этапов до присвоения ему номера EPC. В таких ситуациях в момент формирования груза ему присваивается внутренний контрольный номер (часто называемый «номерным знаком» («license plate number», LPN), который используется вплоть до момента отгрузки. В момент отгрузки присваивается серийный номер транспортной упаковки (Serial Shipping Container Code — SSCC), который является номером EPC. В стандарте EPCIS это моделируется с помощью (a) AggregateEvent (Событие_с_Агрегацией) со значением поля action (действие), соответствующим ADD (ДОБАВЛЕНИЕ), в момент формирования груза, и (b) второго события типа AggregateEvent со значением action (действие), соответствующим ADD (ДОБАВЛЕНИЕ), в момент присвоения номера SSCC (первое объединение может быть также аннулировано через событие типа AggregateEvent со значением action (действие), соответствующим DELETE (УДАЛЕНИЕ)). Первое событие типа AggregationEvent (Событие_с_Агрегацией) будет использовать номер LPN как идентификатор родителя (выраженный в подходящем представлении идентификатора URI; см. 6.4), тогда как второе событие типа AggregationEvent (Событие_с_Агрегацией) будет использовать номер SSCC (который является разновидностью EPC) как идентификатор родителя, таким образом изменяя поле parentID (идентификатор_Родителя).

Тип событий AggregationEvent (Событие_с_Агрегацией) имеет следующие поля (&см. таблицу 19&):

&Таблица 19&

Ретроспективная семантика:

• событие, описанное с помощью поля bizStep (бизнес-этап) (и любых других полей), имело место с привлечением «содержащего» объекта, указанного в поле parentID (идентификатор_Родителя), и «содержащихся» объектов, указанных в поле childEPCs (номера_EPC_Потомков) и поле childQuantityList (список_Количества_Потомков), в момент времени, указанный в поле eventTime (время_События), и в месте нахождения, указанном в поле readPoint (место_Считывания);

• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ), а значения полей childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков) не пустые) объекты, определенные в поле childEPCs (номера_EPC_Потомков) и поле childQuantityList (список_Количества_Потомков), были дезагрегированы из объекта, указанного в поле parentID (идентификатор_Родителя);

• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ) и задано непустое поле bizTransactionList (список_Документов_Бизнес-транзакций)) существует связь между документами бизнес-транзакций, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций), объектами, идентифицированными в поле childEPCs (номера_EPC_Потомков) и поле childQuantityList (список_Количества_Потомков), и «содержащим» их объектом, указанным в поле parentID (идентификатор_Родителя);
• (если значением поля action (действие) является OBSERVE (ОТСЛЕЖИВАНИЕ) и задано непустое поле bizTransactionList (список_Документов_Бизнес-транзакций)) данное событие произошло в контексте документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ) и задано непустое поле bizTransactionList (список_Документов_Бизнес-транзакций)) данное событие произошло в контексте документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значение поля sourceList (список_Начальных_Пунктов) не пустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, начальная точка которого описывается с помощью начальных пунктов, перечисленных в поле sourceList (список_Начальных_Пунктов);

• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) существует агрегирование между «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя), и «содержащимися» объектами, указанными в полях childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ), а поля childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков) не пустые) агрегирование между «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя), и «содержащимися» объектами, указанными в полях childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков), больше не существует;
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ), и оба поля, childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков), пустые) агрегирование между «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя), и любыми «содержащимися» объектами больше не существует;
• (если задано поле disposition (состояние)) Условия ведения хозяйственной деятельности для объектов, связанных с объектами, указанными в полях parentID (идентификатор_Родителя), childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков), заданы значением поля disposition (состояние);

• (если задано поле bizLocation (производственное_Место_Назначения)) объекты, связанные с объектами, указанными в полях parentID (идентификатор_Родителя), childEPCs (номера_EPC_Потомков) и childQuantityList, находятся в производственном месте назначения, указанном в поле bizLocation (производственное_Место_Назначения);
• (если значение поля bizLocation (производственное_Место_Назначения) не задано) производственное место назначения объектов, связанных с объектами, указанными в полях parentID (идентификатор_Родителя), childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков), неизвестно;
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ) и задано непустое значение поля bizTransactionList (список_Документов_Бизнес-транзакций)) существует связь между документами бизнес-транзакций, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций), объектами, указанными в полях childEPCs (номера_EPC_Потомков) и childQuantityList (список_Количества_Потомков), и «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан).

Примечание - В случае, когда значением поля action (действие) является ADD (ДОБАВЛЕНИЕ) и задано не пустое значение поля bizTransactionList (список_Документов_Бизнес-транзакций), семантический эффект эквивалентен наличию события типа AggregationEvent (Событие_с_Агрегацией) без поля bizTransactionList (список_документов_Бизнес-транзакций) вместе с событием типа TransactionEvent (Событие_с_Документом_Транзакции), имеющим поле bizTransactionList (список_Документов_Бизнес-транзакций), и те же значения полей, что и событие типа AggregationEvent (Событие_с_Агрегацией). Следует обратить внимание, что событие типа AggregationEvent (Событие_с_Агрегацией) с непустым полем bizTransactionList (список_документов_Бизнес-транзакций) не вызывает возврат события типа TransactionEvent (Событие_с_Документом_Транзакции) из запроса.

Примечание — Многие семантически несостоятельные ситуации могут представлять собой неправильное использование агрегации. Например, одним и тем же объектам может быть предоставлено несколько объектов-родителей в течение одного и того же периода времени с помощью различных операций ADD (ДОБАВЛЕНИЕ) без промежуточного удаления (Delete). Аналогично объект может быть указан как потомок своего прародителя (объекта-родителя от объекта-родителя) или даже себя самого. Несуществующая агрегация может иметь статус DELETED (УДАЛЕНА). Эти ситуации не могут быть обнаружены синтаксически, и в общем случае отдельный репозиторий EPCIS может не иметь достаточной информации, чтобы их обнаружить. Таким образом, настоящая спецификация не учитывает эти ошибочные обстоятельства.

7.4.4 Событие_с_Количеством_Объектов (QuantityEvent) (подкласс EPCISEvent) УСТАРЕВШИЙ

Тип событий QuantityEvent (Событие_с_Количеством_Объектов) фиксирует событие, которое имеет место в отношении определенного количества объектов на уровне класса. Данный тип события может быть использован, например, для отчета об уровнях запасов продукции.

Что касается [&24&], версии EPCIS 1.1, подкласс QuantityEvent (Событие_с_Количеством_Объектов) в ней не используется. Вместо этого приложения должен использоваться подкласс ObjectEvent (Событие_с_Объектом), содержащий один или несколько элементов QuantityListElement (Элемент_Списка_Количество). Подкласс QuantityEvent (Событие_с_Количеством_Объектов) эквивалентен подклассу ObjectEvent (Событие_с_Объектом), содержащему пустой список EPCList и единственный элемент QuantityListElement (Элемент_Списка_Количество), содержащий поле quantity (количество), без поля uom (единица_измерения).

Следует обратить внимание, что поскольку экземпляр на уровне класса EPC (EPCClass) всегда обозначает конкретную упаковочную единицу (например, коробку с 12 предметами), необходимость в явном поле «unit of measure» («единица измерения») отсутствует. Единица измерения всегда является классом объектов, обозначаемым согласно epcClass (epc_на_уровне_Класса), как определено в мастер-данных для данного класса объектов.

Ретроспективная семантика:

• событие, описанное с помощью поля bizStep (бизнес-этап) (и любых других полей), имело место в отношении объектов, указанных в поле quantity (количество), EPC-класса, указанного в поле epcClass (epc_на_уровне_Класса), в момент времени, указанный в поле eventTime (время_События), в месте нахождения, указанном в поле readPoint (место_Считывания);
• (если заданы непустые значения поля bizTransactionList (список_Документов_Бизнес-транзакций)) данное событие произошло внутри контекста документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций).

Перспективная семантика:

• (если задано значение поля disposition (состояние)) условия ведения хозяйственной деятельности для объектов описаны с помощью поля disposition (состояние);
• (если значение поля disposition (состояние) не задано) условия ведения хозяйственной деятельности для объектов не изменяются;
• (если задано значение поля bizLocation (производственное_Место_Назначения)) объекты находятся в производственном месте назначения, указанном в поле bizLocation (производственное_Место_Назначения);
• (если значение поля bizLocation (производственное_Место_Назначения) не задано) место нахождения объектов неизвестно.

7.4.5 Событие_с_Документом_Транзакции (TransactionEvent) (подкласс EPCISEvent)

Тип события TransactionEvent (Событие_с_Документом_Транзакции) описывает объединение или разъединение физических или цифровых объектов с одним или несколькими документами бизнес-транзакций. В то время как в других типах событий есть необязательное поле bizTransactionList (список_Документов_Бизнес-транзакций), которое может использоваться для определения контекста события, тип события TransactionEvent (Событие_с_Документом_Транзакции) используется для однозначного обозначения того, что определенные объекты связаны с одним или несколькими документами бизнес-транзакций, являющимися частью события, или отделены от них.

Поле action события типа TransactionEvent (Событие_с_Документом_Транзакции) описывает отношение события к жизненному циклу документа транзакции (&см. таблицу 21&).

&Таблица 21&

Тип событий TransactionEvent (Событие_с_Документом_Транзакции) имеет следующие поля (см. таблицу 22):

&Таблица 22&

Следует обратить внимание, что в привязке XML (см. 9.3) поля quantityList (список_Количество), sourceList (список_Начальных_Пунктов) и destinationList (список_Конечных_Пунктов) появляются в стандартной области расширения, чтобы поддержать совместимость с [&3&] (EPCIS 1.0).

1 Использование имени поля parentID (идентификатор_Родителя) в обоих событиях, типа TransactionEvent (Событие_с_Документом_Транзакции) и типа AggregationEvent (Событие_с_Агрегацией) (см. 7.2.10), не показывает схожесть функции или семантики. В общем случае тип события TransactionEvent (Событие_с_Документом_Транзакции) несет ту же информацию об идентификации объекта, что и тип события ObjectEvent (Событие_с_Объектом), то есть список номеров EPC и/или элементов QuantityElements (Элемент_Количество). Все другие информационные поля (bizTransactionList (список_Документов_Бизнес-транзакций), bizStep (бизнес-этап), bizLocation (производственное_Место_Назначения) и т.д.) применяются одинаково и единообразно ко всем указанным объектам, независимо от того, указаны ли объекты только в поле epcList (список_EPC) и поле quantityList (список_Количество), или указано дополнительное поле parentID (идентификатор_Родителя).

• событие, описанное с помощью поля bizStep (бизнес-этап) (и любых других полей), имело место с привлечением документов бизнес-транзакций, указанных в поле bizTransactionList (список_Документов_Бизнес-транзакций), объектов, приведенных в поле epcList (список_EPC) и в поле quantityList (список_Количество), и объекта, содержащего экземпляры, указанного в поле parentID (идентификатор_Родителя) (если задан), в момент времени, указанный в поле eventTime (время_События), и в месте нахождения, указанном в поле readPoint (место_Считывания);
• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) объекты, определенные в поле epcList (список_EPC) и поле quantityList (список_Количество), и «содержащий» объект, указанный в поле parentID (идентификатор_Родителя) (если задан), были связаны с документами бизнес-транзакций, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ), а поля epcList (список_EPC) и quantityList (список_Количество) не пустые) объекты, определенные в полях epcList (список_EPC), quantityList (список_Количество) и «содержащем» объекте, указанном в поле parentID (идентификатор_Родителя) (если задан), были отделены от документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ), оба поля, epcList (список_EPC) и quantityList (список_Количество), пустые, а поле parentID (идентификатор_Родителя) не задано) все объекты были отделены от документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значение sourceList (список_Начальных_Пунктов) непустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, исходная точка которого описывается с помощью начальных пунктов, перечисленных в поле sourceList (список_Начальных_Пунктов);
• (если значение поля destinationList (список_Конечных_Пунктов) непустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, конечная точка которого описывается с помощью конечных пунктов, перечисленных в поле destinationList (список_Конечных_Пунктов).

Перспективная семантика:

• (если значением поля action (действие) является ADD (ДОБАВЛЕНИЕ)) существует связь между документами бизнес-транзакций, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций), объектами, указанными в поле epcList (список_EPC) и в поле quantityList (список_Количество), и «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан);
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ), а поля epcList (список_EPC) и quantityList (список_Количество) не пустые) связи между бизнес-транзакциями, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций), объектами, указанными в поле epcList (список_EPC) и в поле quantityList (список_Количество), и «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан), больше не существует;
• (если значением поля action (действие) является DELETE (УДАЛЕНИЕ) и оба поля, epcList (список_EPC) и quantityList (список_Количество), пустые и поле parentID (идентификатор_Родителя) не задано) связи между документами бизнес-транзакций, перечисленными в поле bizTransactionList (список_Документов_Бизнес-транзакций), и любыми объектами больше не существует;
• (если задано поле disposition (состояние)) условия ведения хозяйственной деятельности для объектов, связанных с объектами, указанными в поле epcList (список_EPC) и поле quantityList (список_Количество), а также «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан), заданы значением поля disposition (состояние);
• (если значение поля disposition (состояние) не задано) условия ведения хозяйственной деятельности для объектов, связанных с объектами, указанными в поле epcList (список_EPC) и в поле quantityList (список_Количество), и «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан), не меняются;
• (если задано поле bizLocation (производственное_Место_Назначения)) объекты, связанные с объектами, указанными в полях epcList (список_EPC), quantityList (список_Количество), и «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан), находятся в производственном месте назначения, указанном в поле bizLocation (производственное_Место_Назначения);
• (если значение поля bizLocation (производственное_Место_Назначения) не задано) производственное место назначения объектов, связанных с объектами, указанными в полях epcList (список_EPC), quantityList (список_Количество), и «содержащим» объектом, указанным в поле parentID (идентификатор_Родителя) (если задан), неизвестно.

7.4.6 Событие_с_Преобразованием (TransformationEvent) (подкласс EPCISEvent)

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

Некоторые бизнес-процессы с преобразованием происходят в течение длительного периода времени, и поэтому более целесообразно представлять их в виде серии событий EPCIS. Для связи между собой двух и более событий типа TransformationEvent (Событие_с_Преобразованием) в них может включаться значение TransformationID (Идентификатор_Преобразования). Когда события имеют одинаковое значение TransformationID (Идентификатор_Преобразования), то это означает, что входные данные для любого из этих событий могут каким-то образом включаться в выходные данные для любого из этих событий.

Поля приведены в &таблице 23&.

&Таблица 23&

Если значение поля transformationID (идентификатор_Преобразования) не задано, то событие типа TransformationEvent (Событие_с_Преобразованием) ДОЛЖНО включать по крайней мере одно поле входных данных (т.е. по меньшей мере одно значение поля inputEPCList (список_EPC_на_Входе) и поля inputQuantityList (список_Количество_на_Входе) должно быть непустым) и по крайней мере одно поле выходных данных (т.е. по меньшей мере одно значение поля outputEPCList (список_EPC_на_Выходе) и поля outputQuantityList (список_Количество_на_Выходе) должно быть непустым). Если значение поля transformationID (идентификатор_Преобразования) присутствует, то событие типа TransformationEvent (Событие_с_Преобразованием) ДОЛЖНО включать по крайней мере одно поле входных данных ИЛИ по крайней мере одно поле выходных данных (или оба поля). Последнее обеспечивает возможность того, что при преобразовании, описываемом несколькими событиями, связанными с общим полем transformationID (идентификатор_Преобразования), любое из этих событий может только добавлять входные данные или только извлекать выходные данные.

Ретроспективная семантика:

• преобразование, описанное с помощью поля bizStep (бизнес-этап) (и любых других полей), имело место с привлечением входных объектов, указанных в поле inputEPCList (список_EPC_на_Входе) и поле inputQuantityList (список_Количество_на_Входе), и выходных объектов, указанных в поле outputEPCList (список_EPC_на_Выходе) и поле outputQuantityList (список_Количество_на_Выходе), в момент времени, указанный в поле eventTime (время_События), и в месте нахождения, указанном в поле readPoint (место_Считывания);
• данное событие произошло в контексте документов бизнес-транзакций, перечисленных в поле bizTransactionList (список_Документов_Бизнес-транзакций);
• (если значение поля transformationID (идентификатор_Преобразования) не задано) любой из входных объектов, указанных в поле inputEPCList (список_EPC_на_Входе) и поле inputQuantityList (список_Количество_на_Входе) данного события, может включаться в каждый из выходных объектов, указанных в поле outputEPCList (список_EPC_на_Выходе) и поле outputQuantityList (список_Количество_на_Выходе) этого события;
• (если значение поля transformationID (идентификатор_Преобразования) задано) любой из входных объектов, указанных в поле inputEPCList (список_EPC_на_Входе) и поле inputQuantityList (список_Количество_на_Входе) данного события, совместно с входными объектами, указанными в поле inputEPCList (список_EPC_на_Входе) и поле inputQuantityList (список_Количество_на_Входе) других событий, имеющих то же самое значение поля transformationID (идентификатор_Преобразования), может включаться в каждый из выходных объектов, указанных в поле outputEPCList (список_EPC_на_Выходе) и поле outputQuantityList (список_Количество_на_Выходе) этого события, так же как в каждый из выходных объектов, указанных в поле outputEPCList (список_EPC_на_Выходе) и поле outputQuantityList (список_Количество_на_Выходе) других событий, имеющих то же самое значение поля transformationID (идентификатор_Преобразования);
• (если значение поля sourceList (список_Начальных_Пунктов) не пустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, начальная точка которого описывается с помощью источников, перечисленных в поле sourceList (список_Начальных_Пунктов);
• (если значение поля destinationList (список_Конечных_Пунктов) не пустое) данное событие произошло в контексте перемещения в процессе хозяйственной деятельности, конечная точка которого описывается с помощью конечных пунктов, перечисленных в поле destinationList (список_Конечных_Пунктов).

Перспективная семантика:

• объекты, обозначенные идентификаторами на уровне экземпляра в поле outputEPCList (список_EPC_на_Выходе), могут появиться в последующих событиях;
• объекты, обозначенные идентификаторами на уровне класса в поле outputQuantityList (список_Количество_на_Выходе), могут появиться в последующих событиях;
• (если задано поле disposition (состояние)) условие ведения хозяйственной деятельности для объектов, определенных полями outputEPCList (список_EPC_на_Выходе) и outputQuantityList (список_Количество_на_Выходе), задано значением поля disposition (состояние);
• (если значение поля disposition (состояние) не задано) условие ведения хозяйственной деятельности для объектов, определенных полями outputEPCList (список_EPC_на_Выходе) и outputQuantityList (список_Количество_на_Выходе), неизвестно;
• (если задано поле bizLocation) объекты, определенные полями outputEPCList (список_EPC_на_Выходе) и outputQuantityList (список_Количество_на_Выходе), находятся в месте нахождения, указанном в поле bizLocation;
• (если значение поля bizLocation не задано) производственное место назначения объектов, указанных в поле outputEPCList (список_EPC_на_Выходе) и поле outputQuantityList (список_Количество_на_Выходе), неизвестно;
• (если значение поля ilmd (мдэс) непустое) объекты, указанные в поле outputEPCList (список_EPC_на_Выходе) и поле outputQuantityList (список_Количество_на_Выходе), описываются с помощью атрибутов в поле ilmd (мдэс).

8 Сервисный уровень

Данный раздел включает нормативные спецификации модулей на сервисном уровне. Вместе взятые, эти модули определяют три интерфейса: интерфейс EPCIS сбора данных, интерфейс EPCIS управления запросами, интерфейс EPCIS обратных вызовов по запросам. (Два последних интерфейса совместно относятся к интерфейсам EPCIS запросов.) На схеме (&рисунок 8&) показаны взаимосвязи между этими интерфейсами, расширяя схему из раздела 2 (эта схема является справочной):

Эта схема показывает определение сервиса для интерфейса Service1, который предусматривает три операции. Операция Operation1 принимает два аргумента arg11 и arg12, имеющих типы ArgType11 и ArgType12 соответственно, и возвращает значение типа ReturnType1. Операция Operation2 принимает один аргумент, но не возвращает результат. Операция Operation3 не принимает никаких аргументов, но возвращает значение типа ReturnType3.

В описаниях UML обозначение <> идентифицирует место, где реализации ДОЛЖНЫ предусматривать расширяемость посредством добавления новых операций. Механизмы расширяемости ДОЛЖНЫ предоставлять поставщикам продукции как частные варианты расширения, совместимые с EPCIS, так и расширения, определяемые GS1 в будущих версиях данной спецификации или в новых спецификациях.

В случае стандартных привязок языка WSDL точки расширения реализуются за счет добавления дополнительных операций.

8.1 Модуль основных операций сбора данных

Модуль основных операций сбора данных (Core Capture Operations Module) предоставляет операции, с помощью которых основные события могут доставляться от приложения EPCIS сбора данных. В данном подразделе слово «клиент» (client) относится к приложению EPCIS сбора данных, а «сервис EPCIS» (EPCIS Service) относится к системе, которая реализует интерфейс EPCIS сбора данных.

8.1.1 Аутентификация и авторизация

Некоторые привязки интерфейса EPCIS сбора данных предоставляют сервису EPCIS средства для аутентификации подлинности клиента, а клиенту — средства для аутентификации подлинности сервиса EPCIS либо и то и другое. Спецификация средств аутентификации включена в спецификацию каждой привязки. Если сервис EPCIS аутентифицирует подлинность клиента, реализация МОЖЕТ использовать ключевой идентификатор клиента, чтобы принять решение об авторизации, как описано ниже. Кроме того, реализация МОЖЕТ сохранить ключевой идентификатор клиента с собранными данными для использования в последующих решениях по авторизации путем внедрения интерфейсов EPCIS запросов, как описано в 8.2.2.

Благодаря простоте интерфейса EPCIS сбора данных механизмы авторизации очень просты. Это означает, что реализация МОЖЕТ использовать аутентифицированный ключевой идентификатор клиента, чтобы решить, разрешена операция сбора данных или нет.

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

8.1.2 Сервис сбора данных

&Рисунок 10&

Интерфейс сбора данных содержит только один метод, capture (сбор_данных), который принимает единственный аргумент и не возвращает результат. Реализации интерфейса EPCIS сбора данных ДОЛЖНЫ принимать каждый элемент перечня аргументов, который является действительным типом EPCISEvent (Событие_EPCIS) или его подтипом, в соответствии с настоящей спецификацией. Реализации МОГУТ принимать другие типы событий через расширение, предоставленное поставщиком. Простота данного интерфейса допускает широкое разнообразие привязок, включая простые привязки типа очереди сообщений.

Примечание - «Привязки типа очереди сообщений» («Message-queue type bindings») означают следующее. Предприятия обычно используют технологию «шины сообщений» («message bus») для соединения разных компонентов распределенной системы. Шина сообщений обеспечивает надежный канал для последовательной доставки сообщений по заказу от отправителя к получателю. (Отношение между отправителем и получателем может быть точка-точка (сообщение типа «очередь» («queue»)) или «один-ко-многим» через механизм публикации/подписки (сообщение типа «тема» («topic»)). «Привязка типа очередь сообщений» («message-queue type binding») интерфейса EPCIS сбора данных просто будет обозначением особого канала шины сообщений для доставки событий EPCIS из приложения EPCIS сбора данных в репозиторий EPCIS или в приложение EPCIS доступа посредством интерфейса EPCIS обратных вызовов по запросам. Каждое сообщение будет иметь полезную нагрузку, содержащую одно или несколько событий EPCIS (сериализованных посредством некоторой привязки на уровне определения данных, например привязки XML). Поэтому в такой привязке каждая передача/доставка сообщения соответствует одной операции «сбора данных» («capture»).

Операция capture (сбор_данных) записывает один или несколько событий EPCIS любого типа.

&Таблица 24&

Возвращаемое значение:

(отсутствует).

Конкретные привязки интерфейса EPCIS сбора данных в разделе 10, используя структуру документа EPCIS, определенную в 9.5, несут список событий EPCIS, подлежащих считыванию. Документ EPCIS может содержать мастер-данные в заголовке. Применение интерфейса EPCIS сбора данных, соответствующее настоящему стандарту, МОЖЕТ выбрать запись этих мастер-данных или проигнорировать их: стандарт EPCIS не регламентирует обращение с мастер-данными, полученными через интерфейс EPCIS сбора данных. Аналогичным образом в системе, реализующей интерфейс EPCIS сбора данных, могут быть предусмотрены средства по сбору мастер-данных путем получения документа мастер-данных EPCIS (см. 9.7), но в стандарте EPCIS не содержится требований по поддержке такого решения.

С другой стороны, все мастер-данные на уровне экземпляра/серии, содержащиеся в разделе МДЭП (ILMD) события, ДОЛЖНЫ быть считаны как составная часть события, аналогично любому элементу данных в рамках события EPCIS. Такие мастер-данные ДОЛЖНЫ подлежать запросу с использованием параметров запроса SimpleEventQuery (Простой_Запрос_События), указанных в 8.2.7.1, но не существует требования к применению обеспечить доступность мастер-данных в разделе МДЭП (ILMD) события по запросу SimpleMasterDataQuery (Простой_Запрос_Мастер_Данных), указанному в 8.2.7.2.

Реализация интерфейса сбора данных ДОЛЖНА либо фиксировать все события, указанные в конкретной операции сбора данных, или быть неспособной фиксировать ни одно из событий в указанной операции. То есть реализация НЕ ДОЛЖНА предоставлять возможность частичного фиксирования, при котором некоторые события в списке фиксируются, а другие нет.

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

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

8.2 Модуль основных операций с запросами

Модуль основных операций с запросами (Core Query Operations Module) предоставляет два интерфейса, называемые интерфейс EPCIS управления запросами (EPCIS Query Control Interface) и интерфейс EPCIS обратных вызовов по запросам (EPCIS Query Callback Interface), с помощью которых данные EPCIS могут быть извлечены приложением EPCIS доступа (EPCIS Accessing Application). Интерфейс EPCIS управления запросами предоставляет средства для приложений EPCIS доступа и торговых партнеров для получения данных EPCIS после их сбора из любого источника, как правило, посредством взаимодействия с репозиторием EPCIS. Это предоставляет средство для приложения EPCIS доступа средства для извлечения данных по требованию, а также вводит подписки на длительные запросы (standing queries). Результаты длительных запросов доставляются приложениям EPCIS доступа через интерфейс EPCIS обратных вызовов по запросам.

8.2.1 Аутентификация

Некоторые привязки интерфейса EPCIS управления запросами обеспечивают сервисам EPCIS средства для аутентификации подлинности клиента, а клиенту — средства для аутентификации подлинности сервисов EPCIS либо и то, и другое. Спецификация средств аутентификации включена в спецификацию каждой привязки. Если сервис EPCIS аутентифицирует подлинность клиента, реализация МОЖЕТ использовать ключевой идентификатор клиента, чтобы принять решение об авторизации, как описано в &8.2.2&.

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

8.2.2 Авторизация

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

Получив запрос EPCIS, сервис EPCIS при обработке запроса на основе аутентифицированной подлинности клиента МОЖЕТ предпринять любое из следующих действий:

• сервис МОЖЕТ отказаться от выполнения запроса в целом, ответив с помощью SecurityException (Исключение_по_Безопасности), как определено ниже;
• сервис МОЖЕТ отреагировать меньшим количеством данных, чем было у него запрошено. Например, если клиент запрашивает все экземпляры событий типа ObjectEvent (Событие_с_Объектом) в рамках определенного интервала времени и сервису известно о 100 совпадающих событиях, сервис может выбрать ответ менее чем из 100 событий (например, возвратить только те события, чьи номера EPC представляют собой номер SGTIN с префиксом предприятия, который назначен клиенту);
• сервис МОЖЕТ ответить более укрупненной информацией. В частности, если ответ на запрос включает тип места нахождения (как указано в 7.3.4), сервис может подставить вместо простого места нахождения агрегированное место нахождения;
• сервис МОЖЕТ скрыть информацию. Например, если клиент запрашивает экземпляры событий типа ObjectEvent (Событие_с_Объектом), сервис может в ответ выбрать удаление полей bizTransactionList (список_Документов_Бизнес-транзакций). Возвращенная информация ДОЛЖНА быть правильно сформированными событиями EPCIS, соответствующими данной спецификации и отраслевым руководствам. Кроме того, если сокрытие информации влечет за собой неоднозначную или вводящую в заблуждение информацию, то все событие ДОЛЖНО быть скрыто. Это правило применяется независимо от того, была ли исходная информация собрана через интерфейс EPCIS сбора данных или предоставлена каким-либо другим способом. Например, в событии типа AggregationEvent (Событие_с_Агрегацией) с действием (action), значение которого равно ADD (ДОБАВЛЕНИЕ), попытка скрыть поле parentID (идентификатор_Родителя) привела бы к событию, сформированному неправильно, потому что присутствие поля parentID (идентификатор_Родителя) необходимо, когда значением действия (action) является ADD (ДОБАВЛЕНИЕ). Следовательно, в этом случае все событие целиком должно быть скрыто;
• сервис МОЖЕТ ограничить область запроса данными, которые первоначально были собраны с помощью определенного ключевого идентификатора клиента. Это позволяет «разделить» единственный сервис EPCIS для использования группами несвязанных пользователей, чьи данные следует хранить отдельно.

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

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

8.2.3 Запросы для большого объема данных

Многие из описанных ниже операций запроса позволяют клиенту делать запрос на потенциально неограниченный объем данных. Например, ответ на запрос, который запрашивает все экземпляры класса ObjectEvent (Событие_с_Объектом) в течение заданного интервала времени, может возвратить одно, тысячу, миллион или миллиард событий в зависимости от временного интервала и количества зафиксированных событий. Это может представлять проблемы с производительностью для реализаций сервиса.

Для решения этой проблемы сервис EPCIS МОЖЕТ отклонить любой запрос, ответив с помощью исключения (exception) QueryTooLarge (Запрос_с_Превышением_Объема). Это исключение указывает, что объем запрашиваемых данных больше, чем сервис в состоянии предоставить клиенту. Исключение QueryTooLarge (Запрос_с_Превышением_Объема) — это подсказка клиенту о том, что клиент может получить успешный результат, если сузит область исходного запроса или представит запрос в другое время (например, если служба принимает или отклоняет запросы на основе текущей расчетной нагрузки на сервис).

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

8.2.4 Слишком сложные запросы

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

Для решения этой проблемы сервис EPCIS МОЖЕТ отклонить любой запрос, ответив с помощью исключения QueryTooComplex (Запрос_с_Чрезмерной_Сложностью). Это исключение указывает, что структура запроса такова, что сервис не в состоянии выполнить его для клиента. В отличие от исключения QueryTooLarge (Запрос_с_Превышением_Объема) (см. 8.2.3) исключение QueryTooComplex (Запрос_с_Чрезмерной_Сложностью) указывает, что простое сужение области запроса (например, при запросе событий за одну неделю вместо одного месяца) вряд ли приведет к успеху при ответе на запрос.

Особый язык запросов может определять условия, при которых сервису EPCIS не разрешается отклонять запрос с исключением QueryTooComplex (Запрос_с_Чрезмерной_Сложностью). Это обеспечивает минимальный уровень совместимости.

8.2.5 Структура запроса (интерфейс EPCIS управления запросами)

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

Интерфейс EPCIS управления запросами определен ниже. Реализация интерфейса EPCIS управления запросами ДОЛЖНА применять все методы, приведенные ниже:

Длительные запросы формируются с помощью создания одного или нескольких подписок на ранее определенный, с использованием метода subscribe (подписка), запрос. Результаты будут периодически доставляться через интерфейс обратных вызовов по запросам к конкретному получателю до тех пор, пока подписка не будет отменена с использованием метода unsubscribe (отмена_подписки). Запросы по требованию формируются с помощью выполнения ранее определенного, с использованием метода poll (опрос), запроса. Каждый вызов метода poll (опрос) возвращает результат непосредственно инициатору вызова. В любом случае, если запрос параметризован, конкретные значения для параметров могут быть предоставлены в качестве аргументов для методов subscribe (подписка) или poll (опрос).

Реализация МОЖЕТ предоставить один или несколько «предопределенных» запросов. Предопределенный запрос доступен для использования методами subscribe (подписка) или poll (опрос) и возвращается в списке имен запросов с помощью метода getQueryNames (получение_Имен_Запросов) без предварительного выполнения клиентом каких-либо действий по определению запроса. В частности, EPCIS версии 1.0 не поддерживает механизм, с помощью которого клиент может определить новый запрос, и, таким образом, предопределенные запросы являются единственно доступными. Информацию в отношении конкретных предопределенных запросов, которые ДОЛЖНЫ быть предоставлены реализацией интерфейса запросов для &[3]& (EPCIS версии 1.0), см. также в 8.2.7.

Реализация МОЖЕТ разрешить использовать данный запрос с помощью метода poll (опрос), но не с помощью метода subscribe (подписка). В общем случае запросы для данных о событиях могут использоваться как с методом poll (опрос), так и с методом subscribe (подписка), однако запросы для мастер-данных могут использоваться только с методом poll (опрос). Это происходит из-за того, что метод subscribe (подписка) устанавливает периодическое расписание для многократного запуска запроса, каждый раз ограничивая внимание новыми событиями, записанными с момента последнего запуска запроса. Этот механизм не может применяться к запросам для мастер-данных, так как считается, что мастер-данные являются квазистатическими и не имеют ничего, что соответствует времени записи.

&Таблица 25&

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

Реализация МОЖЕТ ограничить функционирование любого метода в соответствии с решениями по авторизации на основании аутентифицированной подлинности клиента, делающего запрос. Например, реализация может ограничить множество идентификаторов, возвращаемое методом getSubscriptionIDs (получение_Удостоверений_Подписки) и распознаваемое методом unsubscribe (отмена_подписки), только теми абонентами, которые были подписаны ранее одним и тем же клиентом на получение результатов. Это позволяет «разделить» единый сервис EPCIS для использования группами несвязанных пользователей, данные которых должны храниться отдельно.

Если предопределенный запрос определяет именованные параметры, значения этих параметров могут предоставляться, когда запрос впоследствии обращается к методам poll (опрос) или subscribe (подписка). Экземпляр QueryParams представляет собой просто множество пар имя/значение, где имена соответствуют именам параметров, определенных запросом, а значения являются конкретными значениями, которые будут использоваться для вызова запроса (метод poll (опрос)) или подписки на запрос (метод subscribe (подписка)). Если экземпляр QueryParams включает пару имя/значение, в которой значение — пусто, он ДОЛЖЕН интерпретироваться так, как будто этот параметр запроса полностью опущен.

Метод poll (опрос) или метод subscribe (подписка) ДОЛЖНЫ ответить с помощью исключения QueryParameterException (Исключение_по_Параметру_Запроса) в любом из следующих обстоятельств:

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

8.2.5.1 Элементы управления подпиской

Подписка на длительные запросы производится через метод subscribe (подписка). Для каждой подписки экземпляр SubscriptionControls (Управление_Подпиской) определяет, как будет обрабатываться запрос.

Поля экземпляра SubscriptionControls (Управление_Подпиской) определены в &таблице 26&.

&Таблица 26&

8.2.5.2 Автоматическое ограничение на основе времени записи события

Каждая подписка на запрос приводит к выполнению запроса несколько раз подряд, причем время каждого выполнения контролируется заданным аргументом schedule (расписание) или запускается условием запуска, заданным аргументом trigger (запуск). Наличие нескольких выполнений одного запроса является разумным только в том случае, если каждое выполнение ограничено объемом данных новых событий, сгенерированных с момента последнего выполнения. В противном случае одни и те же события будут возвращаться более одного раза. Однако временные ограничения не могут быть явно указаны в запросе или параметрах запроса, поскольку они не меняются от одного выполнения к другому.

По этой причине сервис EPCIS ДОЛЖЕН ограничить объем выполнения каждого запроса для запроса по подписке следующим образом. В первый раз, когда запрос выполняется для данной подписки, рассматриваются только те события, значение поля recordTime (время_Записи) которых больше или равно значению параметра initialRecordTime (время_Первой_Записи), указанному при создании подписки. При каждом выполнении запроса, следующего за первым, рассматриваются только те события, значение поля recordTime (время_Записи) которых больше или равно значению времени выполнения последнего запроса. Реализация зависит от того, насколько отказ от доставки результатов запроса подписчику влияет на этот расчет. Реализациям СЛЕДУЕТ предпринимать все усилия для обеспечения надежной доставки результатов запроса, чтобы подписчик не пропустил каких-либо данных. Запрос или параметры запроса могут определять дополнительные ограничения во время записи. Они применяются после ограничения совокупности событий, как описано выше.

Примечание - Одно возможное выполнение этого требования состоит в том, что сервис EPCIS поддерживает значение minRecordTime (минимальное_Время_Записи) для каждой существующей подписки. Значение minRecordTime (минимальное_Время_Записи) для данной подписки изначально устанавливается в initialRecordTime (время_Первой_Записи) и обновляется до значения текущего времени каждый раз, когда выполняется запрос для этой подписки. Каждый раз, когда выполняется запрос, рассматриваются только те события, значение поля recordTime (время_Записи) которых больше или равно значению minRecordTime (минимальное_Время_Записи) для этой подписки.

8.2.5.3 Расписание запросов (Query Schedule)

Тип QuerySchedule (Расписание_Запросов) служит для определения расписания периодического выполнения запроса для конкретной подписки. Каждое поле типа QuerySchedule (Расписание_Запросов) — это строка, задающая шаблон для сопоставления с некоторым интервалом текущего времени. Запрос будет выполняться каждый раз, когда текущие дата и время совпадают с данными в поле QuerySchedule (Расписание_Запросов).

Каждое поле типа QuerySchedule (Расписание_Запросов) — это строка, значение которой должно соответствовать следующим грамматическим правилам:

Каждое значение Number (Число), которое является частью значения поля расписания запросов (QuerySchedule), должно попадать в разрешенный для этого поля диапазон, как указано в таблице &27&. Реализация EPCIS ДОЛЖНА ответить с помощью исключения SubscriptionControlsException (Исключение_Управления_Подпиской), если любое значение поля расписания запросов (QuerySchedule) не соответствует грамматическим правилам, приведенным выше, или содержит значение Number (Число), которое выпадает из разрешенного диапазона, или включает значение диапазона Range (Диапазон), в котором значение первого параметра Number (Число) больше, чем значение второго параметра Number (Число).

Тип QuerySchedule (Расписание_Запросов) определяет периодическую последовательность временных значений («время запроса»). Время запроса — это любое временнте значение, которое соответствует типу QuerySchedule (Расписание_Запросов), удовлетворяя при этом следующему правилу:

• получив значение времени, извлекают секунду, минуту, час (от 0 до 23 включительно), день месяца (от 1 до 31 включительно) и день недели (от 1 до 7 включительно, обозначая дни недели с понедельника по воскресенье). Данный расчет будет выполняться в соответствии с часовым поясом, выбранным сервисом EPCIS;
• временнте значение соответствует типу QuerySchedule (Расписание_Запросов), если каждое из извлеченных значений подходит (как указано ниже) соответствующему полю типа QuerySchedule (Расписание_Запросов) для всех заданных полей QuerySchedule (Расписание_Запросов);
• значение, извлеченное из временнтго значения, совпадает с полем типа QuerySchedule (Расписание_Запросов), если оно соответствует любому из разделенных запятыми элементов Element (Элемент) поля типа QuerySchedule (Расписание_Запросов);
• значение, извлеченное из временнтго значения, совпадает с элементом Element (Элемент) поля QuerySchedule (Расписание_Запросов), если
• Element (Элемент) является числом Number (Число) и значение, извлеченное из временнтго значения, равно значению Number (Число);

или

• Element (Элемент) является Range (Диапазон) и значение, извлеченное из временнтго значения, больше или равно первому значению Number (Число) в диапазоне значений Range (Диапазон) и меньше или равно второму значению Number (Число) в диапазоне значений Range (Диапазон).

См. примеры после таблицы &27&.

Реализация EPCIS ДОЛЖНА интерпретировать тип QuerySchedule (Расписание_Запросов) как заявление клиента о том, когда он хотел бы выполнить запрос, и ДОЛЖНА предпринять разумные усилия, чтобы придерживаться этого графика. Однако реализация EPCIS МОЖЕТ отклоняться от запрошенного расписания, согласуя свои действия с собственными правилами относительно загрузки сервера, авторизации или по любой другой причине. Если во время вызова метода subscribe (подписка) реализация EPCIS знает, что она не сможет соблюдать указанное в поле QuerySchedule (Расписание_Запросов) расписание без существенного отклонения от запроса, реализация EPCIS ДОЛЖНА ответить с помощью исключения SubscriptionControlsException (Исключение_Управления_Подпиской).

Примечание - Расписание в поле QuerySchedule (Расписание_Запросов), принятое буквально, указывает точное время выполнения запроса с точностью до секунды. На практике реализация может не пожелать или быть неспособной точно выполнить запрос, но может выполнить общее намерение. Например, расписание в поле QuerySchedule (Расписание_Запросов) может задать выполнение запроса в момент точного значения каждого часа, в то время как реализация может выбрать выполнение запроса каждый час плюс-минус пять минут от момента точного значения часа. Вышеприведенный параграф предназначен для предоставления свободы реализации для такого вида отклонений.

В любом случае автоматическая обработка поля recordTime (время_Записи), как было указано ранее, ДОЛЖНА быть основана на фактическом времени выполнения запроса, независимо от того, насколько точно оно соответствует типу QuerySchedule (Расписание_Запросов).

Значения поля экземпляра QuerySchedule (Расписание_Запросов) выглядят следующим образом &(см. таблицу 27)&.

&Таблица 27&

8.2.5.3.1 Примеры расписания запросов (справочная информация)

Ниже приведено несколько примеров типа QuerySchedule (Расписание_Запросов) и объяснение того, что они означают.

&Пример 1&

Это означает «запускать запрос один раз в час, в начале часа». Если значение аргумента reportIfEmpty (пустой_ли_Отчет) для метода subscribe (подписка) — false (ложно), то отсутствует необходимость запускать отчет для отсылки каждый час: отчет будет отправлен в течение часа после появления новых данных о событиях, соответствующих запросу.

&Пример 2&

Это означает «запускать запрос один раз в час в начале каждого часа, но только в рабочие дни».

&Пример 4&

Это означает «запускать запрос один раз в секунду в диапазоне между 2:00:00 и 2:59:59 ежедневно». Этот пример показывает, что обычно не желательно пропускать поле с более тонкой детализацией, чем указанные поля.

8.2.5.4 QueryResults (Результаты запроса)

Экземпляр QueryResults (Результаты_Запроса) синхронно возвращается методом poll (опрос) интерфейса EPCIS управления запросами, а также синхронно направляется подписчику длительного запроса через интерфейс EPCIS обратных вызовов по запросам.

Поля экземпляра QueryResults (Результаты_Запроса) определены в &таблице 28&.

&Таблица 28&

8.2.6 Условия возникновения ошибок

Методы прикладного программного интерфейса (API — application programming interface) интерфейса EPCIS управления запросами сигнализируют клиенту об ошибках с помощью исключений. Определены следующие исключения. Все типы исключений, приведенные в таблице &29&, являются общим базовым типом EPCISException (Исключение_EPCIS), содержащим один обязательный элемент строки, указывающий причину исключения.

&Таблица 29&

Исключения, которые могут быть выбраны каждым методом интерфейса EPCIS управления запросами, указаны в таблице &30&:

&Таблица 30&

В дополнение к исключениям, полученным из методов интерфейса EPCIS управления запросами, перечисленным выше, попытка выполнения длительного запроса может привести к тому, что вместо обычного результата запроса подписчику через интерфейс EPCIS обратных вызовов по запросам отправляются исключения QueryTooLargeException (Исключение_при_Превышении_Объема Запроса) или ImplementationException (Исключение_по_Реализации). В этом случае исключения QueryTooLargeException (Исключение_при_Превышении_Объема Запроса) или ImplementationException (Исключение_по_Реализации) ДОЛЖНЫ включать, помимо строки с причиной, имя запроса и параметр subscriptionID (удостоверение_подписки), как указано в вызове метода subscribe (подписка), который создал длительный запрос.

8.2.7 Предопределенные запросы для EPCIS

В стандарте EPCIS не предусмотрен язык запросов, с помощью которого клиент может выразить произвольный запрос данных. Вместо этого реализация EPCIS ДОЛЖНА предоставлять следующие предопределенные запросы, которые клиент может вызывать, используя методы poll (опрос) и subscribe (подписка) в интерфейсе EPCIS управления запросами. Каждый вызов метода poll (опрос) и subscribe (подписка) может включать параметры через аргумент params (параметры). Предопределенные запросы, определенные в этом подразделе, имеют большое количество необязательных параметров. При соответствующем выборе параметров клиент может получить различные результаты.

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

8.2.7.1 Запрос SimpleEventQuery (Простой_Запрос_События)

Этот запрос вызывается путем указания строки SimpleEventQuery (Простой_Запрос_События) в качестве аргумента queryName (имя_Запроса) для методов poll (опрос) или subscribe (подписка). Результатом является экземпляр QueryResults (Результаты_Запроса), основа которого содержит (возможно, пустой) список экземпляров EPCISEvent (Событие_EPCIS). При отсутствии ограничений параметром eventType (тип_События) каждый элемент списка результатов может иметь любой тип события, т.е. ObjectEvent (Событие_с_Объектом), AggregationEvent (Событие_с_Агрегацией), QuantityEvent (Событие_с_Количеством_Объектов), TransactionEvent (Событие_с_Документом_Транзакции) или любой тип события расширения, которое является подклассом EPCISEvent (Событие_EPCIS).

Запрос SimpleEventQuery (Простой_Запрос_События) ДОЛЖЕН быть доступен как через метод poll (опрос), так и через метод subscribe (подписка), то есть реализация НЕ ДОЛЖНА использовать исключение SubscribeNotPermittedException (Исключение_при_Недопустимой_Подписке), если запрос SimpleEventQuery (Простой_Запрос_События) указывается как аргумент queryName (имя_Запроса) для метода subscribe (подписка).

Запрос SimpleEventQuery (Простой_Запрос_События) определен для того, чтобы возвращать набор событий, которые удовлетворяют критериям, указанным в параметрах запроса (как указано ниже в &таблице 31&). При возврате событий, зафиксированных через интерфейс EPCIS сбора данных, каждое событие, выбранное для возврата, должно быть идентично первоначально зафиксированному событию, с учетом положений по авторизации (см. 8.2.2), включения поля recordTime (время_Записи) и любых необходимых преобразований в абстрактное внутреннее представление и из него. Тем не менее для любого поля события, определенного для хранения неупорядоченного списка, реализация EPCIS НЕ ДОЛЖНА сохранять порядок.

Параметры для этого запроса приведены &в таблице 31&. Ни один из этих параметров не является обязательным (хотя в большинстве случаев запрос будет содержать хотя бы один параметр).

&Таблица 31&

Как следует из приведенных выше описаний, если указано несколько параметров, событие должно удовлетворять всем критериям для включения в результирующий набор. Другими словами, если каждый параметр рассматривается как логическое утверждение, все такие логические утверждения неявно соединяются как бы с помощью оператора И (AND). Например, если данный вызов метода poll (опрос) определяет значение для обоих параметров, EQ_bizStep (соответствие_по_Бизнес-этапу) и EQ_disposition (соответствие_по_Состоянию), тогда для включения в результат событие должно соответствовать одному из установленных значений поля bizStep (бизнес-этап) И (AND) совпадать с одним из установленных значений поля disposition (состояние).

С другой стороны, для тех параметров, значением которых является список, событие должно соответствовать по крайней мере одному из элементов списка, чтобы быть включенным в результирующий набор. Другими словами, если каждый элемент списка рассматривается как логическое утверждение, все такие логические утверждения для данного списка явно разъединяются как бы оператором ИЛИ (OR). Например, если значением параметра EQ_bizStep (соответствие_по_Бизнес-этапу) является список из двух элементов («bs1», «bs2»), то событие включается, если его поле bizStep (бизнес-этап) содержит значение bs1 ИЛИ (OR) его поле bizStep (бизнес-этап) содержит значение bs2.

В другом примере, если значение параметра EQ_bizStep (соответствие_по_Бизнес-этапу) является списком из двух элементов («bs1», «bs2»), а параметр EQ_disposition (соответствие_по_Состоянию) представляет собой список из двух элементов («d1», «d2»), то результат должен включать события, удовлетворяющие следующему логическому утверждению:

((bizStep = «bs1» OR bizStep = «bs2»)

AND (disposition = «d1» OR disposition = «d2»))

8.2.7.1.1 Обработка параметров запроса MATCH (совпадение_по)

Список параметров для MATCH_epc (совпадение_по_EPC), MATCH_parentID (совпадение_по_Идентификатору_Родителя), MATCH_inputEPC (совпадение_по_EPC_на_Входе), MATCH_outputEPC (совпадение_по_EPC_на_Выходе) и MATCH_anyEPC (совпадение_по_какому-либо_EPC)_ДОЛЖЕН обрабатываться следующим образом. Каждый элемент списка параметров может быть шаблоном чистого ключевого идентификатора (pure identity pattern), указанным в &[12]&, или любым другим идентификатором URI. Если элемент является шаблоном чистого ключевого идентификатора, он сопоставляется с значениями поля события, используя процедуру сопоставления шаблонов ключевого идентификатора, указанную в [&12&, раздел 8]. Если этот элемент является любым другим идентификатором URI, он сопоставляется со значениями полей события посредством проверки равенства строки.

Список параметров для MATCH_epcClass (совпадение_по_Классу_EPC), MATCH_inputEPCClass (совпадение_по_Классу_EPC_на_Входе), MATCH_outputEPCClass (совпадение_по_Классу_EPC_на_Выходе) и MATCH_anyEPCClass (совпадение_по какому-либо_Классу_EPC) ДОЛЖЕН обрабатываться следующим образом. Пусть P — один из шаблонов, указанных в значении этого параметра, и пусть C будет значением поля epcClass (epc_на_уровне_Класса) в соответствующем списке значений количества, рассматриваемого для включения в результат. Тогда событие включается в результат, если каждый компонент Pi из P совпадает с соответствующей компонентой Ci из C, где понятие «совпадает» определено в [&12&, раздел 8].

Примечание — Различие между параметрами MATCH_epcClass (совпадение_по_Классу_EPC) и MATCH_epc (совпадение_по_EPC), а также похожими параметрами, заключается в том, что для параметра MATCH_epcClass (совпадение_по_Классу_EPC) значение в событии (поле epcClass (epc_на_уровне_Класса) в списке значений количества) может само по себе являться шаблоном, как указано в 7.3.3.3). Это означает, что значение в событии может содержать в параметре запроса компоненту «». Например, если поле epcClass (epc_на_уровне_Класса) внутри события является urn: epc:idpat:sgtin:0614141.112345., то этому событию будет соответствовать параметр запроса urn: epc:idpat:sgtin:0614141.. или urn:epc:idpat:sgtin:0614141.112345.*, но не urn:epc:idpat:sgtin:0614141.112345.400.

8.2.7.2 Запрос SimpleMasterDataQuery (Простой_Запрос_Мастер_Данных)

Этот запрос вызывается путем указания строки SimpleMasterDataQuery (Простой_Запрос_Мастер_Данных) в качестве аргумента queryName (имя_Запроса) для метода poll (опрос). Результатом является экземпляр QueryResults (Результаты_Запроса), тело которого содержит (возможно, пустой) список лексических элементов вместе с выбранными атрибутами.

Запрос SimpleMasterDataQuery (Простой_Запрос_Мастер_Данных) ДОЛЖЕН быть доступен через метод poll (опрос), но не через метод subscribe (подписка); то есть реализация ДОЛЖНА ответить с помощью исключения SubscribeNotPermittedException (Исключение_при_Недопустимой_Подписке), если запрос SimpleMasterDataQuery (Простой_Запрос_Мастер_Данных) задан как аргумент queryName (имя_Запроса) для subscribe (подписка).

Параметры для этого запроса приведены в &таблице 32&:

&Таблица 32&

Как следует из приведенных выше описаний, если указано несколько параметров, то для включения в результирующий набор лексический элемент должен удовлетворять всем критериям. Другими словами, если каждый параметр рассматривается как логическое утверждение, то все такие логические утверждения неявно соединяются как бы с помощью оператора AND (И). Например, если данный вызов метода poll (опрос) определяет значение для обоих параметров, WD_name (соответствие_по_Имени_с_учетом_Потомков) и HASATTR (наличие_Ненулевого_Атрибута), то тогда для включения в результат лексический элемент должен быть потомком установленного элемента И владеть одним из указанных атрибутов.

С другой стороны, для тех параметров, значением которых является список, лексический элемент должен соответствовать по крайней мере одному из элементов списка для включения в результирующий набор. Другими словами, если каждый элемент списка рассматривается как логическое утверждение, то все такие логические утверждения для данного списка явно разъединяются как бы оператором OR (ИЛИ). Например, если значением параметра EQATTR_sample (соответствие_по_Атрибуту_Образец) является список из двух элементов («s1», «s2»), то лексический элемент включается, если он имеет атрибут sample (образец), значение которого соответствует s1 ИЛИ равно s2.

В другом примере, если значение параметра EQ_name (соответствие_по_Имени) является списком из двух элементов («ve1», «ve2»), а параметр EQATTR_sample (соответствие_по_Атрибуту_Образец) представляет собой список из двух элементов («s1», «s2»), то результат должен включать события, удовлетворяющие следующему логическому утверждению:

((name = «ve1» OR name = «ve2»)

AND (sample = «s1» OR sample = «s2»))

где name неформально ссылается на имя лексического элемента, а sample неформально ссылается на значение атрибута sample (образец).

8.2.8 Интерфейс обратных вызовов по запросам

Интерфейс обратных вызовов по запросам (Query Callback Interface) — это путь, по которому сервис EPCIS доставляет результаты длительного запроса клиенту.

Каждый раз, когда сервис EPCIS выполняет длительный запрос в соответствии с расписанием QuerySchedule (Расписание_Запросов), он ДОЛЖЕН попытаться доставить результаты подписчику посредством вызова одного из трех методов интерфейса обратных вызовов по запросам. Если запрос выполнен нормально, сервис EPCIS ДОЛЖЕН вызвать метод callbackResults (результаты_Обратного_Вызова). Если в результате выполнения запроса было применено исключение QueryTooLargeException (Исключение_при_Превышении_Объема_Запроса) или ImplementationException (Исключение_по_Реализации), сервис EPCIS ДОЛЖЕН вызвать соответствующий метод интерфейса обратных вызовов по запросам.

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

9 Привязки XML для модулей определения данных

Настоящий раздел определяет типовую привязку XML для модуля определения данных типов основных событий с использованием языка определения схемы для документов XML (XML Schema language) стандарта W3C (World Wide Web Consortium) см. &[19]&, &[18]&. Также приводятся примеры.

Схема, приведенная ниже, согласуется с правилами проектирования типовых схем GS1. Приведенная ниже схема импортирует типовую базовую схему EPCglobal в соответствии с правилами проектирования по &[20]&.

9.1 Механизм расширяемости

Схема XML в данном разделе реализует точку расширения <>, приведенную на языке UML в разделе 6, с использованием методологии, описанной в [&21&]. Эта методология предусматривает как расширение поставщика/пользователя, так и расширение в соответствии с правилами GS1 в будущих версиях данной спецификации или в дополнительных спецификациях. Расширения, внедренные через этот механизм, будут иметь совместимость снизу вверх, так как документы, соответствующие старым версиям схемы, будут также соответствовать более новым версиям типовой схемы и схеме, содержащей расширения для конкретных поставщиков. Расширения также будут совместимы снизу вверх с будущими версиями, поскольку документы, содержащие расширения поставщиков/пользователей или соответствующие более новым версиям типовой схемы, также будут соответствовать более старым версиям схемы.

Если документ содержит расширения (для конкретных поставщиков/пользователей или стандартизированных в более новых версиях схемы), он может соответствовать более чем одной схеме. Например, документ, содержащий расширения поставщиков до схемы GS1 версии 1.0 &по& [&3&], будет соответствовать как схеме GS1 версии 1.0 &по& [&3&], так и схеме конкретного поставщика, которая включает расширения поставщика. В этом примере при анализе документа с использованием типовой схемы не будет проверки элементов и атрибутов расширения, но при анализе документа с использованием схемы, зависящей от поставщика, расширения должны быть проверены. Аналогично документ, содержащий новые функции, представленные в схеме &согласно настоящему стандарту& и [&2&], будет соответствовать как схеме &по& [&3&], так и схеме &по& [&4&] и схеме &согласно настоящему стандарту& и [&2&], но проверка новых функций будет доступна только при использовании схемы &согласно настоящему стандарту& и [&2&].

Правила проектирования для этого шаблона расширяемости приведены в документе &[21]&. В итоге они сводятся к следующему:

• Для каждого типа, в котором встречается точка расширения <>, включают объявление xsd:anyAttribute. Это объявление предусматривает добавление новых атрибутов XML либо в последующих версиях типовой схемы, либо в схеме поставщика/пользователя.
• Для каждого типа, в котором встречается точка расширения <>, включают необязательный элемент (minOccurs = 0) с именем extension (расширение). Тип, объявленный для элемента extension (расширение), будет всегда выглядеть так:

xsd:sequence

<xsd:any processContents=«lax» minOccurs=«1» maxOccurs=«unbounded»

namespace=«##local»/>

</xsd:sequence>

<xsd:anyAttribute processContents=«lax»/>

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

• Для каждого типа, в котором встречается точка расширения <>, включают в конце элемента список объявлений

<xsd:any processContents=«lax» minOccurs=«0» maxOccurs=«unbounded»

namespace=«##other»/>

Это объявление обеспечивает совместимость снизу вверх с новыми элементами, введенными в схему конкретного поставщика/пользователя.

Правила добавления расширений конкретных поставщиков/пользователей в схему следующие:

• атрибуты конкретного поставщика/пользователя могут быть добавлены к любому типу, в котором встречается точка расширения <>. Атрибуты конкретного поставщика/пользователя НЕ ДОЛЖНЫ находиться в пространстве имен EPCglobal EPCIS (urn:epcglobal:epcis:xsd:1) или в пустом пространстве имен. Атрибуты конкретного поставщика/пользователя ДОЛЖНЫ находиться в пространстве имен, идентификатор формата URI которого содержит имя поставщика в качестве организации-владельца. (На языке схемы это означает, что все атрибуты, зависящие от поставщика/пользователя, должны быть указаны в форме qualified (составное_имя). Например, пространству имен URI может принадлежать адрес URL протокола HTTP, полномочная часть которого является доменным именем, принадлежащим поставщику/пользователю; имя URN, имеющее идентификатор пространства имен URN, выданный поставщику/пользователю организацией IANA; имя OID URN, начальным путем которого является номер частного предприятия (Private Enterprise Number), присвоенный поставщику/пользователю, и т.д. Объявления атрибутов конкретного поставщика/пользователя ДОЛЖНЫ устанавливать use=>>optional>>;
• элементы конкретного поставщика/пользователя могут быть добавлены к любому типу, в котором присутствует точка расширения <>. Элементы конкретного поставщика/пользователя НЕ ДОЛЖНЫ находиться в пространстве имен EPCglobal EPCIS (urn:epcglobal:epcis:xsd:1) или в пустом пространстве имен. Элементы конкретного поставщика/пользователя ДОЛЖНЫ находиться в пространстве имен, идентификатор URI которого содержит имя поставщика в качестве организации-владельца (как описано выше). (На языке схемы это означает, что все элементы, зависящие от поставщика/пользователя, должны быть указаны в форме qualified (составное_имя).

Для создания схемы, которая содержит расширения поставщика/пользователя, производят замену объявления <xsd:any ... namespace=«##other»/> ссылкой на группу контента для группы, определенной в пространстве имен поставщика/пользователя. Например, <xsd:group ref=«vendor:VendorExtension»>. В данной схеме файл, определяющий элементы для пространства имен поставщика/пользователя, определяет группу контента, используя объявление в следующей форме:

(В последующих иллюстрациях vendor (поставщик) и VendorExtension (Расширение_Поставщика) могут быть любыми строками, которые выберет поставщик/пользователь).

Примечание - Поскольку элементы, зависящие от конкретных поставщиков/пользователей, должны быть необязательны, включение ссылок на их определения непосредственно в схему EPCIS будет нарушать ограничение присвоения уникальной частицы (Unique Particle Attribution) схемы XML, так как элемент xsd:any... в схеме EPCIS также может соответствовать элементам, зависящим от поставщика/пользователя. Перемещение xsd:any... в схему поставщика/пользователя устраняет эту проблему, потому что ##other в этой схеме означает «совпадение с элементом, который имеет пространство имен, отличное от пространства имен поставщика/пользователя». Это не вступает в конфликт с типовыми элементами, так как форма элемента по умолчанию для типовой схемы EPCIS является unqualified (неуточненный), и, следовательно, ##other в схеме поставщика/пользователя также не соответствует типовым элементам EPCIS.

Правила для добавления атрибутов или элементов в будущие версии типовой схемы GS1 следующие:

• Типовые атрибуты могут быть добавлены к любому типу, в котором встречается точка расширения <>. Типовые атрибуты НЕ ДОЛЖНЫ принадлежать ни одному пространству имен (т.е. ДОЛЖНЫ находиться в пустом пространстве имен) и НЕ ДОЛЖНЫ конфликтовать с любым существующим именем типового атрибута.
• Типовые элементы могут быть добавлены к любому типу, в котором встречается точка расширения <>. Новые элементы добавляются по следующим правилам:
• Находят самый глубокий вложенный тип элемента extension (расширение).
• Заменяют объявление <xsd:any ... namespace=«##local»/> на (a) новые элементы (которые НЕ ДОЛЖНЫ принадлежать ни одному пространству имен, другими словами, которые ДОЛЖНЫ находиться в пустом пространстве имен), за которыми следует (b) новый элемент extension, тип которого строится, как описано выше. В последующих версиях типовой схемы новые типовые элементы будут скорее добавлены в этот новый элемент extension (расширение)..

Примечание - Причиной того, что новые типовые атрибуты и элементы, указанные выше, не должны находиться в каком-либо пространстве имен, является то, что они должны быть совместимы с атрибутом схемы EPCIS и с формой элемента по умолчанию unqualified.

Применительно к схеме XML &настоящего стандарта& (EPCIS &версия& 1.2) для основных событий (см. 9.5) это приводит к следующему:

Типы событий, определенные в &[3]& (EPCIS &версия& 1.0), появляются в элементе (<Список_Событий>).

Каждый из типов событий, определенных в &[4]& (EPCIS &версия& 1.1) (т.е. TransformationEvent (Событие_с_Преобразованием)), появляется внутри элемента (<расширение>) в элементе (<Список_Событий>).

Для типов событий, определенных в &[3]& (EPCIS &версия& 1.0), новые поля, добавленные в &[4]& (EPCIS &версия& 1.1), появляются в элементе (<расширение>), следующем за полями &[3]& (EPCIS &версия& 1.0). Если в будущую версию EPCIS будут добавлены дополнительные поля, они появятся во втором элементе (<расширение>), вложенном в первый элемент (<расширение>), следующий за полями стандарта &[4]& (EPCIS &версия& 1.1). Новые поля, добавленные в настоящем стандарте и &[2]& (EPCIS &версия& 1.2) в местах, где в &[4]& (EPCIS &версия& 1.1) не было добавлено новых полей (т.е. errorDeclaration (Заявление_об_Ошибке)), появляются в элементе (<расширение>) после полей, определенных в &[3]& (EPCIS &версия& 1.0).

Для типов событий, определенных в &[4]& (EPCIS &версия& 1.1), нет элемента (<расширение>), поскольку в &[4]& (EPCIS &версия& 1.1) весь тип события является новым. Если в будущей версии стандарта EPCIS будут добавлены дополнительные поля, они появятся в элементе (<расширение>) после полей, определенных в &[4]& (EPCIS &версия& 1.1).

Расширения на уровне событий поставщика/пользователя всегда появляются непосредственно перед закрывающим тэгом события (т.е. после любых типовых полей и любого элемента (<расширение>)) и всегда находятся в непустом пространстве имен XML. Ни при каких обстоятельствах расширения поставщика/пользователя не появляются внутри элемента (<расширение>). Элемент (<расширение>) зарезервирован для полей, определенных в самом стандарте EPCIS.

Примеры см. в подразделе 9.6.

9.2 Типовой заголовок бизнес-документа

Привязки XML для модуля определения данных типов основных событий включают необязательный элемент EPCISHeader (Заголовок_EPCIS), который может использоваться отраслевыми группами для включения дополнительной информации, требуемой для обработки в рамках этой отрасли. Основная схема включает «типовой заголовок бизнес-документа» (Standard Business Document Header — SBDH), определенный в &[22]& как необходимый компонент элемента EPCISHeader (Заголовок_EPCIS). Отраслевым группам МОГУТ также потребоваться некоторые другие виды заголовка внутри элемента EPCISHeader (Заголовок_EPCIS) дополнительно к SBDH.

Схему XSD для типового заголовка бизнес-документа можно получить с веб-сайта СЕФАКТ ООН (UN/CEFACT), см. &[22]&. Эта схема включена сюда с помощью ссылки.

Если включен типовой заголовок бизнес-документа, то для элементов схемы SBDH по &[22]& ДОЛЖНЫ быть использованы указанные ниже значения, &приведенные в таблице 33&.

&Таблица 33&

Значение для поля DocumentIdentification/Type (Идентификация_Документа/Тип) ДОЛЖНО быть установлено в соответствии со следующей таблицей &34&, устанавливающей значение для этого поля, основываясь на виде документа EPCIS и контексте, в котором он используется.

&Таблица 34&

Привязка протокола AS2 для интерфейса управления запросами (см. 11.3) также задает дополнительные поля типового заголовка бизнес-документа, которые должны быть представлены в экземпляре EPCISQueryDocument (Документ_Запроса_EPCIS), используемом в качестве ответного сообщения интерфейса управления запросами. Подробности см. в 11.3.

В дополнение к полям, указанным выше, типовой заголовок бизнес-документа ДОЛЖЕН включать все другие поля, которые требуются схемой SBDH, и МОЖЕТ включать дополнительные поля SBDH. Во всех случаях значения для этих полей ДОЛЖНЫ быть установлены в соответствии с &[22]&. Отраслевая группа МОЖЕТ указать дополнительные ограничения на контенты SBDH, которые будут использоваться внутри этой отраслевой группы, однако такие ограничения ДОЛЖНЫ соответствовать указанным здесь спецификациям.

9.3 Базовая схема EPCglobal

Привязка XML для модуля определения данных типов основных событий, так же как и другие привязки XML в этой спецификации, ссылаются на базовую схему EPCglobal. Эта схема воспроизводится ниже.

9.4 Мастер-данные в привязке XML

Как было отмечено в 6.1.1, EPCIS предусматривает четыре способа передачи мастер-данных. Эти четыре способа поддерживаются различными частями XML схемы, указанной в настоящем разделе, как описано в таблице &35&:

&Таблица 35&

Каждый атрибут мастер-данных представляет собой пару имя/значение, в которой имя как часть этой пары является составным именем, состоящим из идентификатора URI пространства имен и локального имени, а значение как другая часть пары представляет собой любой тип данных, выражаемый в формате XML. Вне зависимости от использования любого из четырех вышеуказанных механизмов передачи мастер-данных, передаваемые данные ДОЛЖНЫ всегда использовать для определенного атрибута одни и те же идентификатор URI пространства имен и локальное имя. Однако способы, при помощи которых осуществляется кодирование идентификатора URI пространства имен и локального имени в XML, отличаются в зависимости от выбранного механизма:

• для элементов МДЭП (ILMD) атрибутом мастер-данных ДОЛЖЕН являться элемент XML, именем элемента которого является составное имя с префиксом, привязанным к идентификатору URI пространства имени атрибута мастер-данных, а локальным именем составного имени является локальное имя атрибута мастер-данных. Содержанием элемента ДОЛЖНО быть значение атрибута мастер-данных;
• для механизмов, использующих VocabularyElement (Лексический_Элемент), идентификационным id атрибутом VocabularyElement (Лексический_Элемент) ДОЛЖНА быть строка, состоящая из идентификатора URI пространства имени, знака «номер» (#) и локального имени. Содержанием VocabularyElement (Лексический_Элемент) ДОЛЖНО быть значение атрибута мастер-данных.

Пример: Рассматривают атрибут мастер-данных с идентификатором URI пространства имени http://epcis.example.com/ns/md, локальным именем myAttrName и значением в виде цепочки myAttrValue. Ниже показано представление данного атрибута в разделе МДЭП (ILMD):

Представление данного атрибута в VocabularyElement (Лексический_Элемент):

<VocabularyElement

id=«http://epcis.example.com/ns/md#myAttrName»>

myAttrValue

(Знаки «перевод строки» и «пробел» добавлены с каждой из сторон myAttrValue для большей ясности, но в реальном сообщении XML они бы не присутствовали.)

НЕ РЕКОМЕНДУЕТСЯ: Связка XML для модуля определения данных типов основных событий предусматривает механизм для включения дополнительной информации в поля readPoint (место_Считывания) и bizLocation (производственное_Место_Назначения) всех типов событий посредством включения дополнительных подэлементов внутри этих полей после необходимого идентификационного подэлемента. Этот механизм был изначально задуман как средство передачи мастер-данных для идентификаторов места нахождения. Однако настоящим стандартом и [&2&] (EPCIS &версия& 1.2) НЕ РЕКОМЕНДУЕТСЯ его использование, и он НЕ ДОЛЖЕН использоваться в данных EPCIS, соответствующих настоящему стандарту и [&2&], а также более поздним версиям. Вместо него следует использовать один или несколько прочих механизмов передачи мастер-данных.

9.5 Схема для типов основных событий

Ниже приведена схема XML (XSD) для модуля определения данных типов основных событий. Эта схема импортирует дополнительные схемы, как показано в таблице &36&.

&Таблица 36&

В дополнение к ограничениям, которые предполагает данная схема, значение типа xsd:dateTime в экземпляре документа ДОЛЖНО включать идентификатор часового пояса (либо «Z» для всемирного координированного времени, UTC, либо явный временной сдвиг относительно всемирного координированного времени, UTC).

Для любого элемента XML, который определяет значение minOccurs=«0» типа xsd:anyURI, xsd:string или типа, производного от одного из этих двух, реализация EPCIS ДОЛЖНА обрабатывать экземпляр, имеющий пустую строку в качестве своего значения, точно тем же способом, как если бы элемент отсутствовал вовсе. То же самое верно для любого атрибута XML подобного типа, который определяет значение use=«optional».

Эта схема также включает привязку XML мастер-данных для модуля определения данных типов основных событий. Сегменты схемы, содержащие мастер-данные, используются для (a) возврата результатов по запросу типа SimpleMasterDataQuery (Простой_Запрос_Мастер_Данных) (см. 8.2.7.2), (b) формирования основной части документа мастер-данных, как определено в подразделе 9.7, и (c) для предоставления необязательного раздела мастер-данных заголовка EPCIS, который может использоваться в документе EPCIS или документе запроса EPCIS.

Элемент высокого уровня EPCISDocument (Документ_EPCIS), определенный в схеме, используется конкретными привязками интерфейса EPCIS сбора данных, указанными в разделе 10. Торговые партнеры могут также по взаимному согласию дополнительно использовать документ EPCIS как средство передачи набора событий EPCIS, при необходимости дополненного соответствующими мастер-данными, в виде единого электронного документа.

Документ EPCIS МОЖЕТ включать мастер-данные в заголовке. Это позволяет создателю документа EPCIS включить мастер-данные, которые могут потребоваться получателю документа для осуществления запроса с использованием интерфейса запросов EPCIS. Не существует требований в отношении включения мастер-данных в заголовок документа EPCIS, включения в мастер-данные в заголовке мастер-данных для каждого идентификатора, используемого в основной части документа EPCIS, или ограничения мастер-данных в заголовке исключительно теми идентификаторами, которые используются в основной части документа EPCIS. Однако, если мастер-данные в заголовке все же относятся к идентификатору в основной части, они ДОЛЖНЫ представлять собой актуальные мастер-данные для этого идентификатора на момент создания документа EPCIS. Получатель документа EPCIS, в том числе система, реализующая применение интерфейса EPCIS сбора данных, может по своему усмотрению использовать или игнорировать такие мастер-данные. Мастер-данные в заголовке документа EPCIS НЕ ДОЛЖНЫ указывать значения атрибутов, противоречащие разделу МДЭП (ILMD) любого из событий, содержащихся в основной части документа EPCIS.

Схема XML (XSD) для модуля определения данных типов основных событий приводится ниже:

9.6 Типы основных событий. Примеры (справочная информация)

В настоящем подразделе приведены примеры типов EPCISDocuments (Документы_EPCIS), представленных в XML по &[23]&.

9.6.1 Пример 1 — События типа Object Events (События с Объектами) с идентификацией на уровне экземпляра

Пример в этом подразделе содержит два события типа ObjectEvent (Событие_с_Объектом), каждое из которых содержит идентификацию на уровне экземпляра. В этом примере используются только функции из &[3]& (EPCIS &версия& 1.0) и лексикон из &[24]& (CBV &версия& 1.1). Второе событие показывает элемент расширения поставщика/пользователя на уровне события с именем myField, следуя методу для расширений поставщика/пользователя, указанному в подразделе 9.1.

9.6.2 Пример 2 — Событие типа Object Event с идентификацией на уровне класса

Пример в этом подразделе содержит одно событие типа ObjectEvent (Событие_с_Объектом), содержащее идентификацию только на уровне класса. Следует обратить внимание на то, что элемент (<список_EPC>) все же представлен, хотя и пустой, как того требует схема XML для обеспечения обратной совместимости с &[3]& (EPCIS &версия& 1.0). Элемент QuantityList (Список_Количество) наряду с другими элементами, новыми для &[4]& (EPCIS &версия& 1.1), находится в области (<расширение>), которая зарезервирована для новых функций в [&4&] (EPCIS &версия& 1.1) (см. подраздел 9.1). Расширение поставщика/пользователя с именем myField также включено.

9.6.3 Пример 3. Событие типа Aggregation Event со смешанной идентификацией

Пример в этом подразделе содержит одно событие типа AggregationEvent (Событие_с_Агрегацией), содержащее события-потомки, имеющие идентификацию как на уровне экземпляра, так и на уровне класса. ChildQuantityList (список_Количества_Потомков) находится в области (<расширение>), которая зарезервирована для новых функций в &[4]& (EPCIS &версия& 1.1) (см. подраздел 9.1). Расширение поставщика/пользователя с именем myField также включено.

9.6.4 Пример 4. Событие типа Transformation Event

Пример в этом подразделе содержит одно событие типа TransformationEvent (Событие_с_Преобразованием), содержащее потомков, имеющих идентификацию как на уровне экземпляра, так и на уровне класса. Мастер-данные Экземпляра/Партии (МДЭП, ILMD) также включены и описывают выходные данные преобразования. Расширение поставщика/пользователя с именем myField также включено. Событие целиком включено в элемент (<расширение>) для EventList (Список_Событий), который зарезервирован для новых типов событий в стандарте &[4]& (EPCIS &версия& 1.1) (см. подраздел 9.1).

9.7 Схема для мастер-данных

Ниже приведена схема XML (XSD), определяющая документ мастер-данных EPCIS. Документ мастер-данных EPCIS может быть использован по взаимному согласию для передачи мастер-данных. Схема импортирует дополнительные схемы, как показано в таблице &37&.

&Таблица 37&

В дополнение к ограничениям, налагаемым схемой, любое значение типа xsd:dateTime в документе экземпляра ДОЛЖНО включать спецификатор часового пояса (либо «Z» для всемирного координированного времени, UTC, либо явный временной сдвиг относительно всемирного координированного времени UTC).

Для любого элемента XML типа xsd:anyURI или типа xsd:string, который задает значение minOccurs=«0», реализация EPCIS ДОЛЖНА обрабатывать экземпляр, имеющий пустую строку в качестве значения, точно так же, как если бы этот элемент вообще отсутствовал.

Эта схема включает заголовок EPCIS из схемы типов основных событий, указанной в подразделе 9.5. Такой заголовок предоставляет возможность включения мастер-данных при необходимости. Однако документ мастер-данных EPCIS (документ XML, корневым элементом которого является EPCISMasterDataDocument (Документ_Мастер-Данных_EPCIS), определенный в приведенной ниже схеме) НЕ ДОЛЖЕН включать необязательный элемент EPCISMasterData (Мастер-Данные_EPCIS) в своем заголовке EPCIS.

Ниже приводится схема XML (XSD) для мастер-данных:

9.8 Мастер-данные. Пример (справочная информация)

Ниже приводится пример элемента EPCISMasterDataDocument (Документ_Мастер-Данных_EPCIS), содержащего мастер-данные для лексиконов BusinessLocation (Производственное_Место_Назначения) и ReadPoint (место_Считывания), представленных в XML &[23]&:

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

Данный раздел определяет привязки для модуля основных операций сбора данных (Core Capture Operations Module). Все привязки, указанные здесь, основываются на представлении событий XML, определенных в подразделе 9.5. Как указано ниже, реализация EPCIS МОЖЕТ обеспечить поддержку одной или более привязок модуля основных операций сбора данных.

10.1 Привязка очереди сообщений

В данном подразделе определяется привязка модуля основных операций сбора данных к системе очереди сообщений, как это обычно реализуется на крупных предприятиях. Система очереди сообщений определена для данного подраздела как любая система, которая позволяет одному приложению отправлять сообщение XML другому приложению. Системы очереди сообщений обычно поддерживают как доставку сообщения типа точка-точка, так и доставку сообщений типа публикации/подписки. Системы очереди сообщений часто включают в себя функции гарантированной надежной доставки, а также другие гарантии качества обслуживания (quality-of-service — QoS).

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

Реализация EPCIS МОЖЕТ обеспечить привязку очереди сообщений к модулю основных операций сбора данных следующим образом. Для этой привязки «клиентом сбора данных» является приложение EPCIS по сбору данных (EPCISCapture Application), которое намеревается доставить Событие EPCIS через интерфейс EPCIS сбора данных (EPCIS Capture Interface), а «сервер сбора данных» — это репозиторий EPCIS (EPCIS Repository) или приложение EPCIS доступа (EPCIS Accessing Application), которое получает событие от клиента сбора данных.

Сервер сбора данных ДОЛЖЕН предоставить одну или несколько конечных точек очереди сообщений, через которые клиент сбора данных может доставить одно или несколько событий EPCIS. Каждая конечная точка очереди сообщений МОЖЕТ быть очередью типа точка-точка, заголовком публикации/подписки или каким-либо другим соответствующим адресуемым каналом, предоставляемым системой очереди сообщений. Подробные сведения выходят за рамки данной спецификации.

Клиент сбора данных ДОЛЖЕН выполнить операцию capture (сбор_данных), описанную в 8.1.2, с помощью доставки сообщения в конечную точку, предоставленную сервером сбора данных. Сообщение ДОЛЖНО быть одним из следующих:

• документ XML, корневой элемент которого соответствует элементу EPCISDocument (Документ_EPCIS), как определено схемой подраздела 9.5; или
• документ XML, корневой элемент которого соответствует элементу EPCISQueryDocument (Документ_Запроса_EPCIS), как определено схемой подраздела 11.1, где элемент, непосредственно вложенный в элемент EPCISBody (Тело_EPCIS), является элементом QueryResults (Результаты_Запроса), а элемент resultsBody (тело_Результата) внутри элемента QueryResults (Результаты_Запроса) содержит элемент EventList (Список_Событий).

Реализация интерфейса сбора данных ДОЛЖНА принять форму элемента EPCISDocument (Документ_EPCIS) и форму элемента EPCISQueryDocument (Документ_Запроса_EPCIS). Реализация интерфейса сбора данных НЕ ДОЛЖНА принимать документы, которые не имеют силы, как это указано выше. Успешное принятие этого сообщения сервером ДОЛЖНО представлять собой фиксирование всех событий EPCIS, включенных в сообщение.

Системы очереди сообщений различаются по своей способности предоставлять положительные и отрицательные подтверждения отправителям сообщений. Если в системе очереди сообщений имеется функция положительного подтверждения, положительное подтверждение МОЖЕТ использоваться для указания успешного фиксирования сервером сбора данных. Если в системе очереди сообщений имеется функция отрицательного подтверждения, отрицательное подтверждение МОЖЕТ использоваться для указания на отказ выполнить операцию сбора данных. Отказ может быть вызван недействительным документом, сбоем авторизации, как описано в 8.1.1, или по какой-либо другой причине. Конкретные обстоятельства, при которых указывается положительное или отрицательное подтверждение, зависят от реализации. Тем не менее все реализации ДОЛЖНЫ либо принимать все события в сообщении, либо отклонять все события.

10.2 Привязка к протоколу HTTP

В данном подразделе определяется привязка модуля основных операций сбора данных к протоколу HTTP &[25]&.

Реализация EPCIS МОЖЕТ обеспечить HTTP привязку к модулю основных операций сбора данных следующим образом. Для этой привязки «клиентом сбора данных» является приложение EPCIS сбора данных, которое хочет доставить событие EPCIS через интерфейс EPCIS сбора данных, а «сервер сбора данных» — это репозиторий EPCIS или приложение EPCIS по организации доступа, которое получает событие от клиента сбора данных.

Сервер сбора данных ДОЛЖЕН предоставить URL адрес протокола HTTP, через который клиент сбора данных может доставить одно или несколько событий EPCIS.

Клиент сбора данных ДОЛЖЕН выполнить операцию capture (сбор_данных), описанную в 8.1.2, с помощью вызова операции POST протокола HTTP по URL адресу, предоставленному сервером сбора данных. Содержание сообщения ДОЛЖНО быть одним из следующих:

• документ XML, корневой элемент которого соответствует элементу EPCISDocument (Документ_EPCIS), как определено схемой подраздела 9.5, или
• документ XML, корневой элемент которого соответствует элементу EPCISQueryDocument (Документ_Запроса_EPCIS), как определено схемой подраздела 11.1, где элемент, непосредственно вложенный в элемент EPCISBody (Тело_EPCIS), является элементом QueryResults (Результаты_Запроса), а элемент resultsBody (тело_Результата) внутри элемента QueryResults (Результаты_Запроса) содержит элемент EventList (Список_Событий).

Реализация интерфейса сбора данных ДОЛЖНА принять форму элемента EPCISDocument (Документ_EPCIS) и форму элемента EPCISQueryDocument (Документ_Запроса_EPCIS). Реализация интерфейса сбора данных НЕ ДОЛЖНА принимать документы, которые не имеют силы, как это указано выше. Успешное принятие этого сообщения сервером ДОЛЖНО представлять собой фиксирование всех событий EPCIS, включенных в сообщение.

Кодовые значения состояния, возвращаемые сервером сбора данных, ДОЛЖНЫ соответствовать [&25&, раздел 10]. В частности, сервер сбора данных ДОЛЖЕН возвращать кодовое значение состояния 200, чтобы показать успешное завершение операции сбора данных, а любое кодовое значение состояния: 3xx, 4xx или 5xx — ДОЛЖНО показывать, что операция сбора данных не была успешно завершена. Обстоятельства возврата соответствующих кодовых значений состояния определяются конкретным применением. Однако любое применение ДОЛЖНО принять или отвергнуть все события в сообщении.

11 Привязки для модуля основных операций с запросами

В данном разделе определяются привязки для модуля основных операций с запросами (Core Query Operations Module), как показано &в таблице 38&:

&Таблица 38&

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

• элементы XML для аргумента и возвращаемой сигнатуры каждого метода в интерфейсе управления запросами, как определено в 8.2.5;
• типы XML для каждого типа данных, используемого в этих аргументах, и возвращаемых сигнатур;
• элементы XML для каждого исключения, определенного в 8.2.6;
• элементы XML для интерфейса обратных вызовов по запросам, как определено в 8.2.8 (это, на самом деле, просто подмножество предыдущих трех пунктов);
• элемент EPCISQueryDocument (Документ_Запроса_EPCIS), который используется привязками в качестве «конверта», базовая технология которых не предоставляет собственный конверт или механизм заголовка (а именно всеми привязками, за исключением привязки SOAP). Привязка протокола AS2 использует этот элемент для того, чтобы предоставить заголовок для соответствия запросам и ответам. Элемент EPCISQueryDocument (Документ_Запроса_EPCIS) имеет общий тип EPCISHeader (Заголовок_EPCIS), определенный в подразделе 9.5. Каждая привязка определяет собственные правила использования этого заголовка, если это применимо.

11.1 Схема XML для модуля основных операций с запросами

Следующая схема определяет XML представления типов данных, запросов, ответов и исключений, используемых интерфейсом EPCIS управления запросами и интерфейсом EPCIS обратных вызовов по запросам в модуле основных операций с запросами. Эта схема включена в виде ссылки во все привязки для этих двух интерфейсов, указанных в настоящем разделе 11. Эта схема ДОЛЖНА использоваться любой новой привязкой в рамках модуля основных операций с запросами, которая использует XML как основной формат сообщения.

Тип QueryParam (Параметр_Запроса), определенный в нижеприведенной схеме, используется для представления параметра запроса в методах poll (опрос) и subscribe (подписка) интерфейса запросов, определенных в 8.2.5. Параметр запроса состоит из имени и значения. Для значения схема XML задает xsd:anyType, таким образом может быть представлено значение параметра любого типа. При создании экземпляра документа фактическое значение ДОЛЖНО соответствовать типу, подходящему для параметра запроса, как определено в таблице &39&:

&Таблица 39&

В частности, таблица &39& ДОЛЖНА использоваться для сопоставления типов параметров, указанных в 8.2.7 для предопределенных запросов, и соответствующих типов XML.

Как указано в &[19]&, каждый элемент (<значение>), задающий значение параметра запроса в документе экземпляра, МОЖЕТ включать атрибут xsi:type. Следующие правила определяют, каким образом обрабатываются значения параметра запроса:

• если элемент (<значение>) не включает атрибут xsi:type, то в том случае, если указанное значение имеет недопустимый синтаксис для типа, требуемого параметром запроса, метод subscribe (подписка) или метод poll (опрос) интерфейса управления запросами ДОЛЖЕН ответить с помощью исключения QueryParameterException (Исключение_по_Параметру_Запроса);
• если элемент (<значение>) включает атрибут xsi:type, то применяются следующие правила:

1. если тело элемента (<значение>) имеет недопустимый синтаксис для типа, заданного атрибутом xsi:type, то запрос EPCISQueryDocument (Документ_Запроса_EPCIS) или запрос протокола SOAP МОЖЕТ быть отклонен синтаксическим анализатором XML данной реализации;

2. если значение атрибута xsi:type не является корректным типом для параметра запроса, как указано во второй колонке приведенной выше таблицы, то метод subscribe (подписка) или метод poll (опрос) интерфейса управления запросами МОЖЕТ применить исключение QueryParameterException (Исключение_по_Параметру_Запроса), даже если тело элемента (<значение>) имеет допустимый синтаксис для типа, требуемого параметром запроса;

3. если тело элемента (<значение>) имеет недопустимый синтаксис для типа, требуемого параметром запроса, то метод интерфейса управления запросами subscribe (подписка) или poll (опрос) ДОЛЖЕН применить исключение QueryParameterException (Исключение_по_Параметру_Запроса) в том случае, если запрос EPCISQueryDocument (Документ_Запроса_EPCIS) или запрос протокола SOAP не был отклонен синтаксическим анализатором XML данной реализации в соответствии с вышеприведенным правилом.

Указанная схема импортирует дополнительные схемы, как показано в таблице &40&:

&Таблица 40&

В дополнение к ограничениям, налагаемым схемой, любое значение типа xsd:dateTime в документе экземпляра ДОЛЖНО включать спецификатор часового пояса (либо «Z» для всемирного координированного времени UTC, либо явный временной сдвиг относительно всемирного координированного времени UTC).

Для любого элемента XML типа xsd:anyURI или xsd:string, который задает значение minOccurs=«0», реализация EPCIS ДОЛЖНА обрабатывать экземпляр, имеющий пустую строку в качестве значения, точно так же, как если бы этот элемент вообще отсутствовал.

Схема XML (XSD) для модуля основных операций с запросами приведена ниже: