Standard

EPC Information Services

(EPCIS)

Standard

enables disparate applications to create and share visibility

event data, both within and across enterprises.

Release 1.2, Ratified, Sep 2016

EPC Information Services (EPCIS) Standard

Document Summary 1

Document Item Current Value

Document Name EPC Information Services (EPCIS) Standard

Document Date Sep 2016

Document Version 1.2

Document Issue

Document Status Ratified

Document Description enables disparate applications to create and share visibility event data,

both within and across enterprises.

Contributors 2

Name Company

Andrew Kennedy, Co-chair FoodLogiQ

Ralph Troeger, Co-chair GS1 Germany

Gena Morgan, Facilitator GS1 Global Office

Ken Traub, Editor Ken Traub Consulting LLC

Philip Allgaier bpcompass GmbH

Paul Arguin r-pac international

Karla Biggs-Gregory Oracle

Zsolt Bocsi GS1 Hungary

Jonas Buskenfried GS1 Sweden

Jaewook Byun Auto-ID Labs, KAIST

Karolin Catela GS1 Sweden

Mario Chavez GS1 Guatemala

Luiz Costa GS1 Brasil

Deniss Dobrovolskis GS1 Sweden

Michael Dols MET Laboratories

Hussam El-Leithy GS1 US

Jürgen Engelhardt Robert Bosch GmbH

Heinz Graf GS1 Switzerland

Danny Haak Nedap

Tany Hui GS1 Hong Kong, China

Jianhua Jia GS1 China

Peter Jonsson GS1 Sweden

Art Kaufmann Frequentz LLC

Janice Kite GS1 Global Office

Jens Kungl METRO Group

Roar Lorvik GS1 Norway

Paul Lothian Tyson

Fargeas Ludovic Courbon

EPC Information Services (EPCIS) Standard

Name Company

Noriyuki Mama GS1 Japan

Kevan McKenzie McKesson

Reiko Moritani GS1 Japan

Alice Mukaru GS1 Sweden

Mauricio Munoz Axway

Falk Nieder EECC

Juan Ochoa GS1 Columbia

Ted Osinski MET Laboratories

Ben Östman GS1 Finland

James Perng GS1 Chinese Taipei

Craig Alan Repec GS1 Global Office

Chris Roberts GlaxoSmithKline

Thomas Rumbach SAP AG

Chuck Sailer Frequentz

Michael Sarachman GS1 Global Office

Hans Peter Scheidt GS1 Germany

Michael Smith Merck & Co., Inc.

Michele Southall GS1 US

Peter Spellman TraceLink

Peter Sturtevant GS1 US

Hristo Todorov Axway

Geir Vevle HRAFN AS

Elizabeth Waldorf TraceLink

Ruoyun Yan GS1 China

Tony Zhang FSE, Inc.

Mike Zupec Abbvie

Log of Changes 3

Release Date of Change Changed By Summary of Change

1.0 Initial version

EPC Information Services (EPCIS) Standard

Release Date of Change Changed By Summary of Change

1.1 May 2014 EPCIS 1.1 is fully backward compatible with EPCIS 1.0.1.

EPCIS 1.1 includes these new or enhanced features:

Support for class-level identification is added to

ObjectEvent, AggregationEvent, and

TransformationEvent through the addition of quantity lists.

A new event type, TransformationEvent, provides for the

description of events in which inputs are consumed and

outputs are produced.

The “why” dimension of all event types are enhanced so that

information about the sources and destinations of business

transfers may be included.

The “why” dimension of certain event types are enhanced so

that item/lot master data may be included.

The SimpleEventQuery is enhanced to encompass the above

changes to event types.

The introductory material is revised to align with the GS1

System Architecture.

The XML extension mechanism is explained more fully.

The QuantityEvent is deprecated, as its functionality is fully

subsumed by

ObjectEvent

with the addition of quantity lists.

1.2 Sep 2016 EPCIS 1.2 is fully backward compatible with EPCIS 1.1 and

1.0.1.

EPCIS 1.2 includes these new or enhanced features:

A mechanism is introduced to declare that a prior EPCIS

event is in error, for use when it is impossible to correct the

historical trace by means of ordinary EPCIS events. This

mechanism includes the errorDeclaration structure in an

EPCIS event and associated query parameters.

An optional

eventID is added to all EPCIS events. Its main

intended use is to allow for an error declaration event to

(optionally) refer to one or more corrective events.

The Simple Event Query is enhanced to clarify that queries

for extension or ILMD fields apply only to top-level XML

elements, and a new set of query parameters is introduced

to query for XML elements nested within top-level elements.

The role of an EPCIS document as a means to transmit

events point-to-point is clarified.

The EPCIS Header in the XML schemas is enhanced to allow

for optional inclusion of master data.

The use of extension elements within

<readPoint> and

<bizLocation> is deprecated.

Section 12 regarding conformance is added.

Disclaimer 4

GS1

, under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in 5

the Work Group that developed this EPC Information Services (EPCIS) Standard to agree to grant to GS1 members a 6

royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. Furthermore, 7

attention is drawn to the possibility that an implementation of one or more features of this Specification may be the subject 8

of a patent or other intellectual property right that does not involve a Necessary Claim. Any such patent or other 9

intellectual property right is not subject to the licencing obligations of GS1. Moreover, the agreement to grant licences 10

provided under the GS1 IP Policy does not include IP rights and any claims of third parties who were not participants in the 11

Work Group. 12

Accordingly, GS1 recommends that any organisation developing an implementation designed to be in conformance with this 13

Specification should determine whether there are any patents that may encompass a specific implementation that the 14

organisation is developing in compliance with the Specification and whether a licence under a patent or other intellectual 15

property right is needed. Such a determination of a need for licencing should be made in view of the details of the specific 16

system designed by the organisation in consultation with their own patent counsel. 17

EPC Information Services (EPCIS) Standard

THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF 18

MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY WARRANTY OTHER WISE ARISING 19

OUT OF THIS SPECIFICATION. GS1 disclaims all liability for any damages arising from use or misuse of this Standard, 20

whether special, indirect, consequential, or compensatory damages, and including liability for infringement of any 21

intellectual property rights, relating to use of information in or reliance upon this document. 22

GS1 retains the right to make changes to this document at any time, without notice. GS1 makes no warranty for the use of 23

this document and assumes no responsibility for any errors which may appear in the document, nor does it make a 24

commitment to update the information contained herein. 25

GS1 and the GS1 logo are registered trademarks of GS1 AISBL. 26

EPC Information Services (EPCIS) Standard

Table of Contents 28

1 Introduction ................................................................................................. 9 29

2 Relationship to the GS1 System Architecture ................................................ 9 30

2.1

Overview of GS1 standards ............................................................................................ 10 31

2.2

EPCIS in relation to the “Capture” and “Share” layers ........................................................ 10 32

2.3

EPCIS in Relation to trading partners ............................................................................... 12 33

2.4

EPCIS in relation to other GS1 System Architecture components ......................................... 13 34

3 EPCIS specification principles ..................................................................... 15 35

4 Terminology and typographical conventions ............................................... 16 36

5 EPCIS specification framework ................................................................... 16 37

5.1

Layers ......................................................................................................................... 16 38

5.2

Extensibility .................................................................................................................. 18 39

5.3

Modularity .................................................................................................................... 18 40

6 Abstract data model layer ........................................................................... 18 41

6.1

Event data and master data ........................................................................................... 19 42

6.1.1

Transmission of master data in EPCIS ..................................................................... 21 43

6.2

Vocabulary kinds ........................................................................................................... 22 44

6.3

Extension mechanisms ................................................................................................... 23 45

6.4

Identifier representation ................................................................................................ 24 46

6.5

Hierarchical vocabularies ................................................................................................ 24 47

7 Data definition layer ................................................................................... 25 48

7.1

General rules for specifying data definition layer modules .................................................. 25 49

7.1.1

Content ............................................................................................................... 25 50

7.1.2

Notation .............................................................................................................. 26 51

7.1.3

Semantics ............................................................................................................ 27 52

7.2 Core event types module – overview ............................................................................... 27 53

7.3

Core event types module – building blocks ....................................................................... 31 54

7.3.1

Primitive types ..................................................................................................... 31 55

7.3.2

Action type .......................................................................................................... 31 56

7.3.3

The “What” dimension ........................................................................................... 32 57

7.3.4

The “Where” Dimension – read point and business location ........................................ 35 58

7.3.5 The “Why” dimension ............................................................................................ 38 59

7.3.6

Instance/Lot master data (ILMD) ............................................................................ 41 60

7.4

Core event types module – events .................................................................................. 42 61

7.4.1

EPCISEvent .......................................................................................................... 42 62

7.4.2

ObjectEvent (subclass of EPCISEvent) ..................................................................... 45 63

7.4.3

AggregationEvent (subclass of EPCISEvent) ............................................................. 48 64

7.4.4

QuantityEvent (subclass of EPCISEvent) – DEPRECATED ............................................ 51 65

7.4.5 TransactionEvent (subclass of EPCISEvent) .............................................................. 52 66

7.4.6

TransformationEvent (subclass of EPCISEvent) ......................................................... 55 67

8 Service layer ............................................................................................... 57 68

EPC Information Services (EPCIS) Standard

8.1 Core capture operations module ...................................................................................... 59 69

8.1.1

Authentication and authorisation ............................................................................ 59 70

8.1.2

Capture service .................................................................................................... 59 71

8.2

Core Query operations module ........................................................................................ 60 72

8.2.1 Authentication ...................................................................................................... 61 73

8.2.2

Authorisation ........................................................................................................ 61 74

8.2.3

Queries for large amounts of data ........................................................................... 62 75

8.2.4

Overly complex queries ......................................................................................... 62 76

8.2.5

Query framework (EPCIS query control interface) ..................................................... 62 77

8.2.6

Error conditions .................................................................................................... 68 78

8.2.7

Predefined queries for EPCIS .................................................................................. 70 79

8.2.8 Query callback interface ........................................................................................ 81 80

9 XML bindings for data definition modules ................................................... 82 81

9.1

Extensibility mechanism ................................................................................................. 82 82

9.2

Standard business document header ............................................................................... 84 83

9.3

EPCglobal Base schema ................................................................................................. 85 84

9.4 Master data in the XML binding ....................................................................................... 86 85

9.5

Schema for core event types .......................................................................................... 87 86

9.6

Core event types – examples (Non-Normative) ........................................................... 99 87

9.6.1

Example 1 – Object Events with instance-level identification ...................................... 99 88

9.6.2

Example 2 – Object Event with class-level identification ............................................ 100 89

9.6.3

Example 3 – Aggregation event with mixed identification .......................................... 101 90

9.6.4

Example 4 – Transformation event ......................................................................... 102 91

9.7

Schema for master data document ................................................................................. 103 92

9.8 Master data – example (non-normative) ................................................................... 105 93

10 Bindings for core capture operations module ...................................... 106 94

10.1

Message queue binding ................................................................................................. 106 95

10.2

HTTP binding ............................................................................................................... 107 96

11 Bindings for core query operations module ......................................... 108 97

11.1

XML schema for core query operations module ................................................................ 108 98

11.2

SOAP/HTTP binding for the query control interface ........................................................... 116 99

11.3

AS2 Binding for the query control interface ..................................................................... 124 100

11.3.1

GS1 AS2 guidelines (Non-Normative) ............................................................... 126 101

11.4

Bindings for query callback interface............................................................................... 128 102

11.4.1

General Considerations for all XML-based bindings ................................................... 129 103

11.4.2

HTTP binding of the query callback interface ........................................................... 129 104

11.4.3

HTTPS binding of the query callback interface ......................................................... 129 105

11.4.4 AS2 Binding of the query callback interface ............................................................. 130 106

12 Conformance ....................................................................................... 131 107

12.1

Conformance of EPCIS data ........................................................................................... 131 108

12.2

Conformance of EPCIS capture interface clients ............................................................... 131 109

12.3

Conformance of EPCIS capture interface servers .............................................................. 131 110

12.4 Conformance of EPCIS query interface clients .................................................................. 132 111

12.5

Conformance of EPCIS query interface servers ................................................................. 132 112

EPC Information Services (EPCIS) Standard

12.6 Conformance of EPCIS query callback interface implementations ....................................... 132 113

13 References .......................................................................................... 132 114

14 Contributors to earlier versions ........................................................... 133 115

116

EPC Information Services (EPCIS) Standard

1 Introduction 117

This document is a GS1 standard that defines Version 1.2 of EPC Information Services (EPCIS). The 118

goal of EPCIS is to enable disparate applications to create and share visibility event data, both 119

within and across enterprises. Ultimately, this sharing is aimed at enabling users to gain a shared 120

view of physical or digital objects within a relevant business context. 121

“Objects” in the context of EPCIS typically refers to physical objects that are identified either at a 122

class or instance level and which are handled in physical handling steps of an overall business 123

process involving one or more organisations. Examples of such physical objects include trade items 124

(products), logistic units, returnable assets, fixed assets, physical documents, etc. “Objects” may 125

also refer to digital objects, also identified at either a class or instance level, which participate in 126

comparable business process steps. Examples of such digital objects include digital trade items 127

(music downloads, electronic books, etc.), digital documents (electronic coupons, etc.), and so 128

forth. Throughout this document the word “object” is used to denote a physical or digital object, 129

identified at a class or instance level, that is the subject of a business process step. EPCIS data 130

consist of “visibility events,” each of which is the record of the completion of a specific business 131

process step acting upon one or more objects. 132

The EPCIS standard was originally conceived as part of a broader effort to enhance collaboration 133

between trading partners by sharing of detailed information about physical or digital objects. The 134

name EPCIS reflects the origins of this effort in the development of the Electronic Product Code 135

(EPC). It should be noted, however, that EPCIS does not require the use of Electronic Product 136

Codes, nor of Radio-Frequency Identification (RFID) data carriers, and as of EPCIS 1.2 does not 137

even require instance-level identification (for which the Electronic Product Code was originally 138

designed). The EPCIS standard applies to all situations in which visibility event data is to be 139

captured and shared, and the presence of “EPC” within the name is of historical significance only. 140

EPCIS provides open, standardised interfaces that allow for seamless integration of well-defined 141

services in inter-company environments as well as within companies. Standard interfaces are 142

defined in the EPCIS standard to enable visibility event data to be captured and queried using a 143

defined set of service operations and associated data standards, all combined with appropriate 144

security mechanisms that satisfy the needs of user companies. In many or most cases, this will 145

involve the use of one or more persistent databases of visibility event data, though elements of the 146

Services approach could be used for direct application-to-application sharing without persistent 147

databases. 148

With or without persistent databases, the EPCIS specification specifies only a standard data sharing 149

interface between applications that capture visibility event data and those that need access to it. It 150

does not specify how the service operations or databases themselves should be implemented. This 151

includes not defining how the EPCIS services should acquire and/or compute the data they need, 152

except to the extent the data is captured using the standard EPCIS capture operations. The 153

interfaces are needed for interoperability, while the implementations allow for competition among 154

those providing the technology and implementing the standard. 155

EPCIS is intended to be used in conjunction with the GS1 Core Business Vocabulary (CBV) standard 156

[CBV1.2]. The CBV standard provides definitions of data values that may be used to populate the 157

data structures defined in the EPCIS standard. The use of the standardised vocabulary provided by 158

the CBV standard is critical to interoperability and critical to provide for querying of data by reducing 159

the variation in how different businesses express common intent. Therefore, applications should use 160

the CBV standard to the greatest extent possible in constructing EPCIS data. 161

The companion EPCIS and CBV Implementation Guideline [EPCISGuideline] provides additional 162

guidance for building visibility systems using EPCIS and CBV, including detailed discussion of how to 163

model specific business situations using EPCIS/CBV data and methods for sharing such data 164

between trading partners. 165

2 Relationship to the GS1 System Architecture 166

This section is largely quoted from [EPCAF] and [GS1Arch], and shows the relationship of EPCIS to 167

other GS1 standards. 168

EPC Information Services (EPCIS) Standard

2.1 Overview of GS1 standards 169

GS1 standards support the information needs of end users interacting with each other in supply 170

chains, specifically the information required to support the business processes through which supply 171

chain participants interact. The subjects of such information are the real-world entities that are part 172

of those business processes. Real-world entities include things traded between companies, such as 173

products, parts, raw materials, packaging, and so on. Other real-world entities of relevance to 174

trading partners include the equipment and material needed to carry out the business processes 175

surrounding trade such as containers, transport, machinery; entities corresponding to physical 176

locations in which the business processes are carried out; legal entities such as companies, 177

divisions; service relationships; business transactions and documents; and others. Real-world 178

entities may exist in the tangible world, or may be digital or conceptual. Examples of physical 179

objects include a consumer electronics product, a transport container, and a manufacturing site 180

(location entity). Examples of digital objects include an electronic music download, an eBook, and an 181

electronic coupon. Examples of conceptual entities include a trade item class, a product category, 182

and a legal entity. 183

GS1 standards may be divided into the following groups according to their role in supporting 184

information needs related to real-world entities in supply chain business processes: 185

■ Standards which provide the means to identify real-world entities so that they may be the 186

subject of electronic information that is stored and/or communicated by end users. GS1 187

identification standards include standards that define unique identification codes (called GS1 188

identification keys). 189

■ Standards which provide the means to automatically capture data that is carried directly on 190

physical objects, bridging the world of physical things and the world of electronic information. 191

GS1 data capture standards include definitions of barcode and radio-frequency identification 192

(RFID) data carriers which allow identifiers to be affixed directly to a physical object, and 193

standards that specify consistent interfaces to readers, printers, and other hardware and 194

software components that connect the data carriers to business applications. 195

■ Standards which provide the means to Share information, both between trading partners and 196

internally, providing the foundation for electronic business transactions, electronic visibility of 197

the physical or digital world, and other information applications. GS1 standards for information 198

sharing include this EPCIS Standard which is a standard for visibility event data. Other 199

standards in the “Share” group are standards for master data and for business transaction data, 200

as well as discovery standards that help locate where relevant data resides across a supply 201

chain and trust standards that help establish the conditions for sharing data with adequate 202

security. 203

The EPCIS Standard fits into the “Share” group, providing the data standard for visibility event data 204

and the interface standards for capturing such information from data capture infrastructure (which 205

employs standards from the “Capture” group) and for sharing such information with business 206

applications and with trading partners. 207

2.2 EPCIS in relation to the “Capture” and “Share” layers 208

The following diagram shows the relationship between EPCIS and other GS1 standards in the 209

“Capture” and “Share” groups. (The “Identify” group of standards pervades the data at all levels of 210

this architecture, and so is not explicitly shown.) 211

EPC Information Services (EPCIS) Standard

212

As depicted in the diagram above, the EPCIS Capture Interface exists as a bridge between the 213

“Capture” and “Share” standards. The EPCIS Query Interface provides visibility event data both to 214

internal applications and for sharing with trading partners. 215

At the centre of a data capture application is the data capture workflow that supervises the business 216

process step within which data capture takes place. This is typically custom logic that is specific to 217

the application. Beneath the data capture workflow in the diagram is the data path between the 218

workflow and GS1 data carriers: barcodes and RFID. The green bars in the diagram denote GS1 219

standards that may be used as interfaces to the data carriers. At the top of the diagram are the 220

interfaces between the data capture workflow and larger-scale enterprise applications. Many of 221

these interfaces are application- or enterprise-specific, though using GS1 data as building blocks; 222

however, the EPCIS interface is a GS1 standard. Note that the interfaces at the top of the diagram, 223

including EPCIS, are independent of the data carrier used at the bottom of the diagram. 224

Filtering &

Collection Engine

EPCIS Accessing

Applications and other

Enterprise-level

Applications

LLRP Interface

ALE Interface

EPCIS Capture

Interface

Data Capture Workflow

Composite

Element

String

Data

Capture

Application

Various app-specific Interfaces

Human

Interfaces

RFID Reader

RFID Air Interface

RFID Tag

Barcode Symbology

Barcode

= System Component

= Interface

EPCIS Query Interface

eCOM (GS1 XML / EANCOM) Interface

GDSN Interface

To/from

external

parties

Capture

EPCIS

Repository

Possible

bypass for

real-

time

“push”

EPC Information Services (EPCIS) Standard

The purpose of the interfaces and the reason for a multi-layer data capture architecture is to provide 225

isolation between different levels of abstraction. Viewed from the perspective of an enterprise 226

application (i.e., from the uppermost blue box in the figure), the entire data capture application 227

shields the enterprise application from the details of exactly how data capture takes place. Through 228

the application-level interfaces (uppermost green bars), an enterprise application interacts with the 229

data capture workflow through data that is data carrier independent and in which all of the 230

interaction between data capture components has been consolidated into that data. At a lower level, 231

the data capture workflow is cognizant of whether it is interacting with barcode scanners, RFID 232

interrogators, human input, etc., but the transfer interfaces (green bars in the middle) shield the 233

data capture workflow from low-level hardware details of exactly how the data carriers work. The 234

lowest level interfaces (green bars on the bottom) embody those internal data carrier details. EPCIS 235

and the “Share” layer in general differ from elements in the Capture layer in three key respects: 236

1. EPCIS deals explicitly with historical data (in addition to current data). The Capture layer, in 237

contrast, is oriented exclusively towards real-time processing of captured data. 238

2. EPCIS often deals not just with raw data captured from data carriers such as barcodes and RFID 239

tags, but also in contexts that imbue those observations with meaning relative to the physical or 240

digital world and to specific steps in operational or analytical business processes. The Capture 241

layers are more purely observational in nature. An EPCIS event, while containing much of the 242

same “Identify” data as a Filtering & Collection event or a barcode scan, is at a semantically 243

higher level because it incorporates an understanding of the business context in which the 244

identifier data were obtained. Moreover, there is no requirement that an EPCIS event be directly 245

related to a specific physical data carrier observation. For example, an EPCIS event may indicate 246

that a perishable trade item has just crossed its expiration date; such an event may be 247

generated purely by software. 248

3. EPCIS operates within enterprise IT environments at a level that is much more diverse and 249

multi-purpose than exists at the Capture layer, where typically systems are self-contained and 250

exist to serve a single business purpose. In part, and most importantly, this is due to the desire 251

to share EPCIS data between enterprises which are likely to have different solutions deployed to 252

perform similar tasks. In part, it is also due to the persistent nature of EPCIS data. And lastly, it 253

is due to EPCIS being at the highest level of the overall architecture, and hence the natural point 254

of entry into other enterprise systems, which vary widely from one enterprise to the next (or 255

even within parts of the same enterprise). 256

2.3 EPCIS in Relation to trading partners 257

GS1 standards in the “Share” layer pertain to three categories of data that are shared between end 258

users: 259

Data Description GS1 standards

Master data Data, shared by one trading partner to many trading partners, that provide

descriptive attributes of real-world entities identified by GS1 identification keys,

including trade items, parties, and physical locations.

GDSN

Transaction

data

Trade transactions triggering or confirming the execution of a function within a

business process as defined by an explicit business agreement (e.g., a supply

contract) or an implicit one (e.g., customs processing), from the start of the

business process (e.g., ordering the product) to the end of it (e.g., final

settlement), also making use of GS1 identification keys.

GS1 XML

EANCOM

Visibility event

data

Details about physical or digital activity in the supply chain of products and

other assets, identified by keys, detailing where these objects are in time, and

why; not just within one organisation’s four walls, but across organisations.

EPCIS

260

Transaction Data and Visibility Event Data have the characteristic that new documents of those 261

types are continually created as more business is transacted in a supply chain in steady state, even 262

if no new real-world entities are being created. Master data, in contrast, is more static: the master 263

data for a given entity changes very slowly (if at all), and the quantity of master data only increases 264

as new entities are created, not merely because existing entities participate in business processes. 265

For example, as a given trade item instance moves through the supply chain, new transaction data 266

and visibility event data are generated as that instance undergoes business transactions (such as 267

EPC Information Services (EPCIS) Standard

purchase and sale) and physical handling processes (packing, picking, stocking, etc.). But new 268

master data is only created when a new trade item or location is added to the supply chain. 269

The following figure illustrates the flow of data between trading partners, emphasising the parts of 270

the EPCIS standard involved in the flow of visibility event data. 271

272

In addition to the use of the EPCIS Query Interface as illustrated above, trading partners may by 273

mutual agreement use the EPCIS Document structure defined in Section 9.3 as a means to transport 274

a collection of EPCIS events, optionally accompanied by relevant master data, as a single electronic 275

document. 276

2.4 EPCIS in relation to other GS1 System Architecture components 277

The following outlines the responsibilities of each element of the GS1 System Architecture as 278

illustrated in the figures in the preceding sections. Further information may be found in [GS1Arch], 279

from which the above diagram and much of the above text is quoted, and [EPCAF], from which 280

much of the following text is quoted. 281

EPCIS Accessing

Applications and

other Enterprise-

level

Applications

EPCIS Capture

Interface

Data Capture Infrastructure

App-specific

Interfaces

eCOM (GS1 XML / EANCOM) Interface

GDSN Interface

and data pools

EPCIS

Repository

EPCIS Query

Interface (Control

and Callback)

EPCIS Accessing

Applications and

other Enterprise-

level

Applications

App-specific

Interfaces

EPCIS Capture

Interface

EPCIS

Repository

Data Capture Infrastructure

EPCIS Query traffic – on-demand queries and

standing queries

EPCIS Query

Interface (Control

and Callback)

Trading Partner 1

Trading Partner 2

GS1 Networked Services

Services for

Discovery (ONS, etc)

GDSN Global

Registry

EPC Information Services (EPCIS) Standard

■ RFID and Barcode Readers Make observations of RFID tags while they are in the read zone, and 282

observations of barcodes when reading is triggered. 283

■ Low-Level [RFID] Reader Protocol (LLRP) Interface Defines the control and delivery of raw RFID 284

tag reads from RFID Readers to the Filtering & Collection role. Events at this interface say 285

“Reader A saw EPC X at time T.” 286

■ Filtering & Collection This role filters and collects raw RFID tag reads, over time intervals 287

delimited by events defined by the EPCIS Capturing Application (e.g. tripping a motion 288

detector). No comparable role typically exists for reading barcodes, because barcode readers 289

typically only read a single barcode when triggered. 290

■ Filtering & Collection (ALE) Interface Defines the control and delivery of filtered and collected 291

RFID tag read data from the Filtering & Collection role to the Data Capture Workflow role. 292

Events at this interface say “At Logical Reader L, between time T1 and T2, the following EPCs 293

were observed,” where the list of EPCs has no duplicates and has been filtered by criteria 294

defined by the EPCIS Capturing Application. In the case of barcodes, comparable data is 295

delivered to the Data Capture Workflow role directly from the barcode reader in the form of a 296

GS1 Element String. 297

■ Data Capture Workflow Supervises the operation of the lower-level architectural elements, and 298

provides business context by coordinating with other sources of information involved in 299

executing a particular step of a business process. The Data Capture Workflow may, for example, 300

coordinate a conveyor system with Filtering & Collection events and barcode reads, may check 301

for exceptional conditions and take corrective action (e.g., diverting a bad object into a rework 302

area), may present information to a human operator, and so on. The Data Capture Workflow 303

understands the business process step or steps during which EPCIS event data capture takes 304

place. This role may be complex, involving the association of multiple Filtering & Collection 305

events and/or barcode reads with one or more business events, as in the loading of a shipment. 306

Or it may be straightforward, as in an inventory business process where there may be readers 307

deployed that generate observations about objects that enter or leave the shelf. Here, the 308

Filtering & Collection-level event or barcode read and the EPCIS-level event may be so similar 309

that very little actual processing at the Data Capture Workflow level is necessary, and the Data 310

Capture Workflow merely configures and routes events from the Filtering & Collection interface 311

and/or barcode readers directly through the EPCIS Capture Interface to an EPCIS-enabled 312

Repository or a business application. A Data Capture Workflow whose primary output consists of 313

EPCIS events is called an “EPCIS Capturing Application” within this standard. 314

■ EPCIS Interfaces The interfaces through which EPCIS data is delivered to enterprise-level roles, 315

including EPCIS Repositories, EPCIS Accessing Applications, and data exchange with partners. 316

Events at these interfaces say, for example, “At location X, at time T, the following contained 317

objects (cases) were verified as being aggregated to the following containing object (pallet).” 318

There are actually three EPCIS Interfaces. The EPCIS Capture Interface defines the delivery of 319

EPCIS events from EPCIS Capturing Applications to other roles that consume the data in real 320

time, including EPCIS Repositories, and real-time “push” to EPCIS Accessing Applications and 321

trading partners. The EPCIS Query Control Interface defines a means for EPCIS Accessing 322

Applications and trading partners to obtain EPCIS data subsequent to capture, typically by 323

interacting with an EPCIS Repository. The EPCIS Query Control Interface provides two modes of 324

interaction. In “on-demand” or “synchronous” mode, a client makes a request through the 325

EPCIS Query Control Interface and receives a response immediately. In “standing request” or 326

“asynchronous” mode, a client establishes a subscription for a periodic query. Each time the 327

periodic query is executed, the results are delivered asynchronously (or “pushed”) to a recipient 328

via the EPCIS Query Callback Interface. The EPCIS Query Callback Interface may also be used 329

to deliver information immediately upon capture; this corresponds to the “possible bypass for 330

real-time push” arrow in the diagram. All three of these EPCIS interfaces are specified 331

normatively in this document. 332

■ EPCIS Accessing Application: Responsible for carrying out overall enterprise business processes, 333

such as warehouse management, shipping and receiving, historical throughput analysis, and so 334

forth, aided by EPC-related data. 335

■ EPCIS-enabled Repository: Records EPCIS-level events generated by one or more EPCIS 336

Capturing Applications, and makes them available for later query by EPCIS Accessing 337

Applications. 338

EPC Information Services (EPCIS) Standard

■ Partner Application: Trading Partner systems that perform the same role as an EPCIS Accessing 339

Application, though from outside the responding party’s network. Partner Applications may be 340

granted access to a subset of the information that is available from an EPCIS Capturing 341

Application or within an EPCIS Repository. 342

The interfaces within this stack are designed to insulate the higher levels of the architecture from 343

unnecessary details of how the lower levels are implemented. One way to understand this is to 344

consider what happens if certain changes are made: 345

■ The Low-Level [RFID] Reader Protocol (LLRP) and GS1 Element String insulate the higher layers 346

from knowing what RF protocols or barcode symbologies are in use, and what reader 347

makes/models have been chosen. If a different reader is substituted, the information sent 348

through these interfaces remains the same. 349

■ In situations where RFID is used, the Filtering & Collection Interface insulates the higher layers 350

from the physical design choices made regarding how RFID tags are sensed and accumulated, 351

and how the time boundaries of events are triggered. If a single four-antenna RFID reader is 352

replaced by a constellation of five single-antenna “smart antenna” readers, the events at the 353

Filtering & Collection level remain the same. Likewise, if a different triggering mechanism is 354

used to mark the start and end of the time interval over which reads are accumulated, the 355

Filtering & Collection event remains the same. 356

■ EPCIS insulates enterprise applications from understanding the details of how individual steps in 357

a business process are carried out at a detailed level. For example, a typical EPCIS event is “At 358

location X, at time T, the following cases were verified as being on the following pallet.” In a 359

conveyor-based business implementation, this may correspond to a single Filtering & Collection 360

event, in which reads are accumulated during a time interval whose start and end is triggered 361

by the case crossing electric eyes surrounding a reader mounted on the conveyor. But another 362

implementation could involve three strong people who move around the cases and use hand-363

held readers to read the tags. At the Filtering & Collection level, this looks very different (each 364

triggering of the hand-held reader is likely a distinct Filtering & Collection event), and the 365

processing done by the EPCIS Capturing Application is quite different (perhaps involving an 366

interactive console that the people use to verify their work). But the EPCIS event is still the 367

same for all these implementations. 368

In summary, EPCIS-level data differs from data employed at the Capture level in the GS1 System 369

Architecture by incorporating semantic information about the business process in which data is 370

collected, and providing historical observations. In doing so, EPCIS insulates applications that 371

consume this information from knowing the low-level details of exactly how a given business 372

process step is carried out. 373

3 EPCIS specification principles 374

The considerations in the previous two sections reveal that the requirements for standards at the 375

EPCIS layer are considerably more complex than in the Capture layer of the GS1 System 376

Architecture. The historical nature of EPCIS data implies that EPCIS interfaces need a richer set of 377

access techniques than ALE or RFID and barcode reader interfaces. The incorporation of operational 378

or business process context into EPCIS implies that EPCIS traffics in a richer set of data types, and 379

moreover needs to be much more open to extension in order to accommodate the wide variety of 380

business processes in the world. Finally, the diverse environment in which EPCIS operates implies 381

that the EPCIS Standard be layered carefully so that even when EPCIS is used between external 382

systems that differ widely in their details of operation, there is consistency and interoperability at 383

the level of what the abstract structure of the data is and what the data means. 384

In response to these requirements, EPCIS is described by a framework specification and narrower, 385

more detailed specifications that populate that framework. The framework is designed to be: 386

■ Layered: In particular, the structure and meaning of data in an abstract sense is specified 387

separately from the concrete details of data access services and bindings to particular interface 388

protocols. This allows for variation in the concrete details over time and across enterprises while 389

preserving a common meaning of the data itself. It also permits EPCIS data specifications to be 390

reused in approaches other than the service-oriented approach of the present specification. For 391

example, data definitions could be reused in an EDI framework. 392

EPC Information Services (EPCIS) Standard

■ Extensible: The core specifications provide a core set of data types and operations, but also 393

provide several means whereby the core set may be extended for purposes specific to a given 394

industry or application area. Extensions not only provide for proprietary requirements to be 395

addressed in a way that leverages as much of the standard framework as possible, but also 396

provides a natural path for the standards to evolve and grow over time. 397

■ Modular: The layering and extensibility mechanisms allow different parts of the complete EPCIS 398

framework to be specified by different documents, while promoting coherence across the entire 399

framework. This allows the process of standardisation (as well as of implementation) to scale. 400

The remainder of this document specifies the EPCIS framework. It also populates that framework 401

with a core set of data types and data interfaces. The companion standard, the GS1 Core Business 402

Vocabulary (CBV), provides additional data definitions that layer on top of what is provided by the 403

EPCIS standard. 404

4 Terminology and typographical conventions 405

Within this specification, the terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, NEED NOT, 406

CAN, and CANNOT are to be interpreted as specified in Annex G of the ISO/IEC Directives, Part 2, 407

2001, 4th edition [ISODir2]. When used in this way, these terms will always be shown in ALL CAPS; 408

when these words appear in ordinary typeface they are intended to have their ordinary English 409

meaning. 410

All sections of this document, with the exception of Sections 2, 33, and 4

are normative, except 411

where explicitly noted as non-normative. 412

The following typographical conventions are used throughout the document: 413

■ ALL CAPS type is used for the special terms from [ISODir2] enumerated above. 414

■

Monospace type is used to denote programming language, UML, and XML identifiers, as well as 415

for the text of XML documents. 416



Placeholders for changes that need to be made to this document prior to its reaching the final 417

stage of approved GS1 standard are prefixed by a rightward-facing arrowhead, as this 418

paragraph is. 419

5 EPCIS specification framework 420

The EPCIS specification is designed to be layered, extensible, and modular. 421

5.1 Layers 422

The EPCIS specification framework is organised into several layers, as illustrated below: 423

EPC Information Services (EPCIS) Standard

424

These layers are described below. 425

■ Abstract Data Model Layer: The Abstract Data Model Layer specifies the generic structure of 426

EPCIS data. This is the only layer that is not extensible by mechanisms other than a revision to 427

the EPCIS specification itself. The Abstract Data Model Layer specifies the general requirements 428

for creating data definitions within the Data Definition Layer. 429

■ Data Definition Layer: The Data Definition Layer specifies what data is exchanged through 430

EPCIS, what its abstract structure is, and what it means. One data definition module is defined 431

within the present specification, called the Core Event Types Module. Data definitions in the 432

Data Definition Layer are specified abstractly, following rules defined by the Abstract Data Model 433

Layer. 434

■ Service Layer: The Service Layer defines service interfaces through which EPCIS clients interact. 435

In the present specification, two service layer modules are defined. The Core Capture 436

Operations Module defines a service interface (the EPCIS Capture Interface) through which 437

EPCIS Capturing Applications use to deliver Core Event Types to interested parties. The Core 438

Query Operations Module defines two service interfaces (the EPCIS Query Control Interface and 439

Data

Definition

Layer

Core Event

Types

(sect.

7.2)

Core

Capture

Operations

(sect. 8.1)

Capture

Interface

Core

Query

Operations

(sect. 8.2)

Query

Control

Interface

Query

Callback

Interface

Service

Layer

Bindings

Core Event

XSD

(sect.

Capture

Interface

Msg Q

(sect.

10.1)

Query

Control

Interface

SOAP

(sect.

11.2

)

depends on

implements

implement

Abstract

Data

Model

Layer

EPCIS

Abstract

Data Model

(sect. 6)

depends on

Capture

Interface

HTTP

(sect.

10.2)

Query

Control

Interface

AS2

(sect.

11.3

)

Core Query

XSD

(sect.

11.1)

Query

Callback

Interface

HTTP

(sect.

11.4.2)

Query

Callback

Interface

HTTPS

(sect.

11.4.3)

Query

Callback

Interface

AS2

(sect.

11.4.4)

GS1 Core

Business

Vocabulary

Standard

populates

EPC Information Services (EPCIS) Standard

the EPCIS Query Callback Interface) that EPCIS Accessing Applications use to obtain data 440

previously captured. Interface definitions in the Service Layer are specified abstractly using 441

UML. 442

■ Bindings: Bindings specify concrete realisations of the Data Definition Layer and the Service 443

Layer. There may be many bindings defined for any given Data Definition or Service module. In 444

this specification, a total of nine bindings are specified for the three modules defined in the Data 445

Definition and Service Layers. The data definitions in the Core Event Types data definition 446

module are given a binding to an XML schema. The EPCIS Capture Interface in the Core Capture 447

Operations Module is given bindings for Message Queue and HTTP. The EPCIS Query Control 448

Interface in the Core Query Operations Module is given a binding to SOAP over HTTP via a WSDL 449

web services description, and a second binding for AS2. The EPCIS Query Callback Interface in 450

the Core Query Operations Module is given bindings to HTTP, HTTPS, and AS2. 451

■ GS1 Core Business Vocabulary Standard: The GS1 Core Business Vocabulary standard [CBV1.2] 452

is a companion to the EPCIS standard. It defines specific vocabulary elements that may be used 453

to populate the data definitions specified in the Data Definition Layer of the EPCIS standard. 454

While EPCIS may be used without CBV, by employing only private or proprietary data values, it 455

is far more beneficial for EPCIS applications to make as much use of the CBV Standard as 456

possible. 457

5.2 Extensibility 458

The layered technique for specification promotes extensibility, as one layer may be reused by more 459

than one implementation in another layer. For example, while this specification includes an XML 460

binding of the Core Event Types data definition module, another specification may define a binding 461

of the same module to a different syntax, for example a CSV file. 462

Besides the extensibility inherent in layering, the EPCIS specification includes several specific 463

mechanisms for extensibility: 464

■ Subclassing: Data definitions in the Data Definition Layer are defined using UML, which allows a 465

new data definition to be introduced by creating a subclass of an existing one. A subclass is a 466

new type that includes all of the fields of an existing type, extending it with new fields. An 467

instance of a subclass may be used in any context in which an instance of the parent class is 468

expected. 469

■ Extension Points: Data definitions and service specifications also include extension points, which 470

vendors may use to provide extended functionality without creating subclasses. 471

5.3 Modularity 472

The EPCIS specification framework is designed to be modular. That is, it does not consist of a single 473

specification, but rather a collection of individual specifications that are interrelated. This allows 474

EPCIS to grow and evolve in a distributed fashion. The layered structure and the extension 475

mechanisms provide the essential ingredients to achieving modularity, as does the grouping into 476

modules. 477

While EPCIS specifications are modular, there is no requirement that the module boundaries of the 478

specifications be visible or explicit within implementations of EPCIS. For example, there may be a 479

particular software product that provides a SOAP/HTTP-based implementation of a case-to-pallet 480

association service and a product catalogue service that traffics in data defined in the relevant data 481

definition modules. This product may conform to as many as six different modules from the EPCIS 482

standard: the data definition module that describes product catalogue data, the data definition 483

module that defines case-to-pallet associations, the specifications for the respective services, and 484

the respective SOAP/HTTP bindings. But the source code of the product may have no trace of these 485

boundaries, and indeed the concrete database schema used by the product may denormalise the 486

data so that product catalogue and case-to-pallet association data are inextricably entwined. But as 487

long as the net result conforms to the specifications, this implementation is permitted. 488

6 Abstract data model layer 489

This section gives a normative description of the abstract data model that underlies EPCIS. 490

EPC Information Services (EPCIS) Standard

6.1 Event data and master data 491

Generically, EPCIS deals in two kinds of data: event data and master data. Event data arises in the 492

course of carrying out business processes, and is captured through the EPCIS Capture Interface and 493

made available for query through the EPCIS Query Interfaces. Master data is additional data that 494

provides the necessary context for interpreting the event data. It is available for query through the 495

EPCIS Query Control Interface, but the means by which master data enters the system is not 496

specified in the EPCIS standard. 497

The Abstract Data Model Layer does not attempt to define the meaning of the terms “event data” or 498

“master data,” other than to provide precise definitions of the structure of the data as used by the 499

EPCIS specification. The modelling of real-world business information as event data and master data 500

is the responsibility of the Data Definition Layer, and of industry and end-user agreements that build 501

on top of this specification. 502

Non-Normative: Explanation: While for the purposes of this specification the terms “event 503

data” and “master data” mean nothing more than “data that fits the structure provided here,” 504

the structures defined in the Abstract Data Model Layer are designed to provide an 505

appropriate representation for data commonly requiring exchange through EPCIS. Informally, 506

these two types of data may be understood as follows. Event data grows in quantity as more 507

business is transacted, and refers to things that happen at specific moments in time. An 508

example of event data is “At 1:23pm on 15 March 2004, EPC X was observed at Location L.” 509

Master data does not generally grow merely because more business is transacted (though 510

master data does tend to grow as organisations grow in size), is not typically tied to specific 511

moments in time (though master data may change slowly over time), and provides 512

interpretation for elements of event data. An example of master data is “Location L refers to 513

the distribution centre located at 123 Elm Street, Anytown, US.” All of the data in the set of 514

use cases considered in the creation of the EPCIS standard can be modelled as a combination 515

of event data and master data of this kind. 516

The structure of event data and master data in EPCIS is illustrated below. (Note that this is an 517

illustration only: the specific vocabulary elements and master data attribute names in this figure are 518

not defined within this specification.) 519

EPC Information Services (EPCIS) Standard

520

The ingredients of the EPCIS Abstract Data Model are defined below: 521

■ Event Data: A set of Events. 522

■ Event: A structure consisting of an Event Type and one or more named Event Fields. 523

■ Event Type: A namespace-qualified name (qname) that indicates to which of several possible 524

Event structures (as defined by the Data Definition Layer) a given event conforms. 525

■ Event Field: A named field within an Event. The name of the field is given by a qname, referring 526

either to a field name specified by the Data Definition Layer or a field name defined as an 527

extension to this specification. The value of the field may be a primitive type (such as an integer 528

or timestamp), a Vocabulary Element, or a list of primitive types or Vocabulary Elements. 529

■ Master data: A set of Vocabularies, together with master data attributes associated with 530

elements of those Vocabularies. 531

■ Vocabulary: A named set of identifiers. The name of a Vocabulary is a qname that may be used 532

as a type name for an event field. The identifiers within a Vocabulary are called Vocabulary 533

Elements. A Vocabulary represents a set of alternative values that may appear as the values of 534

specific Event Fields. Vocabularies in EPCIS are used to model sets such as the set of available 535

location names, the set of available business process step names, and so on. 536

■ Vocabulary Element: An identifier that names one of the alternatives modelled by a Vocabulary. 537

The value of an Event Field may be a Vocabulary Element. Vocabulary Elements are represented 538

as Uniform Resource Identifiers (URIs). Each Vocabulary Element may have associated master 539

data attributes. 540

■ Master data attributes: An unordered set of name/value pairs associated with an individual 541

Vocabulary Element. The name part of a pair is a qname. The value part of a pair may be a 542

value of arbitrary type. A special attribute is a (possibly empty) list of children, each child being 543

another vocabulary element from the same vocabulary. See Section 6.5

. 544

BizStep Vocabulary

urn:…:receiving

urn:…:shipping

…

BizLocation Vocabulary

urn:epc:id:sgln:0614141.12345.0

urn:epc:id:sgln:0614141.33254.0

urn:epc:id:sgln:0614141.33254.1

…

Event Data

Master Data

sampleAttrName = sampleValue

…

ObjectEvent

Time = 1:23pm 15 Mar 2004

EPC = urn:epc:id:sgtin:0614141.100734.400

bizStep = urn:epcglobal:cbv:bizstep:shipping

bizLocation = urn:epc:id:sgln:0614141.12345.0

address = 123 Elm St

city = Anytown

postalCode = 12345

Children urn:epc:id:sgln: …

Master Data Vocabularies

Master Data Attributes

Event

Event Type

EPC Information Services (EPCIS) Standard

New EPCIS Events are generated at the edge and delivered into EPCIS infrastructure through the 545

EPCIS Capture Interface, where they can subsequently be delivered to interested applications 546

through the EPCIS Query Interfaces. There is no mechanism provided in either interface by which an 547

application can delete or modify an EPCIS Event. The only way to “retract” or “correct” an EPCIS 548

Event is to generate a subsequent event whose business meaning is to rescind or amend the effect 549

of a prior event (Section 7.4.1.3

discusses how this may be done). 550

While the EPCIS Capture Interface and EPCIS Query Interfaces provide no means for an application 551

to explicitly request the deletion of an event, EPCIS Repositories MAY implement data retention 552

policies that cause old EPCIS events to become inaccessible after some period of time. 553

Master data, in contrast, may change over time, though such changes are expected to be infrequent 554

relative to the rate at which new event data is generated. The current version of this specification 555

does not specify how master data changes (nor, as noted above, does it specify how master data is 556

entered in the first place). 557

6.1.1 Transmission of master data in EPCIS 558

The EPCIS Capture and Query Interfaces are primarily concerned with the transmission of EPCIS 559

Events. The means by which master data enters a system that implements these interfaces is not 560

specified in the EPCIS standard. However, the EPCIS standard does provide mechanisms for 561

transmission of master data, which an implementation may use to ensure that the recipient of 562

EPCIS event data has access to the master data necessary to interpret that event data. 563

Alternatively, master data may be transmitted by means entirely outside the EPCIS standard. The 564

EPCIS standard does not impose any requirements on whether EPCIS event data is accompanied by 565

master data or not, other than to require that master data accompanying event data be consistent 566

with any master data in ILMD sections of those events. 567

The EPCIS standard provides four mechanisms for transmission of master data, summarised in the 568

table below: 569

Mechanism Section Description Constraint

Master data

query

8.2.7.2 An EPCIS query client may query an

implementation of the EPCIS Query

Interface for master data matching

specified criteria.

The master data returned from the query SHALL

reflect the current values of master data

attributes, as known to the query responder, as

of the time the query response is created.

ILMD 7.3.6 An EPCIS event that marks the

beginning of life for an instance-level

or lot-level identifier may include

corresponding master data directly in

the event.

The master data in the event SHALL reflect the

current values of master data attributes, as

known to the event creator, as of the event

time. Note that because this data is embedded

directly in the event, it is permanently a part of

that event and will always be included when this

event is queried for (subject to redaction as

specified in Section 8.2.2

Header of

EPCIS

document

9.5 An EPCIS document used for point-to-

point transmission of a collection of

EPCIS events outside of the EPCIS

Query Interface may include relevant

master data in the document header.

The master data in the document header SHALL

reflect the current values of master data

attributes, as known to the document creator,

as of the time the document is created. Master

data in the header of an EPCIS document SHALL

NOT specify attribute values that conflict with

the ILMD section of any event contained within

the EPCIS document body.

EPCIS master

data document

9.7 An EPCIS master data document may

be used for point-to-point

transmission of master data outside of

the EPCIS Query Interface.

The master data in the document SHALL reflect

the current values of master data attributes, as

known to the document creator, as of the time

the document is created.

570

571

EPC Information Services (EPCIS) Standard

6.2 Vocabulary kinds 572

Vocabularies are used extensively within EPCIS to model physical, digital, and conceptual entities 573

that exist in the real world. Examples of vocabularies defined in the core EPCIS Data Definition 574

Layer are location names, object class names (an object class name is something like “Acme Deluxe 575

Widget,” as opposed to an EPC which names a specific instance of an Acme Deluxe Widget), and 576

business step names. In each case, a vocabulary represents a finite (though open-ended) set of 577

alternatives that may appear in specific fields of events. 578

It is useful to distinguish two kinds of vocabularies, which follow different patterns in the way they 579

are defined and extended over time: 580

■ Standard Vocabulary: A Standard Vocabulary represents a set of Vocabulary Elements whose 581

definition and meaning must be agreed to in advance by trading partners who will exchange 582

events using the vocabulary. For example, the EPCIS Core Data Definition Layer defines a 583

vocabulary called “business step,” whose elements are identifiers denoting such things as 584

“shipping,” “receiving,” and so on. One trading partner may generate an event having a 585

business step of “shipping,” and another partner receiving that event through a query can 586

interpret it because of a prior agreement as to what “shipping” means. 587

Standard Vocabulary elements tend to be defined by organisations of multiple end users, such 588

as GS1, industry consortia outside GS1, private trading partner groups, and so on. The master 589

data associated with Standard Vocabulary elements are defined by those same organisations, 590

and tend to be distributed to users as part of a specification or by some similar means. New 591

vocabulary elements within a given Standard Vocabulary tend to be introduced through a very 592

deliberate and occasional process, such as the ratification of a new version of a standard or 593

through a vote of an industry group. While an individual end user organisation acting alone may 594

introduce a new Standard Vocabulary element, such an element would have limited use in a 595

data exchange setting, and would probably only be used within an organisation’s four walls. 596

■ User Vocabulary: A User Vocabulary represents a set of Vocabulary Elements whose definition 597

and meaning are under the control of a single organisation. For example, the EPCIS Core Data 598

Definition Layer defines a vocabulary called “business location,” whose elements are identifiers 599

denoting such things as “Acme Corp. Distribution Centre #3.” Acme Corp may generate an 600

event having a business location of “Acme Corp. Distribution Centre #3,” and another partner 601

receiving that event through a query can interpret it either because it correlates it with other 602

events naming the same location, or by looking at master data attributes associated with the 603

location, or both. 604

User Vocabulary elements are primarily defined by individual end user organisations acting 605

independently. The master data associated with User Vocabulary elements are defined by those 606

same organisations, and are usually distributed to trading partners through the EPCIS Query 607

Control Interface or other data exchange / data synchronisation mechanisms. New vocabulary 608

elements within a given User Vocabulary are introduced at the sole discretion of an end user, 609

and trading partners must be prepared to respond accordingly. Usually, however, the rules for 610

constructing new User Vocabulary Elements are established by organisations of multiple end 611

users, and in any case must follow the rules defined in Section 6.4

below. 612

The lines between these two kinds of vocabularies are somewhat subjective. However, the 613

mechanisms defined in the EPCIS specification make absolutely no distinction between the two 614

vocabulary types, and so it is never necessary to identify a particular vocabulary as belonging to one 615

type or the other. The terms “Standard Vocabulary” and “User Vocabulary” are introduced only 616

because they are useful as a hint as to the way a given vocabulary is expected to be defined and 617

extended. 618

The GS1 Core Business Vocabulary (CBV) standard [CBV1.2] provides standardised vocabulary 619

elements for many of the vocabulary types used in EPCIS event types. In particular, the CBV defines 620

vocabulary elements for the following EPCIS Standard Vocabulary types: Business Step, Disposition, 621

Business Transaction Type, and Source/Destination Type. The CBV also defines templates for 622

constructing vocabulary elements for the following EPCIS User Vocabulary types: Object (EPC), 623

Object Class (EPCClass), Location (Read Point and Business Location), Business Transaction ID, 624

Source/Destination ID, and Transformation ID. 625

EPC Information Services (EPCIS) Standard

6.3 Extension mechanisms 626

A key feature of EPCIS is its ability to be extended by different organisations to adapt to particular 627

business situations. In all, the Abstract Data Model Layer provides five methods by which the data 628

processed by EPCIS may be extended (the Service Layer, in addition, provides mechanisms for 629

adding additional services), enumerated here from the most invasive type of extension to the least 630

invasive: 631

■ New Event Type: A new Event Type may be added in the Data Definition Layer. Adding a new 632

Event Type requires each of the Data Definition Bindings to be extended, and may also require 633

extension to the Capture and Query Interfaces and their Bindings. 634

■ New Event Field: A new field may be added to an existing Event Type in the Data Definition 635

Layer. The bindings, capture interface, and query interfaces defined in this specification are 636

designed to permit this type of extension without requiring changes to the specification itself. 637

(The same may not be true of other bindings or query languages defined outside this 638

specification.) 639

■ New Vocabulary Type: A new Vocabulary Type may be added to the repertoire of available 640

Vocabulary Types. No change to bindings or interfaces are required. 641

■ New master data attribute: A new attribute name may be defined for an existing Vocabulary. No 642

change to bindings or interfaces are required. 643

■ New Instance/Lot master data (ILMD) Attribute: A new attribute name may be defined for use in 644

Instance/Lot master data (ILMD); see Section 7.3.6

. No change to bindings or interfaces are 645

required. 646

■ New Vocabulary Element A new element may be added to an existing Vocabulary. 647

648

The Abstract Data Model Layer has been designed so that most extensions arising from adoption by 649

different industries or increased understanding within a given industry can be accommodated by the 650

latter methods in the above list, which do not require revision to the specification itself. The more 651

invasive methods at the head of the list are available, however, in case a situation arises that 652

cannot be accommodated by the latter methods. 653

It is expected that there will be several different ways to extend the EPCIS specification, as 654

summarised below: 655

How extension is

dsseminated

Responsible

organisation

Extension method

New

Event

Type

New

Event

Field

New

Vocabulary

Type

New master

data or ILMD

(Section 7.3.6

)

Attribute

New

Vocabulary

Element

New Version of

EPCIS standard

GS1 EPCIS Working

Group

Yes Yes Yes Occasionally Rarely

New Version of CBV

standard

GS1 Core Business

Vocabulary Working

Group

No No No Yes Yes

(Standard

Vocabulary,

User

Vocabulary

template)

GS1 Application

Standard for a

specific industry

GS1 Application

Standard Working

Group for a specific

industry

Rarely Rarely Occasionally Yes Yes

(Standard

Vocabulary)

GS1 Member

Organisation Local

Recommendation

Document for a

specific industry

within a specific

geography

GS1 Member

Organisation

Rarely Rarely Occasionally Yes Yes

(Standard

Vocabulary)

EPC Information Services (EPCIS) Standard

How extension is

dsseminated

Responsible

organisation

Extension method

New

Event

Type

New

Event

Field

New

Vocabulary

Type

New master

data or ILMD

(Section 7.3.6

)

Attribute

New

Vocabulary

Element

Private Group

Interoperability

Specification

Industry Consortium

or Private End User

Group outside GS1

Rarely Rarely Occasionally Yes Yes

(Standard

Vocabulary)

Updated master

data via EPCIS

Query or other data

sync

Individual End User Rarely Rarely Rarely Rarely Yes (User

vocabulary)

656

6.4 Identifier representation 657

The Abstract Data Model Layer introduces several kinds of identifiers, including Event Type names, 658

Event Field names, Vocabulary names, Vocabulary Elements, and master data Attribute Names. 659

Because all of these namespaces are open to extension, this specification imposes some rules on the 660

construction of these names so that independent organisations may create extensions without fear 661

of name collision. 662

Vocabulary Elements are subject to the following rules. In all cases, a Vocabulary Element is 663

represented as Uniform Resource Identifier (URI) whose general syntax is defined in [RFC2396]. 664

The types of URIs admissible as Vocabulary Elements are those URIs for which there is an owning 665

authority. This includes: 666

■ URI representations for EPC codes [TDS1.9, Section 6]. The owning authority for a particular 667

EPC URI is the organisation to whom the GS1 Company Prefix (or other issuing authority, 668

depending on the EPC scheme) was assigned. 669

■ Absolute Uniform Resource Locators (URLs) [RFC1738]. The owning authority for a particular 670

URL is the organisation that owns the Internet domain name in the authority portion of the URL. 671

■ Uniform Resource Names (URNs) [RFC2141] in the oid namespace that begin with a Private 672

Enterprise Number (PEN). The owning authority for an OID-URN is the organisation to which the 673

PEN was issued. 674

■ Uniform Resource Names (URNs) [RFC2141] in the

epc or epcglobal namespace, other than 675

URIs used to represent EPCs [TDS1.9]. The owning authority for these URNs is GS1. 676

Event Type names and Event Field names are represented as namespace-qualified names (qnames), 677

consisting of a namespace URI and a name. This has a straightforward representation in XML 678

bindings that is convenient for extension. 679

6.5 Hierarchical vocabularies 680

Some Vocabularies have a hierarchical or multi-hierarchical structure. For example, a vocabulary of 681

location names may have an element that means “Acme Corp. Retail Store #3” as well others that 682

mean “Acme Corp. Retail Store #3 Backroom” and “Acme Corp. Retail Store #3 Sales Floor.” In this 683

example, there is a natural hierarchical relationship in which the first identifier is the parent and the 684

latter two identifiers are children. 685

Hierarchical relationships between vocabulary elements are represented through master data. 686

Specifically, a parent identifier carries, in addition to its master data attributes, a list of its children 687

identifiers. Each child identifier SHALL belong to the same Vocabulary as the parent. In the example 688

above, the element meaning “Acme Corp. Distribution Centre #3” would have a children list 689

including the element that means “Acme Corp. Distribution Centre #3 Door #5.” 690

Elsewhere in this specification, the term “direct or indirect descendant” is used to refer to the set of 691

vocabulary elements including the children of a given vocabulary element, the children of those 692

children, etc. That is, the “direct or indirect descendants” of a vocabulary element are the set of 693

EPC Information Services (EPCIS) Standard

vocabulary elements obtained by taking the transitive closure of the “children” relation starting with 694

the given vocabulary element. 695

A given element MAY be the child of more than one parent. This allows for more than one way of 696

grouping vocabulary elements; for example, locations could be grouped both by geography and by 697

function. An element SHALL NOT, however, be a child of itself, either directly or indirectly. 698

Non-Normative: Explanation: In the present version of this specification, only one 699

hierarchical relationship is provided for, namely the relationship encoded in the special 700

“children” list. Future versions of this specification may generalise this to allow more than one 701

relationship, perhaps encoding each relationship via a different master data attribute. 702

Hierarchical relationships are given special treatment in queries (Section 8.2

), and may play a role 703

in carrying out authorisation policies (Section

8.2.2), but do not otherwise add any additional 704

complexity or mechanism to the Abstract Data Model Layer. 705

7 Data definition layer 706

This section includes normative specifications of modules in the Data Definition Layer. 707

7.1 General rules for specifying data definition layer modules 708

The general rules for specifying modules in the Data Definition Layer are given here. These rules are 709

then applied in Section 7.2

to define the Core Event Types Module. These rules can also be applied 710

by organisations wishing to layer a specification on top of this specification. 711

7.1.1 Content 712

In general, a Data Definition Module specification has these components, which populate the 713

Abstract Data Model framework specified in Section 6

: 714

■ Value Types: Definitions of data types that are used to describe the values of Event Fields and 715

of master data attributes. The Core Event Types Module defines the primitive types that are 716

available for use by all Data Definition Modules. Each Vocabulary that is defined is also implicitly 717

a Value Type. 718

■ Event Types: Definitions of Event Types, each definition giving the name of the Event Type 719

(which must be unique across all Event Types) and a list of standard Event Fields for that type. 720

An Event Type may be defined as a subclass of an existing Event Type, meaning that the new 721

Event Type includes all Event Fields of the existing Event Type plus any additional Event Fields 722

provided as part of its specification. 723

■ Event Fields: Definitions of Event Fields within Event Types. Each Event Field definition specifies 724

a name for the field (which must be unique across all fields of the enclosing Event Type) and the 725

data type for values in that field. Event Field definitions within a Data Definition Module may be 726

part of new Event Types introduced by that Module, or may extend Event Types defined in other 727

Modules. 728

■ Vocabulary Types: Definitions of Vocabulary Types, each definition giving the name of the 729

Vocabulary (which must be unique across all Vocabularies), a list of standard master data 730

attributes for elements of that Vocabulary, and rules for constructing new Vocabulary Elements 731

for that Vocabulary. (Any rules specified for constructing Vocabulary Elements in a Vocabulary 732

Type must be consistent with the general rules given in Section 6.4

.) 733

■ Master data attributes: Definitions of master data attributes for Vocabulary Types. Each master 734

data attribute definition specifies a name for the Attribute (which must be unique across all 735

attributes of the enclosing Vocabulary Type) and the data type for values of that attribute. 736

Master data definitions within a Data Definition Module may belong to new Vocabulary Types 737

introduced by that Module, or may extend Vocabulary Types defined in other Modules. 738

■ Vocabulary Elements: Definitions of Vocabulary Elements, each definition specifying a name 739

(which must be unique across all elements within the Vocabulary, and conform to the general 740

EPC Information Services (EPCIS) Standard

rules for Vocabulary Elements given in Section 6.4 as well as any specific rules specified in the 741

definition of the Vocabulary Type), and optionally specifying master data (specific attribute 742

values) for that element. 743

Non-Normative: Amplification: As explained in Section 6.3, Data Definition Modules defined 744

in this specification and by companion specifications developed by the EPCIS Working Group 745

will tend to include definitions of Value Types, Event Types, Event Fields, and Vocabulary 746

Types, while modules defined by other groups will tend to include definitions of Event Fields 747

that extend existing Event Types, master data attributes that extend existing Vocabulary 748

Types, and Vocabulary Elements that populate existing Vocabularies. Other groups may also 749

occasionally define Vocabulary Types. 750

The word “Vocabulary” is used informally to refer to a Vocabulary Type and the set of all Vocabulary 751

Elements that populate it. 752

7.1.2 Notation 753

In the sections below, Event Types and Event fields are specified using a restricted form of UML 754

class diagram notation. UML class diagrams used for this purpose may contain classes that have 755

attributes (fields) and associations, but not operations. Here is an example: 756

757

This diagram shows a data definition for two Event Types,

EventType1 and EventType2. These 758

event types make use of four Value Types:

Type1, Type2, DataClass3, and DataClass4. Type1 759

and

Type2 are primitive types, while DataClass3 and DataClass4 are complex types whose 760

structure is also specified in UML. 761

The Event Type

EventType1 in this example has four fields. Field1 and Field2 are of primitive 762

type

Type1 and Type2 respectively. EventType1 has another field Field3 whose type is 763

DataClass3. Finally, EventType1 has another field Fi

eld4 that contains a list of zero or more 764

instances of type

DataClass4 (the “0..*” notation indicates “zero or more”). 765

This diagram also shows a data definition for EventType2. The arrow with the open-triangle 766

arrowhead indicates that EventType2 is a subclass of

EventType1. This means that EventType2 767

actually has five fields: four fields inherited from

EventType1 plus a fifth field5 of type Type1. 768

Within the UML descriptions, the notation <<extension point>> identifies a place where 769

implementations SHALL provide for extensibility through the addition of new data members. (When 770

one type has an extension point, and another type is defined as a subclass of the first type and also 771

has an extension point, it does not mean the second type has two extension points; rather, it 772

merely emphasises that the second type is also open to extension.) Extensibility mechanisms SHALL 773

provide for both proprietary extensions by vendors of EPCIS-compliant products, and for extensions 774

defined by GS1 through future versions of this specification or through new specifications. 775

EventType1

field1 : Type1

field2 : Type2

<<extension point>>

DataClass3

DataClass4

Field3

Field4

0..*

EventType2

field5 : Type1

<<extension point>>

EPC Information Services (EPCIS) Standard

In the case of the standard XML bindings, the extension points are implemented within the XML 776

schema following the methodology described in Section 9.1

. 777

All definitions of Event Types SHALL include an extension point, to provide for the extensibility 778

defined in Section 6.3

(“New Event Fields”). Value Types MAY include an extension point. 779

7.1.3 Semantics 780

Each event (an instance of an Event Type) encodes several assertions which collectively define the 781

semantics of the event. Some of these assertions say what was true at the time the event was 782

captured. Other assertions say what is expected to be true following the event, until invalidated by a 783

subsequent event. These are called, respectively, the retrospective semantics and the prospective 784

semantics of the event. For example, if widget #23 enters building #5 through door #6 at 11:23pm, 785

then one retrospective assertion is that “widget #23 was observed at door #6 at 11:23pm,”, while a 786

prospective assertion is that “widget #23 is in building #5.” The key difference is that the 787

retrospective assertion refers to a specific time in the past (“widget #23 was observed…”), while the 788

prospective assertion is a statement about the present condition of the object (“widget #23 is in…”). 789

The prospective assertion presumes that if widget #23 ever leaves building #5, another EPCIS 790

capture event will be recorded to supersede the prior one. 791

In general, retrospective semantics are things that were incontrovertibly known to be true at the 792

time of event capture, and can usually be relied upon by EPCIS Accessing Applications as accurate 793

statements of historical fact. Prospective semantics, since they attempt to say what is true after an 794

event has taken place, must be considered at best to be statements of “what ought to be” rather 795

than of “what is.” A prospective assertion may turn out not to be true if the capturing apparatus 796

does not function perfectly, or if the business process or system architecture were not designed to 797

capture EPCIS events in all circumstances. Moreover, in order to make use of a prospective 798

assertion implicit in an event, an EPCIS Accessing Application must be sure that it has access to any 799

subsequent event that might supersede the event in question. 800

The retrospective/prospective dichotomy plays an important role in EPCIS’s definition of location, in 801

Section 7.3.4

. 802

In certain situations, an earlier event is subsequently discovered to be in error (the assertions its 803

semantics makes are discovered to be incorrect), and the error cannot be corrected by recording a 804

new event that adds additional assertions through its own semantics. For these cases, a mechanism 805

is provided to record an event whose semantics assert that the assertions previously made by the 806

erroneous event are in error. See Section 7.4.1.2

. 807

7.2 Core event types module – overview 808

The Core Event Types data definition module specifies the Event Types that represent EPCIS data 809

capture events. These events are typically generated by an EPCIS Capturing Application and 810

provided to EPCIS infrastructure using the data capture operations defined in Section 8.1

. These 811

events are also returned in response to query operations that retrieve events according to query 812

criteria. 813

The components of this module, following the outline given in Section 7.1.1, are as follows: 814

■ Value Types: Primitive types defined in Sections 7.3.1 and 7.3.2. 815

■ Event Types: Event types as shown in the UML diagram below, and defined in Sections 7.4.1 816

through

7.4.6. 817

■ Event Fields: Included as part of the Event Types definitions. 818

■ Vocabulary Types: Types defined in Sections 7.3.3 through 7.3.5, and summarised in 819

Section

7.2. 820

■ Master data attributes: Included as part of Vocabulary Types definitions. It is expected that 821

industry vertical working groups will define additional master data attributes for the vocabularies 822

defined here. 823

■ Vocabulary Elements: None provided as part of this specification. It is expected that industry 824

vertical working groups will define vocabulary elements for the

BusinessStep vocabulary 825

EPC Information Services (EPCIS) Standard

(Section 7.3.5), the Disposition vocabulary (Section 7.3.5.2), and the 826

BusinessTransactionType vocabulary (Section 7.3.5.3.1). 827

This module defines six event types, one very generic event and five subclasses (one of which is 828

deprecated as of EPCIS 1.1) that can represent events arising from supply chain activity across a 829

wide variety of industries: 830

■ EPCISEvent (Section 7.4.1

) is a generic base class for all event types in this module as well as 831

others. 832

■ ObjectEvent (Section 7.4.1.2) represents an event that happened to one or more physical or 833

digital objects. 834

■ AggregationEvent (Section 7.4.3) represents an event that happened to one or more objects 835

that are physically aggregated together (physically constrained to be in the same place at the 836

same time, as when cases are aggregated to a pallet). 837

■ QuantityEvent (Section 7.4.4) represents an event concerned with a specific quantity of 838

objects sharing a common EPC class, but where the individual identities of the entities are not 839

specified. As of EPCIS 1.1, this event is deprecated; an ObjectEvent (Section 7.4.1.2) with one 840

or more QuantityElements (Section

7.3.3.3) should be used instead. 841

■ TransactionEvent (Section 7.4.5) represents an event in which one or more objects become 842

associated or disassociated with one or more identified business transactions. 843

■ TransformationEvent (Section 7.4.6) represents an event in which input objects are fully or 844

partially consumed and output objects are produced, such that any of the input objects may 845

have contributed to all of the output objects. 846

A UML diagram showing these Event Types is as follows: 847

848

EPC Information Services (EPCIS) Standard

849

Each of the core event types (not counting the generic

EPCISEvent) has fields that represent four 850

key dimensions of any EPCIS event. These four dimensions are: (1) the object(s) or other entities 851

EPCISEvent

eventTime : Time

recordTime : Time

eventTimeZoneOffset : string

eventID : EventID

<<extension point>>

ObjectEvent

epcList : List<EPC>

action : Action

bizStep : BizStepID

disposition : DispositionID

readPoint : ReadPointID

bizLocation : BizLocationID

ilmd: ILMD

<<extension point>>

QuantityEvent

<<deprecated>>

epcClass : EPCClass

quantity : int

bizStep : BizStepID

disposition : DispositionID

readPoint : ReadPointID

bizLocation :

BizLocationID

<<extension point>>

AggregationEvent

parentID : URI

childEPCs : List<EPC>

action : Action

bizStep : BizStepID

disposition : DispositionID

readPoint : ReadPointID

bizLocation : BizLocationID

<<extension point>>

Note: in this diagram, certain names have been abbreviated owing to

space constraints; e.g.,

BizLocationID is used in the diagram,

whereas the actual type is called

BusinessLocationID. See the text

of the specification for the normative names of fields and their types

TransactionEvent

parentID : URI

epcList : List<EPC>

action : Action

bizStep : BizStepID

disposition : DispositionID

readPoint : ReadPointID

bizLocation : BizLocationID

BizTransaction

type : BizTransTypeID

bizTrans : BizTransID

0..*

qList

Red indicates class or attribute

that is new in EPCIS 1.2

0..1 = “zero or one”

0..* = “zero or more”

1..* = “one or more”

TransformationEvent

inputEpcList : List<EPC>

outputEpcList : List<EPC>

xformID : XformID

bizStep : BizStepID

disposition : DispositionID

readPoint : ReadPointID

bizLocation : BizLocationID

ilmd : ILMD

Source

type : SourceDestTypeID

source : SourceDestID

Destination

type : SourceDestTypeID

dest : SourceDestID

QuantityElement

epcClass EPCClass

quantity : decimal

uom : UOM

0..*

childQList

1..* for TransactionEvent

0..* otherwise

qList

0..*

inputQList

outputQList

0..*

ErrorDeclaration

declarationTime : Time

reason : ErrorReasonID

correctiveEventIDs :

List<EventID>

0..1

error

Declaration

EPC Information Services (EPCIS) Standard

that are the subject of the event; (2) the date and time; (3) the location at which the event 852

occurred; (4) the business context. These four dimensions may be conveniently remembered as 853

“what, when, where, and why” (respectively). The “what” dimension varies depending on the event 854

type (e.g., for an

ObjectEvent the “what” dimension is one or more EPCs; for an 855

AggregationEvent the “what” dimension is a parent ID and list of child EPCs). The “where” and 856

“why” dimensions have both a retrospective aspect and a prospective aspect (see Section 7.1.3), 857

represented by different fields. 858

The following table summarises the fields of the event types that pertain to the four key 859

dimensions: 860

Retrospective

(at the time of the event)

Prospective

(true until contradicted by

subsequent event)

What

EPC

EPCClass

+ quantity

When

Time

Where

ReadPointID

BusinessLocationID

Why

(business context)

BusinessStepID

DispositionID

BusinessTransactionList

Source/Destination

ILMD

861

In addition to the fields belonging to the four key dimensions, events may carry additional 862

descriptive information in other fields. It is expected that the majority of additional descriptive 863

information fields will be defined by industry-specific specifications layered on top of this one. 864

The following table summarises the vocabulary types defined in this module. The URI column gives 865

the formal name for the vocabulary used when the vocabulary must be referred to by name across 866

the EPCIS interface. 867

Vocabulary type Section User /

standard

URI

ReadPointID

7.3.4 User

urn:epcglobal:epcis:vtype:ReadPoint

BusinessLocati

onID

7.3.4 User

urn:epcglobal:epcis:vtype:BusinessLocation

BusinessStepID

7.3.5 Standard

urn:epcglobal:epcis:vtype:BusinessStep

DispositionID

7.3.5.2 Standard

urn:epcglobal:epcis:vtype:Disposition

BusinessTransa

ction

7.3.5.3.2 User

urn:epcglobal:epcis:vtype:BusinessTransaction

BusinessTrasac

tionTypeID

7.3.5.3.1 Standard

urn:epcglobal:epcis:vtype:BusinessTransaction

Type

EPCClass

7.3.5.4 User

urn:epcglobal:epcis:vtype:EPCClass

SourceDestType

7.3.5.4.1 Standard

urn:epcglobal:epcis:vtype:SourceDestType

SourceDestID

7.3.5.4.2 User

urn:epcglobal:epcis:vtype:SourceDest

LocationID

See below User

urn:epcglobal:epcis:vtype:Location

ErrorReasonID

7.4.1.2 Standard

urn:epcglobal:epcis:vtype:ErrorReason

868

The

LocationID type is a supertype of ReadPointID, BusinessStepID, and SourceDestID. In an EPCIS 869

master data document (or master data header within an EPCIS document or EPCIS query document), the 870

EPC Information Services (EPCIS) Standard

urn:epcglobal:epcis:vtype:Location URI may be used to specify a single vocabulary containing 871

identifiers that may appear in the read point, business step, source, or destination field of associated EPCIS 872

events. 873

7.3 Core event types module – building blocks 874

This section specifies the building blocks for the event types defined in Section 7.3.5.4

. 875

7.3.1 Primitive types 876

The following primitive types are used within the Core Event Types Module. 877

Type Description

int

An integer. Range restrictions are noted where applicable.

Time

A timestamp, giving the date and time in a time zone-independent manner. For bindings in which fields of

this type are represented textually, an ISO-8601 compliant representation SHOULD be used.

EPC

An Electronic Product Code, as defined in [TDS1.9]. Unless otherwise noted, EPCs are represented in “pure

identity” URI form as defined in [TDS1.9],

Section 7.

878

The EPC type is defined as a primitive type for use in events when referring to EPCs that are not 879

part of a Vocabulary Type. For example, an SGTIN EPC used to denote an instance of a trade item in 880

the epcList field of an ObjectEvent is an instance of the EPC primitive type. But an SGLN EPC 881

used as a read point identifier (Section 7.3.4

) in the ReadPoint field of an ObjectEvent is a 882

Vocabulary Element, not an instance of the EPC primitive type. 883

Non-Normative: Explanation: This reflects a design decision not to consider individual trade 884

item instances as Vocabulary Elements having master data, owing to the fact that trade item 885

instances are constantly being created and hence new EPCs representing trade items are 886

constantly being commissioned. In part, this design decision reflects consistent treatment of 887

master data as excluding data that grows as more business is transacted (see comment in 888

Section 6.1

), and in part reflects the pragmatic reality that data about trade item instances is 889

likely to be managed more like event data than master data when it comes to aging, database 890

design, etc. 891

7.3.2 Action type 892

The Action type says how an event relates to the lifecycle of the entity being described. For 893

example,

AggregationEvent (Section 7.4.3) is used to capture events related to aggregations of 894

objects, such as cases aggregated to a pallet. Throughout its life, the pallet load participates in 895

many business process steps, each of which may generate an EPCIS event. The

action field of 896

each event says how the aggregation itself has changed during the event: have objects been added 897

to the aggregation, have objects been removed from the aggregation, or has the aggregation simply 898

been observed without change to its membership? The

action is independent of the bizStep (of 899

type

BusinessStepID) which identifies the specific business process step in which the action took 900

place. 901

The Action type is an enumerated type having three possible values: 902

Action

value

Meaning

ADD

The entity in question has been created or added to.

OBSERVE

The entity in question has not been changed: it has neither been created, added to, destroyed,

or removed from.

DELETE

The entity in question has been removed from or destroyed altogether.

903

EPC Information Services (EPCIS) Standard

The description below for each event type that includes an Action value says more precisely what 904

Action means in the context of that event. 905

Note that the three values above are the only three values possible for

Action. Unlike other types 906

defined below,

Action is not a vocabulary type, and SHALL NOT be extended by industry groups. 907

7.3.3 The “What” dimension 908

This section defines the data types used in the “What” dimension of the event types specified in 909

Section 7.3.5.4. 910

7.3.3.1 Instance-level vs. Class-level identification 911

The “What” dimension of an EPCIS event specifies what physical or digital objects participated in the 912

event. EPCIS provides for objects to be identified in two ways: 913

■ Instance-level: An identifier is said to be an instance-level identifier if such identifiers are 914

assigned so that each is unique to a single object. That is, no two objects are allowed to carry 915

the same instance-level identifier. 916

■ Class-level: An identifier is said to be a class-level identifier if multiple objects may carry the 917

same identifier. 918

In general, instance-level identifiers allow EPCIS events to convey more information, because it is 919

possible to correlate multiple EPCIS events whose “what” dimension includes the same instance-920

level identifiers. For example, if an EPCIS event contains a given instance-level identifier, and a 921

subsequent EPCIS event contains the same identifier, then it is certain that the very same object 922

participated in both events. In contrast, if both events contained class-level identifiers, then it is not 923

certain that the same object participated in both events, because the second event could have been 924

a different instance of the same class (i.e., a different object carrying the same class-level identifier 925

as the first object). Class-level identifiers are typically used only when it is impractical to assign 926

unique instance-level identifiers to each object. 927

Non-Normative: Examples: In the GS1 system, examples of instance-level identifiers 928

include GTIN+serial, SSCC, GRAI including serial, GIAI, GSRN, and GDTI including serial. 929

Examples of class-level identifiers include GTIN, GTIN+lot, GRAI without serial, and GDTI 930

without serial. 931

7.3.3.2 EPC 932

An Electronic Product Code (EPC) is an instance-level identifier structure defined in the EPC Tag 933

Data Standard [TDS1.9]. In the “what” dimension of an EPCIS event, the value of an

epc element 934

SHALL be a URI [RFC2396] denoting the unique instance-level identity for an object. When the 935

unique identity is an Electronic Product Code, the list element SHALL be the “pure identity” URI for 936

the EPC as specified in [TDS1.9], Section 6. Implementations MAY accept URI-formatted identifiers

937

other than EPCs as the value of an epc element. 938

7.3.3.3 QuantityElement 939

A QuantityElement is a structure that identifies objects identified by a specific class-level 940

identifier, either a specific quantity or an unspecified quantity. It has the following structure: 941

Field Type Description

epcClass EPCClass

A class-level identifier for the class to which the specified quantity of objects

belongs.

EPC Information Services (EPCIS) Standard

Field Type Description

quantity Decimal

(Optional) A number that specifies how many or how much of the specified

EPCClass is denoted by this QuantityElement.

The

quantity may be omitted to indicate that the quantity is unknown or not

specified. If

quantity is omitted, then uom SHALL be omitted as well.

Otherwise, if

quantity is specified:

If the

QuantityElement lacks a uom field (below), then the quantity SHALL

have a positive integer value, and denotes a count of the number of instances

of the specified

EPCClass that are denoted by this QuantityElement.

If the QuantityElement includes a uom, then the quantity SHALL have a

positive value (but not necessarily an integer value), and denotes the

magnitude of the physical measure that specifies how much of the specified

EPCClass

is denoted by this

QuantityElement

uom UOM

(Optional) If present, specifies a unit of measure by which the specified

quantity is to be interpreted as a physical measure, specifying how much of

the specified

EPCClass is denoted by this QuantityElement. The uom

SHALL be omitted if

quantity

is omitted.

942

EPCClass is a Vocabulary whose elements denote classes of objects. EPCClass is a User 943

Vocabulary as defined in Section 6.2. Any EPC whose structure incorporates the concept of object 944

class can be referenced as an EPCClass. The standards for SGTIN EPCs are elaborated below. 945

An EPCClass may refer to a class having fixed measure or variable measure. A fixed measure class 946

has instances that may be counted; for example, a GTIN that refers to fixed-size cartons of a 947

product. A variable measure class has instances that cannot be counted and so the quantity is 948

specified as a physical measure; for example, a GTIN that refers to copper wire that is sold by 949

length, carpeting that is sold by area, bulk oil that is sold by volume, or fresh produce that is sold by 950

weight. The following table summarises how the

quantity and uom fields are used in each case: 951

EPCClass

quantity

field

uom

field

Meaning

Fixed

measure

Positive integer Omitted The quantity field specifies the count of the specified

class.

Variable

measure

Positive number, not

necessarily an integer

Present The quantity field specifies the magnitude, and the uom

field the physical unit, of a physical measure describing the

amount of the specified class.

Fixed or

Variable

Measure

Omitted Omitted The quantity is unknown or not specified.

952

Master data attributes for the

EPCClass vocabulary contain whatever master data is defined for the 953

referenced objects independent of EPCIS (for example, product catalogue data); definitions of these 954

are outside the scope of this specification. 955

7.3.3.3.1 UOM 956

As specified above, the uom field of a QuantityElement is present when the QuantityElement 957

uses a physical measure to specify the quantity of the specified

EPCClass. When a uom field is 958

present, its value SHALL be the 2- or 3-character code for a physical unit specified in the “Common 959

Code” column of UN/CEFACT Recommendation 20 [CEFACT20]. Moreover, the code SHALL be a code 960

contained in a row of [CEFACT20] meeting all of the following criteria: 961

■ The “Quantity” column contains one of the following quantities: length, area, volume, or mass. 962

■ The “Status” column does not contain “X” (deleted) or “D” (deprecated). 963

For purposes of the first criterion, the quantity must appear as a complete phrase. Example: 964

“metre” (MTR) is allowed, because the quantity includes length (among other quantities such as 965

EPC Information Services (EPCIS) Standard

breadth, height, etc.). But “pound-force per foot” (F17) is not allowed, because the quantity is force 966

divided by length, not just length. 967

7.3.3.3.2 EPCClass values for GTIN 968

When a Vocabulary Element in EPCClass represents the class of SGTIN EPCs denoted by a specific 969

GTIN, it SHALL be a URI in the following form, as defined in Version 1.3 and later of the EPC Tag 970

Data Standards: 971

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

where

CompanyPrefix is the GS1 Company Prefix of the GTIN (including leading zeros) and 973

ItemRefAndIndicator consists of the indicator digit of the GTIN followed by the digits of the item 974

reference of the GTIN. 975

EPCClass vocabulary element in this form denotes the class of objects whose EPCs are SGTINs 976

(

urn:epc:id:sgtin:…) having the same CompanyPrefix and ItemRefAndIndicator fields, 977

and having any serial number whatsoever (or no serial number at all). 978

7.3.3.3.3 EPCClass values for GTIN + Batch/Lot 979

When a Vocabulary Element in EPCClass represents the class of SGTIN EPCs denoted by a specific 980

GTIN and batch/lot, it SHALL be a URI in the following form, as defined in [TDS1.9, Section 6]: 981

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

where

CompanyPrefix is the GS1 Company Prefix of the GTIN (including leading zeros), 983

ItemRefAndIndicator consists of the indicator digit of the GTIN followed by the digits of the item 984

reference of a GTIN, and Lot is the batch/lot number of the specific batch/lot. 985

An EPCClass vocabulary element in this form denotes the class of objects whose EPCs are SGTINs 986

(

urn:epc:id:sgtin:…) having the same CompanyPrefix and ItemRefAndIndicator fields, 987

and belonging to the specified batch/lot, regardless of serial number (if any). 988

7.3.3.4 Summary of identifier types (Non-Normative) 989

This section summarises the identifiers that may be used in the “what” dimension of EPCIS events. 990

The normative specifications of identifiers are in the EPC Tag Data Standard [TDS1.9] and the EPC 991

Core Business Vocabulary [CBV1.2]. 992

Identifier type Instance-level

(EPC)

Class-level

(EPCClass)

URI prefix Normative

reference

GTIN



urn:epc:idpat:sgtin:

[TDS1.9,

Section 8]

GTIN +

batch/lot



urn:epc:class:lgtin:

[TDS1.9,

Section 6]

GTIN + serial



urn:epc:id:sgtin:

[TDS1.9,

Section

6.3.1]

SSCC



urn:epc:id:sscc:

[TDS1.9,

Section

6.3.2]

GRAI (no

serial)



urn:epc:idpat:grai:

[TDS1.9,

Section 8]

GRAI (with

serial)



urn:epc:id:grai:

[TDS 1.9,

Section

6.3.4]

EPC Information Services (EPCIS) Standard

Identifier type Instance-level

(EPC)

Class-level

(EPCClass)

URI prefix Normative

reference

GIAI



urn:epc:id:giai:

[TDS1.9,

Section

6.3.5]

GDTI (no

serial)



urn:epc:idpat:gdti:

[TDS1.9,

Section 8]

GDTI (with

serial)



urn:epc:id:gdti:

[TDS1.9,

Section

6.3.7]

GSRN

(Recipient)



urn:epc:id:gsrn:

[TDS1.9,

Section

6.3.6]

GSRN

(Provider)



urn:epc:id:gsrnp:

[TDS1.9,

Section

6.3.6]

GCN (no

serial)



urn:epc:idpat:sgcn:

[TDS1.9,

Section 8]

GCN (with

serial)



urn:epc:id:sgcn:

[TDS1.9,

Section 6]

CPI



urn:epc:idpat:cpi:

[TDS1.9,

Section 8]

CPI + serial



urn:epc:id:cpi:

[TDS1.9,

Section

6.3.11]

GID



urn:epc:id:gid:

[TDS1.9,

Section

6.3.8]

USDoD



urn:epc:id:usdod:

[TDS1.9,

Section

6.3.9]

ADI



urn:epc:id:adi:

[TDS1.9,

Section

6.3.10]

Non-GS1

Identifier

 

Any URI – see CBV for

recommendations

[CBV1.2,

Section 8.2]

993

7.3.4 The “Where” Dimension – read point and business location 994

This section defines four types that all relate to the notion of location information as used in EPCIS. 995

Two of these types are ways of referring to “readers,” or devices that sense the presence of EPC-996

tagged objects using RFID or other means. These are not actually considered to be “location” types 997

at all for the purposes of EPCIS. They are included in this specification mainly to contrast them to 998

the true location types (though some applications may want to use them as extension fields on 999

observations, for auditing purposes). The other two types are true location types, and are defined as 1000

EPCIS Vocabulary Types. 1001

The reader/location types are as follows: 1002

Type Description

Primitive Reader Types – not location types for EPCIS

EPC Information Services (EPCIS) Standard

Type Description

PhysicalReaderID

This is the unique identity or name of the specific information source (e.g., a physical

RFID Reader) that reports the results of an EPC read event. Physical Reader ID is further

defined in [ALE1.0].

LogicalReaderID

This is the identity or name given to an EPC read event information source independent

of the physical device or devices that are used to perform the read event. Logical Reader

ID is further defined in [ALE1.0]. There are several reasons for introducing the Logical

Reader concept as outlined in [ALE1.0], including allowing physical readers to be

replaced without requiring changes to EPCIS Capturing Applications, allowing multiple

physical readers to be given a single name when they are always used simultaneously to

cover a single location, and (conversely) allowing a single physical reader to map to

multiple logical readers when a physical reader has multiple antennas used independently

to cover different locations.

True Location Types

ReadPointID

A Read Point is a discretely recorded location that is meant to identify the most specific

place at which an EPCIS event took place. Read Points are determined by the EPCIS

Capturing Application, perhaps inferred as a function of logical reader if stationary

readers are used, perhaps determined overtly by reading a location tag if the reader is

mobile, or in general determined by any other means the EPCIS Capturing Application

chooses to use. Conceptually, the Read Point is designed to identify “where objects were

at the time of the EPCIS event.”

BusinessLocationID

A Business Location is a uniquely identified and discretely recorded location that is meant

to designate the specific place where an object is assumed to be following an EPCIS

event until it is reported to be at a different Business Location by a subsequent EPCIS

event. As with the Read Point, the EPCIS Capturing Application determines the Business

Location based on whatever means it chooses. Conceptually, the Business Location is

designed to identify “where objects are following the EPCIS event.”

ReadPointID and BusinessLocationID are User Vocabularies as defined in Section 6.2. Some 1003

industries may wish to use EPCs as vocabulary elements, in which case pure identity URIs as 1004

defined in [TDS1.9] SHALL be used. 1005

Non-Normative: Illustration: For example, in industries governed by GS1 General 1006

Specifications,

readPointID, and businessLocationID may be SGLN-URIs [TDS1.9, 1007

Section 6.3.3], and

physicalReaderID may be an SGTIN-URI [TDS1.9, Section 6.3.1]. 1008

But in all cases, location vocabulary elements are not required to be EPCs. 1009

Non-Normative: Explanation: Allowing non-EPC URIs for locations gives organisations 1010

greater freedom to reuse existing ways of naming locations. 1011

For all of the EPCIS Event Types defined in this Section 7.2

, capture events include separate fields 1012

for Read Point and Business Location. In most cases, both are optional, so that it is still possible for 1013

an EPCIS Capturing Application to include partial information if both are not known. 1014

Non-Normative: Explanation: Logical Reader and Physical Reader are omitted from the 1015

definitions of EPCIS events in this specification. Physical Reader is generally not useful 1016

information for exchange between partners. For example, if a reader malfunctions and is 1017

replaced by another reader of identical make and model, the Physical Reader ID has changed. 1018

This information is of little interest to trading partners. Likewise, the Logical Reader ID may 1019

change if the capturing organisation makes a change in the way a particular business process 1020

is executed; again, not often of interest to a partner. 1021

The distinction between Read Point and Business Location is very much related to the dichotomy 1022

between retrospective semantics and prospective semantics discussed above. In general, Read 1023

Points play a role in retrospective semantics, while Business Locations are involved in prospective 1024

statements. This is made explicit in the way each type of location enters the semantic descriptions 1025

given at the end of each section below that defines an EPCIS capture event. 1026

EPC Information Services (EPCIS) Standard

7.3.4.1 Example of the distinction between a read point and a business location 1027

(Non-Normative) 1028

1029

Tag

Time

Read Point

Business

Location

Comment

#123

7:00

“RP-DC#88-A”

DC#88.Receive & Store

Product entered DC via DockDoor#R1

#123

9:00

“RP-DC#88-K”

DC#88.Shipping

Product placed on conveyor for shipping

#123

9:30

“RP-DC#88-N”

[omitted]

Product shipped via dock door#S2

1030

The figure above shows a typical use case consisting of rooms with fixed doorways at the 1031

boundaries of the rooms. In such a case, Read Points correspond to the doorways (with RFID 1032

instrumentation) and Business Locations correspond to the rooms. Note that the Read Points and 1033

Business Locations are not in one-to-one correspondence; the only situation where Read Points and 1034

Business Locations could have a 1:1 relationship is the unusual case of a room with a single door, 1035

such a small storeroom. 1036

Still considering the rooms-and-doors example, the Business Location is usually the location type of 1037

most interest to a business application, as it says which room an object is in. Thus it is meaningful 1038

to ask the inventory of a Business Location such as the backroom. In contrast, the Read Point 1039

indicates the doorway through which the object entered the room. It is not meaningful to ask the 1040

inventory of a doorway. While sometimes not as relevant to a business application, the Read Point is 1041

nevertheless of significant interest to higher level software to understand the business process and 1042

the final status of the object, particularly in the presence of less than 100% read rates. Note that 1043

correct designation of the business location requires both that the tagged object be observed at the 1044

Simple Distribution Center

RP:C

Recv Dock#R3

DC#88

RP:B

Recv Dock#R2

RP:A

Recv Dock#R1

RP:M

Shipping Dock#S1

RP:N

Shipping Dock#S2

RP:O

Shipping Dock#S3

Receive & Store

Shipping

Read

Point

RP:C

RP:A

RP:B

RP:K

RP:O

RP:N

RP:M

R&S

Shipping

DC#88

Graph

View

Physical

View

EPC Information Services (EPCIS) Standard

Read Point and that the direction of movement be correctly determined – again reporting the Read 1045

Point in the event will be very valuable for higher level software. 1046

A supply chain like the rooms-and-doors example may be represented by a graph in which each 1047

node in the graph represents a room in which objects may be found, and each arc represents a 1048

doorway that connects two rooms. Business Locations, therefore, correspond to nodes of this graph, 1049

and Read Points correspond to the arcs. If the graph were a straight, unidirectional chain, the arcs 1050

traversed by a given object could be reconstructed from knowing the nodes; that is, Read Point 1051

information would be redundant given the Business Location information. In more real-world 1052

situations, however, objects can take multiple paths and move “backwards” in the supply chain. In 1053

these real-world situations, providing Read Point information in addition to Business Location 1054

information is valuable for higher level software. 1055

7.3.4.2 Explanation of reader types versus location types (Non-Normative) 1056

In the EPC context, the term location has been used to signify many different things and this has 1057

lead to confusion about the meaning and use of the term, particularly when viewed from a business 1058

perspective. This confusion stems from a number of causes: 1059

1. In situations where EPC Readers are stationary, there’s a natural tendency to equate the reader 1060

with a location, though that may not always be valid if there is more than one reader in a 1061

location; 1062

2. There are situations where stationary Readers are placed between what business people would 1063

consider to be different locations (such as at the door between the backroom and sales floor of a 1064

retail store) and thus do not inherently determine the location without an indication of the 1065

direction in which the tagged object was travelling; 1066

3. A single physical Reader having multiple, independently addressable antennas might be used to 1067

detect tagged objects in multiple locations as viewed by the business people; 1068

4. Conversely, more than one Reader might be used to detect tagged objects in what business 1069

people would consider a single location; 1070

5. With mobile Readers, a given Reader may read tagged objects in multiple locations, perhaps 1071

using “location” tags or other means to determine the specific location associated with a given 1072

read event; 1073

6. And finally, locations of interest to one party (trading partner or application) may not be of 1074

interest to or authorised for viewing by another party, prompting interest in ways to 1075

differentiate locations. 1076

The key to balancing these seemingly conflicting requirements is to define and relate various 1077

location types, and then to rely on the EPCIS Capturing Application to properly record them for a 1078

given capture event. This is why EPCIS events contain both a ReadPointID and a BusinessLocationID 1079

(the two primitive location types). 1080

In addition, there has historically been much confusion around the difference between “location” as 1081

needed by EPCIS-level applications and reader identities. This EPCIS specification defines location as 1082

something quite distinct from reader identity. To help make this clear, the reader identity types are 1083

defined above to provide a contrast to the definitions of the true EPCIS location types. Also, reader 1084

identity types may enter into EPCIS as “observational attributes” when an application desires to 1085

retain a record of what readers played a role in an observation; e.g., for auditing purposes. (Capture 1086

and sharing of “observational attributes” would require use of extension fields not defined in this 1087

specification.) 1088

7.3.5 The “Why” dimension 1089

This section defines the data types used in the “Why” dimension of the event types specified in 1090

Section 7.3.5.4. 1091

EPC Information Services (EPCIS) Standard

7.3.5.1 Business step 1092

BusinessStepID is a vocabulary whose elements denote steps in business processes. An example 1093

is an identifier that denotes “shipping.” The business step field of an event specifies the business 1094

context of an event: what business process step was taking place that caused the event to be 1095

captured?

BusinessStepID is an example of a Standard Vocabulary as defined in Section 6.2. 1096

Non-Normative: Explanation: Using an extensible vocabulary for business step identifiers 1097

allows GS1 standards (including and especially the GS1 Core Business Vocabulary) to define 1098

some common terms such as “shipping” or “receiving,” while allowing for industry groups and 1099

individual end-users to define their own terms. Master data provides additional information. 1100

This specification defines no master data attributes for business step identifiers. 1101

7.3.5.2 Disposition 1102

DispositionID is a vocabulary whose elements denote a business state of an object. An example 1103

is an identifier that denotes “recalled.” The disposition field of an event specifies the business 1104

condition of the event’s objects, subsequent to the event. The disposition is assumed to hold true 1105

until another event indicates a change of disposition. Intervening events that do not specify a 1106

disposition field have no effect on the presumed disposition of the object.

DispositionID is an 1107

example of a Standard Vocabulary as defined in Section 6.2. 1108

Non-Normative: Explanation: Using an extensible vocabulary for disposition identifiers 1109

allows GS1 standards (including and especially the GS1 Core Business Vocabulary) to define 1110

some common terms such as “recalled” or “in transit,” while allowing for industry groups and 1111

individual end-users to define their own terms. Master data may provide additional 1112

information. 1113

This specification defines no master data attributes for disposition identifiers. 1114

7.3.5.3 Business transaction 1115

BusinessTransaction identifies a particular business transaction. An example of a business 1116

transaction is a specific purchase order. Business Transaction information may be included in EPCIS 1117

events to record an event’s participation in particular business transactions. 1118

A business transaction is described in EPCIS by a structured type consisting of a pair of identifiers, 1119

as follows. 1120

Field Type Description

type BusinessTransactionTypeID

(Optional) An identifier that indicates what kind of

business transaction this

BusinessTransaction

denotes. If omitted, no information is available about

the type of business transaction apart from what is

implied by the value of the

bizTransaction field

itself.

bizTransaction BusinessTransactionID

An identifier that denotes a specific business

transaction.

The two vocabulary types BusinessTransactionTypeID and BusinessTransactionID are 1121

defined in the sections below. 1122

7.3.5.3.1 Business transaction type 1123

BusinessTransactionTypeID is a vocabulary whose elements denote a specific type of business 1124

transaction. An example is an identifier that denotes “purchase order.” 1125

BusinessTransactionTypeID is an example of a Standard Vocabulary as defined in Section 6.2. 1126

EPC Information Services (EPCIS) Standard

Non-Normative: Explanation: Using an extensible vocabulary for business transaction type 1127

identifiers allows GS1 standards to define some common terms such as “purchase order” 1128

while allowing for industry groups and individual end-users to define their own terms. Master 1129

data may provide additional information. 1130

This specification defines no master data attributes for business transaction type identifiers. 1131

7.3.5.3.2 Business transaction ID 1132

BusinessTransactionID is a vocabulary whose elements denote specific business transactions. 1133

An example is an identifier that denotes “Acme Corp purchase order number 12345678.” 1134

BusinessTransactionID is a User Vocabulary as defined in Section 6.2. 1135

Non-Normative: Explanation: URIs are used to provide extensibility and a convenient way 1136

for organisations to distinguish one kind of transaction identifier from another. For example, if 1137

Acme Corporation has purchase orders (one kind of business transaction) identified with an 8-1138

digit number as well as shipments (another kind of business transaction) identified by a 6-1139

character string, and furthermore the PostHaste Shipping Company uses 12-digit tracking 1140

IDs, then the following business transaction IDs might be associated with a particular EPC 1141

over time: 1142

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

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

1144

urn:posthaste:tracking:123456789012

1145

(In this example, it is assumed that PostHaste Shipping has registered the URN namespace 1146

“posthaste” with IANA.) An EPCIS Accessing Application might query EPCIS and discover all 1147

three of the transaction IDs; using URIs gives the application a way to understand which ID is 1148

of interest to it. 1149

7.3.5.4 Source and destination 1150

A Source or Destination is used to provide additional business context when an EPCIS event is 1151

part of a business transfer; that is, a process in which there is a transfer of ownership, 1152

responsibility, and/or custody of physical or digital objects. 1153

In many cases, a business transfer requires several individual business steps (and therefore several 1154

EPCIS events) to execute; for example, shipping followed by receiving, or a more complex sequence 1155

such as loading  departing  transporting  arriving  unloading  accepting. The ReadPoint 1156

and

BusinessLocation in the “where” dimension of these EPCIS events indicate the known 1157

physical location at each step of the process.

Source and Destination, in contrast, may be used 1158

to indicate the parties and/or location that are the intended endpoints of the business transfer. In a 1159

multi-step business transfer, some or all of the EPCIS events may carry Source and Destination, 1160

and the information would be the same for all events in a given transfer. 1161

Source and Destination provide a standardised way to indicate the parties and/or physical 1162

locations involved in the transfer, complementing the business transaction information (e.g., 1163

purchase orders, invoices, etc.) that may be referred to by BusinssTransaction elements. 1164

A source or destination is described in EPCIS by a structured type consisting of a pair of identifiers, 1165

as follows. 1166

Field Type Description

type SourceDestTypeID

An identifier that indicates what kind of source or destination this

Source or

Destination

(respectively) denotes.

source

destination

SourceDestID

An identifier that denotes a specific source or destination.

1167

EPC Information Services (EPCIS) Standard

The two vocabulary types SourceDestTypeID, and SourceDestID are defined in the sections 1168

below. 1169

7.3.5.4.1 Source/Destination type 1170

SourceDestTypeID is a vocabulary whose elements denote a specific type of business transfer 1171

source or destination. An example is an identifier that denotes “owning party.”

SourceDestTypeID 1172

is an example of a Standard Vocabulary as defined in Section 6.2

. 1173

Non-Normative: Explanation: Using an extensible vocabulary for source/destination type 1174

identifiers allows GS1 standards to define some common terms such as “owning party” while 1175

allowing for industry groups and individual end-users to define their own terms. Master data 1176

may provide additional information. 1177

This specification defines no master data attributes for source/destination type identifiers. 1178

7.3.5.4.2 Source/Destination ID 1179

SourceDestID is a vocabulary whose elements denote specific sources and destinations. An 1180

example is an identifier that denotes “Acme Corporation (an owning party).”

SourceDestID is a 1181

User Vocabulary as defined in Section 6.2. 1182

Non-Normative: Explanation: URIs are used to provide extensibility and a convenient way 1183

for organisations to distinguish one kind of source or destination identifier from another. 1184

7.3.6 Instance/Lot master data (ILMD) 1185

Instance/Lot master data (ILMD) is data that describes a specific instance of a physical or digital 1186

object, or a specific batch/lot of objects that are produced in batches/lots. ILMD consists of a set of 1187

descriptive attributes that provide information about one or more specific objects or lots. It is similar 1188

to ordinary master data, which also consists of a set of descriptive attributes that provide 1189

information about objects. But whereas master data attributes have the same values for a large 1190

class of objects, (e.g., for all objects having a given GTIN), the values of ILMD attributes may be 1191

different for much smaller groupings of objects (e.g., a single batch or lot), and may be different for 1192

each object (i.e., different for each instance). 1193

An example of a master data attribute is the weight and physical dimensions of trade items 1194

identified by a specific GTIN. These values are the same for all items sharing that GTIN. An example 1195

of ILMD is the expiration date of a perishable trade item. Unlike master data, the expiration date is 1196

not the same for all trade items having the same GTIN; in principle, each may have a different 1197

expiration date depending on when it is manufactured. Other examples of ILMD include date of 1198

manufacture, place of manufacture, weight and other physical dimensions of a variable-measure 1199

trade item, harvest information for farm products, and so on. 1200

ILMD, like ordinary master data, is intended to be static over the life of the object. For example, the 1201

expiration date of a perishable trade item or the weight of a variable-measure item does not change 1202

over the life of the trade item, even though different trade items having the same GTIN may have 1203

different values for expiration date and weight. ILMD is not to be used to represent information that 1204

changes over the life of an object, for example, the current temperature of an object as it moves 1205

through the supply chain. 1206

While there exist standards (such as GDSN) for the registration and dissemination of ordinary 1207

master data through the supply chain, standards and systems for dissemination of ILMD do not yet 1208

exist. For this reason, EPCIS allows ILMD to be carried directly in certain EPCIS events. This feature 1209

should only be used when no separate system exists for dissemination of ILMD. 1210

ILMD for a specific object is defined when the object comes into existence. Therefore, ILMD may 1211

only be included in

ObjectEvents with action ADD (Section 7.4.1.2), and in 1212

TransformationEvents (Section 7.4.6). In the case of a TransformationEvent, ILMD applies 1213

to the outputs of the transformation, not to the inputs. 1214

EPC Information Services (EPCIS) Standard

The structure of ILMD defined in this EPCIS standard consists of a set of named attributes, with 1215

values of any type. In the XML binding (Section 9.5

), the XML schema provides for an unbounded 1216

list of XML elements having any element name and content. Other documents layered on top of 1217

EPCIS may define specific ILMD data elements; see Section

6.3. In this way, ILMD is similar to 1218

event-level EPCIS extensions, but is separate in order to emphasise that ILMD applies for the entire 1219

life of objects, whereas an event-level EPCIS extension only applies to that specific event. 1220

7.4 Core event types module – events 1221

7.4.1 EPCISEvent 1222

EPCISEvent is a common base type for all EPCIS events. All of the more specific event types in the 1223

following sections are subclasses of

EPCISEvent. 1224

This common base type only has the following fields. 1225

Field Type Description

eventTime Time

The date and time at which the EPCIS Capturing Applications

asserts the event occurred.

recordTime Time

(Optional) The date and time at which this event was recorded

by an EPCIS Repository. This field SHALL be ignored when an

event is presented to the EPCIS Capture Interface, and SHALL

be present when an event is retrieved through the EPCIS Query

Interfaces. The

recordTime does not describe anything about

the real-world event, but is rather a bookkeeping mechanism

that plays a role in the interpretation of standing queries as

specified in Section 8.2.5.2

eventTimeZoneOffset

String

The time zone offset in effect at the time and place the event

occurred, expressed as an offset from UTC. The value of this

field SHALL be a string consisting of the character ‘

+’ or the

character ‘

-’, followed by two digits whose value is within the

range

00 through 14 (inclusive), followed by a colon character

‘

:’, followed by two digits whose value is within the range 00

through

59 (inclusive), except that if the value of the first two

digits is

14, the value of the second two digits must be 00.

For example, the value

+05:30 specifies that where the event

occurred, local time was five hours and 30 minutes later than

UTC (that is, midnight UTC was 5:30am local time).

eventID EventID

(Optional) An identifier for this event as specified by the

capturing application, globally unique across all events other

than error declarations. “Globally unique” means different from

the

eventID on any other EPCIS event across any

implementation of EPCIS, not merely across the events captured

by a single capturing application or by a single capture server.

(The Core Business Vocabulary standard [CBV1.2] specifies the

use of a UUID URI for this purpose.)

Note that in the case of an error declaration, the event ID will

be equal to the event ID of the erroneous event (or null if the

event ID of the erroneous event is null), and in that sense is not

unique. See Section 7.4.1.2

errorDeclaration ErrorDeclaration

(Optional) If present, indicates that this event serves to assert

that the assertions made by a prior event are in error. See

Section 7.4.1.2

7.4.1.1 Explanation of eventTimeZoneOffset (Non-Normative) 1226

The eventTimeZoneOffset field is not necessary to understand at what moment in time an event 1227

occurred. This is because the

eventTime field is of type Time, defined in Section 7.3 to be a “date 1228

and time in a time zone-independent manner.” For example, in the XML binding (Section

9.5) the 1229

eventTime field is represented as an element of type xsd:dateTime, and Section 9.5 further 1230

EPC Information Services (EPCIS) Standard

stipulates that the XML must include a time zone specifier. Therefore, the XML for eventTime 1231

unambiguously identifies a moment in absolute time, and it is not necessary to consult 1232

eventTimeZoneOffset to understand what moment in time that is. 1233

The purpose of

eventTimeZoneOffset is to provide additional business context about the event, 1234

namely to identify what time zone offset was in effect at the time and place the event was captured. 1235

This information may be useful, for example, to determine whether an event took place during 1236

business hours, to present the event to a human in a format consistent with local time, and so on. 1237

The local time zone offset information is not necessarily available from

eventTime, because there is 1238

no requirement that the time zone specifier in the XML representation of

eventTime be the local 1239

time zone offset where the event was captured. For example, an event taking place at 8:00am US 1240

Eastern Standard Time could have an XML eventTime field that is written 08:00-05:00 (using US 1241

Eastern Standard Time), or

13:00Z (using UTC), or even 07:00-06:00 (using US Central Standard 1242

Time). Moreover, XML processors are not required by [XSD2] to retain and present to applications 1243

the time zone specifier that was part of the xsd:dateTime field, and so the time zone specifier in 1244

the

eventTime field might not be available to applications at all. Similar considerations would apply 1245

for other (non-XML) bindings of the Core Event Types module. For example, a hypothetical binary 1246

binding might represent Time values as a millisecond offset relative to midnight UTC on January 1, 1247

1970 – again, unambiguously identifying a moment in absolute time, but not providing any 1248

information about the local time zone. For these reasons,

eventTimeZoneOffset is provided as an 1249

additional event field. 1250

7.4.1.2 ErrorDeclaration 1251

When an event contains an ErrorDeclaration element, it indicates that this event has special 1252

semantics: instead of the normal semantics which assert that various things happened and that 1253

various things are true following the event, the semantics of this event assert that those prior 1254

assertions are in error. An event containing an ErrorDeclaration element SHALL be otherwise 1255

identical to a prior event, “otherwise identical” meaning that all fields of the event other than the 1256

ErrorDeclaration element and the value of recordTime are exactly equal to the prior event. (Note 1257

that includes the

eventID field: the eventID of the error declaration will be equal to the eventID 1258

of the prior event or null if the

eventID of the prior event is null. This is the sole case where the 1259

same non-null

eventID may appear in two events.) The semantics of an event containing the 1260

ErrorDeclaration element are that all assertions implied by the prior event are considered to be 1261

erroneous, as of the specified declarationTime. The prior event is not modified in any way, and 1262

subsequent queries will return both the prior event and the error declaration. 1263

An ErrorDeclaration element contains the following fields: 1264

Field Type Description

declarationTime Timestamp

The date and time at which the declaration of error is made.

(Note that the eventTime of this event must match the

eventTime of the prior event being declared erroneous, so the

declarationTime field is required to indicate the time at

which this event is asserted.)

reason ErrorReasonID

(Optional) An element from a standard vocabulary that

specifies the reason the prior event is considered erroneous.

correctiveEventIDs List<EventID>

(Optional) If present, indicates that the events having the

specified URIs as the value of their eventID fields are to be

considered as “corrections” to the event declared erroneous

by this event. This provides a means to link an error

declaration event to one or more events that are intended to

replace the erroneous event.

1265

An ErrorDeclaration element SHOULD NOT be used if there is a way to model the real-world 1266

situation as an ordinary event (that is, using an event that does not contain an ErrorDeclaration 1267

element). 1268

EPC Information Services (EPCIS) Standard

7.4.1.3 Use of error declarations (Non-Normative) 1269

An EPCIS event records the completion of a step of a business process. A business process is 1270

modeled by breaking it down into a series of steps, and modeling each as an EPCIS event. The net 1271

effect is that the collection of all events pertaining to a specific object (often referred to as a “trace”) 1272

should correctly indicate the history and current state of that object, by interpreting the events 1273

according to the semantics specified in this standard and relevant vocabulary standards. 1274

Sometimes, it is discovered that an event recorded earlier does not accurately reflect what 1275

happened in the real world. In such cases, as noted in Section 6.1

, earlier events are never deleted 1276

or modified. Instead, additional events are recorded whose effect is that the complete trace 1277

(including the new events and all prior events including the incorrect event) accurately reflects the 1278

history and current state, as stated in the above principle. 1279

The preferred way to arrive at the additional events is to recognise that the discovery of an 1280

erroneous event and its remediation is itself a business process which can be modeled by creating 1281

suitable EPCIS events. In most situations, this is done using EPCIS events from the Core Event 1282

Types Module as specified in Sections 7.4.1 through 7.4.6

, using suitable vocabulary. 1283

Example 1: Company X records an EPCIS event asserting that serial numbers 101, 102, and 103 of 1284

some product were shipped to Company Y. Company Y receives the shipment and finds serial 1285

number 104 in addition to serial numbers 101, 102, 103. In discussion with Company X, it is agreed 1286

that serial 104 was indeed shipped and that the shipping event was in error. Remediation: Company 1287

X records a new EPCIS event asserting that serial number 104 was shipped, with similar contextual 1288

information as the original event. 1289

Example 2: Company X records an EPCIS event asserting that serial numbers 101, 102, and 103 of 1290

some product were shipped to Company Y. Company Y receives the shipment and finds only serial 1291

numbers 101, 102. In discussion with Company X, it is agreed that serial 103 was not shipped but 1292

remains in Company X's inventory. They agree to reverse the billing for the third product. 1293

Remediation: Company X records a new EPCIS event asserting that the shipment of serial 103 is 1294

voided. 1295

In the first example, the additional event uses the same business vocabulary as the first. In the 1296

second example, vocabulary specifically associated with the process of voiding a shipment is used, 1297

but it is still “ordinary” EPCIS semantics in the sense that it models the completion of a well-defined 1298

business process step. This reflects the reality that the act remediation is itself a business process, 1299

and so may be modelled as an EPCIS event. 1300

In some situations, it either is not possible (or is highly undesirable) to remediate the history of an 1301

object by creating a new EPCIS event with ordinary semantics (that is, with the semantics specified 1302

in Sections 7.4.1 through 7.4.6

). 1303

Example 3: Company X records an EPCIS event to assert that serial number 101 of product X was 1304

destroyed. This event is an Object Event as specified in Section 7.4.2

with action = DELETE. Later it 1305

is discovered that serial 101 is still in storage, not destroyed. An ordinary event cannot be used to 1306

amend the history, because the semantics of action DELETE for an Object Event specify that “the 1307

objects … should not appear in subsequent events.” 1308

Example 4: Company X records an EPCIS event asserting that several products have been shipped, 1309

indicating Purchase Order 123 as a business transaction in the “why” dimension. Company Y 1310

receives the products and records a receiving event. Only then it is discovered that the purchase 1311

order reference in the shipping event is wrong: it says PO 456 instead of 123. This could be 1312

remediated using ordinary EPCIS events by Company X recording a “cancel shipment” event 1313

followed by a “shipping” event with the correct PO #. But this is rather undesirable from the 1314

perspective of the overall trace, especially given that there is already a receiving event. 1315

To accommodate such situations, the Core Event Types Module provides a mechanism to assert that 1316

the assertions made by a prior event are in error. These semantics may only be used when an event 1317

specifies exactly the same conditions as a prior ordinary event, so that the assertion of error can be 1318

correlated to the prior event. Such an event is termed an “error declaration event.” 1319

In Example 3 above, the error declaration event would imply that serial number 101 of product X 1320

was not destroyed. In Example 4 above, the error declaration event would imply that a shipment 1321

with PO 123 as the context did not occur, and an additional event (the “corrective event”) would say 1322

that a shipment with PO 456 did occur. This is rather similar to modeling Example 4 using a “cancel 1323

EPC Information Services (EPCIS) Standard

shipment” event, except that instead of asserting a shipment was carried out under PO 123 then 1324

cancelled, the error declaration event simply asserts that the PO 123 assertion was erroneous. 1325

An error declaration event is constructed by including an ErrorDeclaration section. Specifically, 1326

given Event E1, an error declaration event E2 whose effect is to declare the assertions of E1 to be in 1327

error is an event structure whose content is identical to E1, but with the ErrorDeclaration element 1328

included. For example, the error declaration for the "destroying" event in Example 3 is also an 1329

Object Event with action = DELETE, but with the ErrorDeclaration element included. In general, 1330

to declare event E to be in error, a new event is recorded that is identical to event E except that the 1331

ErrorDeclaration element is also included (and the record time will be different). 1332

There are three reasons why error declaration events in EPCIS are expressed this way. One, an 1333

event ID is not required to indicate the erroneous event, which in turn implies it is not necessary to 1334

include an event ID on every event to provide for possible error declaration in the future. Event IDs 1335

are available to link an error declaration event to a corrective event, but it is never necessary to use 1336

event IDs. Two, any EPCIS query that matches an event will also match an error declaration for that 1337

event, if it exists. This means that EPCIS Accessing Applications require no special logic to become 1338

aware of error declarations, if they exist. Three, if an EPCIS Accessing Application receives an error 1339

declaration event and for some reason does not have a copy of the original (erroneous) event, it is 1340

not necessary to retrieve the original event as every bit of information in that event is also present 1341

in the error declaration event. 1342

7.4.1.4 Matching an error declaration to the original event (non-normative) 1343

As discussed in Section 7.4.1.2

, an error declaration event has identical content to the original 1344

(erroneous) event, with the exception of the

ErrorDeclaration element itself and the record 1345

time. One of the benefits of this approach is that when an EPCIS Accessing Application encounters 1346

an error declaration, it is not necessary to retrieve the original (erroneous) event, as all of the 1347

information in that event is also present in the error declaration event which the EPCIS Accessing 1348

Application already has. 1349

Nevertheless, there may be situations in which an EPCIS Accessing Application or EPCIS Capturing 1350

Application wishes to confirm the existence of the original (erroneous) event by querying for it. The 1351

only way to recognise that an event is the original event matching an error declaration is to confirm 1352

that all data elements in the events (save the

ErrorDeclaration element and record time) 1353

match. See [EPCISGuideline] for suggested approaches for querying in this situation. 1354

7.4.2 ObjectEvent (subclass of EPCISEvent) 1355

ObjectEvent captures information about an event pertaining to one or more physical or digital 1356

objects identified by instance-level (EPC) or class-level (EPC Class) identifiers. Most ObjectEvents 1357

are envisioned to represent actual observations of objects, but strictly speaking it can be used for 1358

any event a Capturing Application wants to assert about objects, including for example capturing the 1359

fact that an expected observation failed to occur. 1360

While more than one EPC and/or EPC Class may appear in an

ObjectEvent, no relationship or 1361

association between those objects is implied other than the coincidence of having experienced 1362

identical events in the real world. 1363

The

Action field of an ObjectEvent describes the event’s relationship to the lifecycle of the 1364

objects and their identifiers named in the event. Specifically: 1365

Action

value

Meaning

ADD

The objects identified in the event have been commissioned as part of this event. For objects identified

by EPCs (instance-level identifiers), the EPC(s) have been issued and associated with an object (s) for

the first time. For objects identified by EPC Classes (class-level identifiers), the specified quantities of

EPC Classes identified in the event have been created (though other instances of those same classes

may have existed prior this event, and additional instances may be created subsequent to this event).

OBSERVE

The event represents a simple observation of the objects identified in the event, not their

commissioning or decommissioning.

EPC Information Services (EPCIS) Standard

Action

value

Meaning

DELETE

The objects identified in the event have been decommissioned as part of this event. For objects

identified by EPCs (instance-level identifiers), the EPC(s) do not exist subsequent to the event and

should not be observed again. For objects identified by EPC Classes (class-level identifiers), the

specified quantities of EPC Classes identified in the event have ceased to exist (though other instances

of those same classes may continue to exist subsequent to this event, and additional instances may be

have ceased to exist prior this event).

1366

Fields: 1367

Field Type Description

eventTime

recordTime

eventTimeZoneOffset

(Inherited from EPCISEvent; see Section 7.4.1)

epcList List<EPC>

(Optional) An unordered list of one or more EPCs

naming specific objects to which the event pertained.

See Section 7.3.3.2

An ObjectEvent SHALL contain either a non-empty

epcList

, a non-empty

quantityList

, or both.

quantityList List<QuantityElement>

(Optional) An unordered list of one or more

QuantityElements identifying (at the class level)

objects to which the event pertained.

An ObjectEvent SHALL contain either a non-empty

epcList

, a non-empty

quantityList

, or both.

action Action

How this event relates to the lifecycle of the EPCs

named in this event. See above for more detail.

bizStep BusinessStepID

(Optional) The business step of which this event was

a part.

disposition DispositionID

(Optional) The business condition of the objects

associated with the EPCs, presumed to hold true until

contradicted by a subsequent event.

readPoint ReadPointID

(Optional) The read point at which the event took

place.

bizLocation BusinessLocationID

(Optional) The business location where the objects

associated with the EPCs may be found, until

contradicted by a subsequent event.

bizTransactionList

Unordered list of zero or more

BusinessTransaction

instances

(Optional) An unordered list of business transactions

that define the context of this event.

sourceList List<Source>

(Optional) An unordered list of Source elements

(Section 7.3.5.4

) that provide context about the

originating endpoint of a business transfer of which

this event is a part.

destinationList List<Destination>

(Optional) An unordered list of Destination

elements (Section 7.3.5.4

) that provide context about

the terminating endpoint of a business transfer of

which this event is a part.

ilmd ILMD

(Optional) Instance/Lot master data (Section 7.3.6)

that describes the objects created during this event.

An ObjectEvent SHALL NOT contain ilmd if

action

OBSERVE

DELETE.

Note that in the XML binding (Section 9.3), quantityList, sourceList, destinationList, 1368

and

ilmd appear in the standard extension area, to maintain forward-compatibility with EPCIS 1.0. 1369

Retrospective semantics: 1370

EPC Information Services (EPCIS) Standard

■ An event described by bizStep (and any other fields) took place with respect to the objects 1371

identified by

epcList and quantityList at eventTime at location readPoint. 1372

■ (If

action is ADD) The EPCs in epcList were commissioned (issued for the first time). 1373

■ (If action is ADD) The specified quantities of EPC Class instances in quantityList were 1374

created (or an unknown quantity, for each

QuantityElement in which the quantity value is 1375

omitted). 1376

■ (If

action is DELETE) The EPCs in epcList were decommissioned (retired from future use). 1377

■ (If

action is DELETE) The specified quantities of EPC Class instances in quantityList ceased 1378

to exist (or an unknown quantity, for each

QuantityElement in which the quantity value is 1379

omitted). 1380

■ (If

action is ADD and a non-empty bizTransactionList is specified) An association exists 1381

between the business transactions enumerated in

bizTransactionList and the objects 1382

identified in

epcList and quantityList. 1383

■ (If

action is OBSERVE and a non-empty bizTransactionList is specified) This event took 1384

place within the context of the business transactions enumerated in

bizTransactionList. 1385

■ (If

action is DELETE and a non-empty bizTransactionList is specified) This event took 1386

place within the context of the business transactions enumerated in

bizTransactionList. 1387

■ (If

sourceList is non-empty) This event took place within the context of a business transfer 1388

whose originating endpoint is described by the sources enumerated in

sourceList. 1389

■ (If destinationList is non-empty) This event took place within the context of a business 1390

transfer whose terminating endpoint is described by the destinations enumerated in 1391

destinationList. 1392

Prospective semantics: 1393

■ (If

action is ADD) The objects identified by the instance-level identifiers in epcList may 1394

appear in subsequent events. 1395

■ (If

action is ADD) The objects identified by the class-level identifiers in quantityList may 1396

appear in subsequent events. 1397

■ (If

action is DELETE) The objects identified by the instance-level identifiers in epcList should 1398

not appear in subsequent events. 1399

■ (If

action is DELETE) The total population of objects identified by the class-level identifiers in 1400

quantityList that may appear in subsequent events has been reduced by the quantities 1401

specified in

quantityList (or by an unknown quantity, for each QuantityElement in which 1402

the

quantity value is omitted). 1403

■ (If disposition is specified) The business condition of the objects identified by epcList and 1404

quantityList is as described by disposition. 1405

■ (If disposition is omitted) The business condition of the objects associated with identified by 1406

epcList and quantityList is unchanged. 1407

■ (If

bizLocation is specified) The objects identified by epcList and quantityList are at 1408

business location

bizLocation. 1409

■ (If bizLocation is omitted) The business location of the objects identified by epcList and 1410

quantityList is unknown. 1411

■ (If action is ADD and ilmd is non-empty) The objects identified by epcList and 1412

quantityList are described by the attributes in ilmd. 1413

■ (If action is ADD and a non-empty bizTransactionList is specified) An association exists 1414

between the business transactions enumerated in

bizTransactionList and the objects 1415

identified in epcListand quantityList. 1416

EPC Information Services (EPCIS) Standard

Non-Normative: Explanation: In the case where action is ADD and a non-empty 1417

bizTransactionList is specified, the semantic effect is equivalent to having an 1418

ObjectEvent with no

bizTransactionList together with a TransactionEvent having the 1419

bizTransactionList and all the same field values as the ObjectEvent. Note, however, that 1420

an ObjectEvent with a non-empty

bizTransactionList does not cause a TransactionEvent 1421

to be returned from a query. 1422

7.4.3 AggregationEvent (subclass of EPCISEvent) 1423

The event type AggregationEvent describes events that apply to objects that have been 1424

aggregated to one another. In such an event, there is a set of “contained” objects that have been 1425

aggregated within a “containing” entity that’s meant to identify the aggregation itself. 1426

This event type is intended to be used for “aggregations,” meaning an association where there is a 1427

strong physical relationship between the containing and the contained objects such that they will all 1428

occupy the same location at the same time, until such time as they are disaggregated. An example 1429

of an aggregation is where cases are loaded onto a pallet and carried as a unit. The 1430

AggregationEvent type is not intended for weaker associations such as two pallets that are part 1431

of the same shipment, but where the pallets might not always be in exactly the same place at the 1432

same time. (The TransactionEvent may be appropriate for such circumstances.) More specific 1433

semantics may be specified depending on the Business Step. 1434

The

Action field of an AggregationEvent describes the event’s relationship to the lifecycle of the 1435

aggregation. Specifically: 1436

Action

value

Meaning

ADD

The objects identified in the child list have been aggregated to the parent during this event. This

includes situations where the aggregation is created for the first time, as well as when new children are

added to an existing aggregate.

OBSERVE

The event represents neither adding nor removing children from the aggregation. The observation may

be incomplete: there may be children that are part of the aggregation but not observed during this

event and therefore not included in the

childEPCs or childQuantityList field of the

AggregationEvent; likewise, the parent identity may not be observed or known during this event

and therefore the

parentID

field be omitted from the

AggregationEvent

DELETE

The objects identified in the child list have been disaggregated from the parent during this event. This

includes situations where a subset of children are removed from the aggregation, as well as when the

entire aggregation is dismantled. Both

childEPCs and childQuantityList field may be omitted

from the

AggregationEvent, which means that all children have been disaggregated. (This permits

disaggregation when the event capture software does not know the identities of all the children.)

1437

The

AggregationEvent type includes fields that refer to a single “parent” (often a “containing” 1438

entity) and one or more “children” (often “contained” objects). A parent identifier is required when 1439

action is ADD or DELETE, but optional when action is OBSERVE. 1440

Non-Normative: Explanation: A parent identifier is used when

action is ADD so that there 1441

is a way of referring to the association in subsequent events when

action is DELETE. The 1442

parent identifier is optional when

action is OBSERVE because the parent is not always 1443

known during an intermediate observation. For example, a pallet receiving process may rely 1444

on RFID tags to determine the EPCs of cases on the pallet, but there might not be an RFID 1445

tag for the pallet (or if there is one, it may be unreadable). 1446

The AggregationEvent is intended to indicate aggregations among objects, and so the children are 1447

identified by EPCs and/or EPC classes. The parent entity, however, is not necessarily a physical or 1448

digital object separate from the aggregation itself, and so the parent is identified by an arbitrary 1449

URI, which MAY be an EPC, but MAY be another identifier drawn from a suitable private vocabulary. 1450

Non-Normative: Explanation: In many manufacturing operations, for example, it is common 1451

to create a load several steps before an EPC for the load is assigned. In such situations, an 1452

EPC Information Services (EPCIS) Standard

internal tracking number (often referred to as a “license plate number,” or LPN) is assigned at 1453

the time the load is created, and this is used up to the point of shipment. At the point of 1454

shipment, an SSCC code (which is an EPC) is assigned. In EPCIS, this would be modelled by 1455

(a) an

AggregateEvent with action equal to ADD at the time the load is created, and (b) a 1456

second

AggregationEvent with action equal to ADD at the time the SSCC is assigned (the 1457

first association may also be invalidated via a

AggregationEvent with action equal to 1458

DELETE at this time). The first AggregationEvent would use the LPN as the parent 1459

identifier (expressed in a suitable URI representation; see Section 6.4), while the second 1460

AggregationEvent would use the SSCC (which is a type of EPC) as the parent identifier, 1461

thereby changing the parentID. 1462

An AggregationEvent has the following fields: 1463

Field Type Description

eventTime

recordTime

eventTimeZoneOffset

(Inherited from EPCISEvent; see Section 7.4.1)

parentID URI

(Optional when action is OBSERVE, required

otherwise) The identifier of the parent of the

association. When the parent identifier is an EPC,

this field SHALL contain the “pure identity” URI for

the EPC as specified in [TDS1.9], Section 7.

childEPCs List<EPC>

(Optional) An unordered list of the EPCs of

contained objects identified by instance-level

identifiers. See Section 7.3.3.2

An AggregationEvent SHALL contain either a non-

empty

childEPCs, a non-empty

childQuantityList, or both, except that both

childEPCs and childQuantityList MAY be

empty if action is

DELETE, indicating that all

children are disaggregated from the parent.

childQuantityList List<QuantityElement>

(Optional) An unordered list of one or more

QuantityElements identifying (at the class level)

contained objects. See Section 7.3.3.2

An AggregationEvent SHALL contain either a non-

empty

childEPCs, a non-empty

childQuantityList, or both, except that both

childEPCs and childQuantityList MAY be

empty if action is

DELETE, indicating that all

children are disaggregated from the parent.

action Action

How this event relates to the lifecycle of the

aggregation named in this event. See above for

more detail.

bizStep BusinessStepID

(Optional) The business step of which this event was

a part.

disposition DispositionID

(Optional) The business condition of the objects

associated with the EPCs, presumed to hold true

until contradicted by a subsequent event.

readPoint ReadPointID

(Optional) The read point at which the event took

place.

bizLocation BusinessLocationID

(Optional) The business location where the objects

associated with the containing and contained EPCs

may be found, until contradicted by a subsequent

event.

bizTransactionList

Unordered list of zero or more

BusinessTransaction

instances

(Optional) An unordered list of business transactions

that define the context of this event.

EPC Information Services (EPCIS) Standard

Field Type Description

sourceList List<Source>

(Optional) An unordered list of Source elements

(Section 7.3.5.4

) that provide context about the

originating endpoint of a business transfer of which

this event is a part.

destinationList List<Destination>

(Optional) An unordered list of Destination

elements (Section 7.3.5.4

) that provide context

about the terminating endpoint of a business

transfer of which this event is a part.

Note that in the XML binding (Section 9.3), childQuantityList, sourceList, and 1464

destinationList appear in the standard extension area, to maintain forward-compatibility with 1465

EPCIS 1.0. 1466

Retrospective semantics: 1467

■ An event described by

bizStep (and any other fields) took place involving containing entity 1468

parentID and the contained objects in childEPCs and childQuantityList, at eventTime 1469

and location

readPoint. 1470

■ (If action is

ADD) The objects identified in childEPCs and childQuantityList were 1471

aggregated to containing entity

parentID. 1472

■ (If action is DELETE and childEPCs or childQuantityList is non-empty) The objects 1473

identified in

childEPCs and childQuantityList were disaggregated from parentID. 1474

■ (If action is DELETE and both childEPCs and childQuantityList are empty) All contained 1475

objects have been disaggregated from containing entity

parentID. 1476

■ (If action is ADD and a non-empty bizTransactionList is specified) An association exists 1477

between the business transactions enumerated in

bizTransactionList, the objects identified 1478

childEPCs and childQuantityList, and containing entity parentID. 1479

■ (If action is OBSERVE and a non-empty bizTransactionList is specified) This event took 1480

place within the context of the business transactions enumerated in

bizTransactionList. 1481

■ (If action is DELETE and a non-empty bizTransactionList is specified) This event took 1482

place within the context of the business transactions enumerated in

bizTransactionList. 1483

■ (If sourceList is non-empty) This event took place within the context of a business transfer 1484

whose originating endpoint is described by the sources enumerated in

sourceList. 1485

■ (If destinationList is non-empty) This event took place within the context of a business 1486

transfer whose terminating endpoint is described by the destinations enumerated in 1487

destinationList. 1488

Prospective semantics: 1489

■ (If

action is ADD) An aggregation exists between containing entity parentID and the 1490

contained objects in

childEPCs and childQuantityList. 1491

■ (If action is DELETE and childEPCs or childQuantityList is non-empty) An aggregation 1492

no longer exists between containing entity

parentID and the contained objects identified in 1493

childEPCs and childQuantityList. 1494

■ (If action is DELETE and both childEPCs and childQuantityList are empty) An 1495

aggregation no longer exists between containing entity

parentID and any contained objects. 1496

■ (If disposition is specified) The business condition of the objects associated with the objects 1497

identified in

parentID, childEPCs, and childQuantityList is as described by 1498

disposition. 1499

■ (If

disposition is omitted) The business condition of the objects associated with the objects 1500

parentID, childEPCs, and childQuantityList is unchanged. 1501

EPC Information Services (EPCIS) Standard

■ (If bizLocation is specified) The objects associated with the objects in parentID, 1502

childEPCs, and childQuantityList are at business location bizLocation. 1503

■ (If

bizLocation is omitted) The business location of the objects associated with the objects in 1504

parentID, childEPCs, and childQuantityList is unknown. 1505

(If

action is ADD and a non-empty bizTransactionList is specified) An association exists 1506

between the business transactions enumerated in

bizTransactionList, the objects in 1507

childEPCs and childQuantityList, and containing entity parentID (if specified). 1508

Non-Normative: Explanation: In the case where action is ADD and a non-empty 1509

bizTransactionList is specified, the semantic effect is equivalent to having an 1510

AggregationEvent with no

bizTransactionList together with a TransactionEvent having 1511

the

bizTransactionList and all same field values as the AggregationEvent. Note, 1512

however, that an AggregationEvent with a non-empty

bizTransactionList does not cause 1513

a TransactionEvent to be returned from a query. 1514

Non-Normative: Note: Many semantically invalid situations can be expressed with incorrect 1515

use of aggregation. For example, the same objects may be given multiple parents during the 1516

same time period by distinct ADD operations without an intervening Delete. Similarly an 1517

object can be specified to be a child of its grand-parent or even of itself. A non-existent 1518

aggregation may be DELETED. These situations cannot be detected syntactically and in 1519

general an individual EPCIS repository may not have sufficient information to detect them. 1520

Thus this specification does not address these error conditions. 1521

7.4.4 QuantityEvent (subclass of EPCISEvent) – DEPRECATED 1522

QuantityEvent captures an event that takes place with respect to a specified quantity of an 1523

object class. This Event Type may be used, for example, to report inventory levels of a product. 1524

As of EPCIS 1.1, the

QuantityEvent is deprecated. Applications should instead use an 1525

ObjectEvent containing one or more QuantityListElements. A QuantityEvent is equivalent 1526

to an

ObjectEvent containing an empty EPCList and a single QuantityListElement containing a 1527

quantity and without a uom. 1528

Field Type Description

eventTime

recordTime

eventTimeZoneOffset

(Inherited from EPCISEvent; see Section 7.4.1)

epcClass EPCClass

The identifier specifying the object class to which the

event pertains.

quantity Int

The quantity of object within the class described by

this event.

bizStep BusinessStepID

(Optional) The business step of which this event was a

part.

disposition DispositionID

(Optional) The business condition of the objects

associated with the EPCs, presumed to hold true until

contradicted by a subsequent event.

readPoint ReadPointID

(Optional) The read point at which the event took

place.

bizLocation BusinessLocationID

(Optional) The business location where the objects may

be found, until contradicted by a subsequent event.

bizTransactionList

Unordered list of zero or more

BusinessTransaction

instances

(Optional) An unordered list of business transactions

that define the context of this event.

1529

EPC Information Services (EPCIS) Standard

Note that because an EPCClass always denotes a specific packaging unit (e.g., a 12-item case), 1530

there is no need for an explicit “unit of measure” field. The unit of measure is always the object 1531

class denoted by epcClass as defined in master data for that object class. 1532

Retrospective semantics: 1533

■ An event described by

bizStep (and any other fields) took place with respect to quantity 1534

objects of EPC class

epcClass at eventTime at location readPoint. 1535

■ (If a non-empty

bizTransactionList is specified) This event took place within the context of 1536

the business transactions enumerated in

bizTransactionList. 1537

Prospective semantics: . 1538

■ (If

disposition is specified) The business condition of the objects is as described by 1539

disposition. 1540

■ (If

disposition is omitted) The business condition of the objects is unchanged. 1541

■ (If bizLocation is specified) The objects are at business location bizLocation. 1542

■ (If bizLocation is omitted) The business location of the objects is unknown. 1543

7.4.5 TransactionEvent (subclass of EPCISEvent) 1544

The event type TransactionEvent describes the association or disassociation of physical or digital 1545

objects to one or more business transactions. While other event types have an optional 1546

bizTransactionList field that may be used to provide context for an event, the 1547

TransactionEvent is used to declare in an unequivocal way that certain objects have been 1548

associated or disassociated with one or more business transactions as part of the event. 1549

The

action field of a TransactionEvent describes the event’s relationship to the lifecycle of the 1550

transaction. Specifically: 1551

Action

value

Meaning

ADD

The objects identified in the event have been associated to the business transaction(s) during this event.

This includes situations where the transaction(s) is created for the first time, as well as when new objects

are added to an existing transaction(s).

OBSERVE

The objects named in the event have been confirmed as continuing to be associated to the business

transaction(s) during this event.

Explanation (non-normative): A

TransactionEvent with action OBSERVE is quite similar to an

ObjectEvent that includes a non-empty bizTransactionList field. When an end user group agrees

to use both kinds of events, the group should clearly define when each should be used. An example where

TransactionEvent with action OBSERVE might be appropriate is an international shipment with

transaction ID xxx moving through a port, and there’s a desire to record the EPCs that were observed at

that point in handling that transaction. Subsequent queries will concentrate on querying the transaction ID

to find the EPCs, not on the EPCs to find the transaction ID.

DELETE

The objects named in the event have been disassociated from the business transaction(s) during this

event. This includes situations where a subset of objects are disassociated from the business

transaction(s), as well as when the entire business transaction(s) has ended. As a convenience, both the

list of EPCs and QuantityElements may be omitted from the

TransactionEvent, which means that all

objects have been disassociated.

1552

TransactionEvent has the following fields: 1553

Field Type Description

eventTime

recordTime

eventTimeZoneOffset

(Inherited from EPCISEvent; see Section 7.4.1)

bizTransactionList

Unordered list of one or more

BusinessTransaction

instances

The business transaction(s).

EPC Information Services (EPCIS) Standard

Field Type Description

parentID URI

(Optional) The identifier of the parent of the objects

given in

epcList and quantityList. When the

parent identifier is an EPC, this field SHALL contain

the “pure identity” URI for the EPC as specified in

[TDS1.9], Section 7. See also the note following the

table.

epcList List<EPC>

(Optional) An unordered list of the EPCs of the

objects identified by instance-level identifiers

associated with the business transaction. See

Section 7.3.3.2

A TransactionEvent SHALL contain either a non-empty

epcList, a non-empty quantityList, or both,

except that both

epcList and quantityList MAY

be empty if

action is DELETE, indicating that all the

objects are disassociated from the business

transaction(s).

quantityList List<QuantityElement>

(Optional) An unordered list of one or more

QuantityElements identifying objects (at the class

level) to which the event pertained.

A TransactionEvent SHALL contain either a non-empty

epcList, a non-empty quantityList, or both,

except that both

epcList and quantityList MAY

be empty if

action is DELETE, indicating that all the

objects are disassociated from the business

transaction(s).

action Action

How this event relates to the lifecycle of the business

transaction named in this event. See above for more

detail.

bizStep BusinessStepID

(Optional) The business step of which this event was

a part.

disposition DispositionID

(Optional) The business condition of the objects

associated with the objects, presumed to hold true

until contradicted by a subsequent event.

readPoint ReadPointID

(Optional) The read point at which the event took

place.

bizLocation BusinessLocationID

(Optional) The business location where the objects

associated with the containing and contained objects

may be found, until contradicted by a subsequent

event.

sourceList List<Source>

(Optional) An unordered list of Source elements

(Section 7.3.5.4

) that provide context about the

originating endpoint of a business transfer of which

this event is a part.

destinationList List<Destination>

(Optional) An unordered list of Destination

elements (Section 7.3.5.4

) that provide context about

the terminating endpoint of a business transfer of

which this event is a part.

Note that in the XML binding (Section 9.3), quantityList, sourceList, and destinationList 1554

appear in the standard extension area, to maintain forward-compatibility with EPCIS 1.0. 1555

Non-Normative: Explanation: The use of the field name parentID in both 1556

TransactionEvent and AggregationEvent (Section 7.2.10) does not indicate a similarity 1557

in function or semantics. In general a

TransactionEvent carries the same object 1558

identification information as an

ObjectEvent, that is, a list of EPCs and/or 1559

QuantityElements. All the other information fields (

bizTransactionList, bizStep, 1560

bizLocation, etc) apply equally and uniformly to all objects specified, whether or not the 1561

EPC Information Services (EPCIS) Standard

objects are specified in just the epcList and quantityList field or if the optional 1562

parentID field is also supplied. 1563

Non-Normative: The TransactionEvent provides a way to describe the association or 1564

disassociation of business transactions to objects. The

parentID field in the 1565

TransactionEvent highlights a specific EPC or other identifier as the preferred or primary 1566

object but does not imply a physical relationship of any kind, nor is any kind of nesting or 1567

inheritance implied by the TransactionEvent itself. Only AggregationEvent instances 1568

describe actual parent-child relationships and nestable parent-child relationships. This can be 1569

seen by comparing the semantics of

AggregationEvent in Section 7.2.10 with the 1570

semantics of

TransactionEvent below. 1571

Retrospective semantics: 1572

■ An event described by

bizStep (and any other fields) took place involving the business 1573

transactions enumerated in

bizTransactionList, the objects in epcList and 1574

quantityList, and containing entity parentID (if specified), at eventTime and location 1575

readPoint. 1576

■ (If action is ADD) The objects in epcList and quantityList and containing entity parentID 1577

(if specified) were associated to the business transactions enumerated in 1578

bizTransactionList. 1579

■ (If action is DELETE and epcList or quantityList is non-empty) The objects in epcList, 1580

quantityList, and containing entity parentID (if specified) were disassociated from the 1581

business transactions enumerated in

bizTransactionList. 1582

■ (If action is DELETE, both epcList and quantityList are empty, and parentID is 1583

omitted) All objects have been disassociated from the business transactions enumerated in 1584

bizTransactionList. 1585

■ (If sourceList is non-empty) This event took place within the context of a business transfer 1586

whose originating endpoint is described by the sources enumerated in

sourceList. 1587

■ (If destinationList is non-empty) This event took place within the context of a business 1588

transfer whose terminating endpoint is described by the destinations enumerated in 1589

destinationList. 1590

Prospective semantics: 1591

■ (If action is ADD) An association exists between the business transactions enumerated in 1592

bizTransactionList, the objects in epcList and quantityList, and containing entity 1593

parentID (if specified). 1594

■ (If

action is DELETE and epcList or quantityList is non-empty) An association no longer 1595

exists between the business transactions enumerated in

bizTransactionList, the objects in 1596

epcList and quantityList, and containing entity parentID (if specified). 1597

■ (If

action is DELETE, both epcList and quantityList are empty, and parentID is 1598

omitted) An association no longer exists between the business transactions enumerated in 1599

bizTransactionList and any objects. 1600

■ (If

disposition is specified) The business condition of the objects associated with the objects 1601

epcList and quantityList and containing entity parentID (if specified) is as described 1602

disposition. 1603

■ (If disposition is omitted) The business condition of the objects associated with the objects 1604

epcList and quantityList and containing entity parentID (if specified) is unchanged. 1605

■ (If bizLocation is specified) The objects associated with the objects in epcList, 1606

quantityList, and containing entity parentID (if specified) are at business location 1607

bizLocation. 1608

EPC Information Services (EPCIS) Standard

■ (If bizLocation is omitted) The business location of the objects associated with the objects in 1609

epcList and quantityList and containing entity parentID (if specified) is unknown. 1610

7.4.6 TransformationEvent (subclass of EPCISEvent) 1611

A TransformationEvent captures information about an event in which one or more physical or 1612

digital objects identified by instance-level (EPC) or class-level (EPC Class) identifiers are fully or 1613

partially consumed as inputs and one or more objects identified by instance-level (EPC) or class-1614

level (EPC Class) identifiers are produced as outputs. The

TransformationEvent captures the 1615

relationship between the inputs and the outputs, such that any of the inputs may have contributed 1616

in some way to each of the outputs. 1617

Some transformation business processes take place over a long period of time, and so it is more 1618

appropriate to represent them as a series of EPCIS events. A

TransfomationID may be included 1619

in two or more

TransformationEvents to link them together. When events share an identical 1620

TransformationID, the meaning is that the inputs to any of those events may have contributed in 1621

some way to each of the outputs in any of those same events. 1622

Fields: 1623

Field Type Description

eventTime

recordTime

eventTimeZoneOffset

(Inherited from EPCISEvent; see Section 7.4.1)

inputEPCList List<EPC>

(Optional) An unordered list of one or more EPCs

identifying (at the instance level) objects that

were inputs to the transformation. See

Section 7.3.3.2

See below for constraints on when

inputEPCList

may be omitted.

inputQuantityList List<QuantityElement>

(Optional) An unordered list of one or more

QuantityElements identifying (at the class

level) objects that were inputs to the

transformation.

See below for constraints on when

inputQuantityList

may be omitted.

outputEPCList List<EPC>

(Optional) An unordered list of one or more EPCs

naming (at the instance level) objects that were

outputs from the transformation. See

Section 7.3.3.2

See below for constraints on when

outputEPCList

may be omitted.

outputQuantityList List<QuantityElement>

(Optional) An unordered list of one or more

QuantityElements identifying (at the class

level) objects that were outputs from the

transformation.

See below for constraints on when

outputQuantityList

may be omitted.

transformationID TransformationID

(Optional) A unique identifier that links this event

to other TransformationEvents having an identical

value of

transformationID. When specified,

all inputs to all events sharing the same value of

the

transformationID may contribute to all

outputs of all events sharing that value of

transformationID. If transformationID is

omitted, then the inputs of this event may

contribute to the outputs of this event, but the

inputs and outputs of other events are not

connected to this one.

EPC Information Services (EPCIS) Standard

Field Type Description

bizStep BusinessStepID

(Optional) The business step of which this event

was a part.

disposition DispositionID

(Optional) The business condition of the objects

associated with the output objects, presumed to

hold true until contradicted by a subsequent

event.

readPoint ReadPointID

(Optional) The read point at which the event took

place.

bizLocation BusinessLocationID

(Optional) The business location where the

output objects of this event may be found, until

contradicted by a subsequent event.

bizTransactionList

Unordered list of zero or more

BusinessTransaction

instances

(Optional) An unordered list of business

transactions that define the context of this event.

sourceList List<Source>

(Optional) An unordered list of Source elements

(Section 7.3.5.4

) that provide context about the

originating endpoint of a business transfer of

which this event is a part.

destinationList List<Destination>

(Optional) An unordered list of Destination

elements (Section 7.3.5.4

) that provide context

about the terminating endpoint of a business

transfer of which this event is a part.

ilmd ILMD

(Optional) Instance/Lot master data

(Section 7.3.6

) that describes the output objects

created during this event.

1624

transformationID is omitted, then a TransformationEvent SHALL include at least one input 1625

(i.e., at least one of

inputEPCList and inputQuantityList are non-empty) AND at least one 1626

output (i.e., at least one of

outputEPCList and outputQuantityList are non-empty). If 1627

transformationID is included, then a TransformationEvent SHALL include at least one input 1628

OR at least one output (or both). The latter provides for the possibility that in a transformation 1629

described by several events linked by a common

transformationID, any one event might only 1630

add inputs or extract outputs. 1631

Retrospective semantics: 1632

■ A transformation described by

bizStep (and any other fields) took place with input objects 1633

identified by

inputEPCList and inputQuantityList and output objects identified by 1634

outputEPCList and outputQuantityList, at eventTime at location readPoint. 1635

■ This event took place within the context of the business transactions enumerated in 1636

bizTransactionList. 1637

■ (If

transformationID is omitted) Any of the input objects identified by inputEPCList and 1638

inputQuantityList of this event may have contributed to each of the output objects 1639

identified by

outputEPCList and outputQuantityList of this event. 1640

■ (If transformationID is included) Any of the input objects identified by inputEPCList and 1641

inputQuantityList of this event, together with the input objects identified by 1642

inputEPCList and inputQuantityList of other events having the same value of 1643

transformationID, may have contributed to each of the output objects identified by 1644

outputEPCList and outputQuantityList of this event, as well as to each of the output 1645

objects identified by

outputEPCList and outputQuantityList of other events having the 1646

same value of

transformationID. 1647

■ (If sourceList is non-empty) This event took place within the context of a business transfer 1648

whose originating endpoint is described by the sources enumerated in

sourceList. 1649

EPC Information Services (EPCIS) Standard

■ (If destinationList is non-empty) This event took place within the context of a business 1650

transfer whose terminating endpoint is described by the destinations enumerated in 1651

destinationList. 1652

Prospective semantics: 1653

■ The objects identified by the instance-level identifiers in

outputEPCList may appear in 1654

subsequent events. 1655

■ The objects identified by the class-level identifiers in

outputQuantityList may appear in 1656

subsequent events. 1657

■ (If

disposition is specified) The business condition of the objects identified by 1658

outputEPCList and outputQuantityList is as described by disposition. 1659

■ (If disposition is omitted) The business condition of the objects associated with identified by 1660

outputEPCList and outputQuantityList is unknown. 1661

■ (If bizLocation is specified) The objects identified by outputEPCList and 1662

outputQuantityList are at business location bizLocation. 1663

■ (If bizLocation is omitted) The business location of the objects identified by outputEPCList 1664

and

outputQuantityList is unknown. 1665

■ (If ilmd is non-empty) The objects identified by outputEPCList and outputQuantityList 1666

are described by the attributes in

ilmd. 1667

8 Service layer 1668

This Section includes normative specifications of modules in the Service Layer. Together, these 1669

modules define three interfaces: the EPCIS Capture Interface, the EPCIS Query Control Interface, 1670

and the EPCIS Query Callback Interface. (The latter two interfaces are referred to collectively as the 1671

EPCIS Query Interfaces.) The diagram below illustrates the relationship between these interfaces, 1672

expanding upon the diagram in Section 2

(this diagram is non-normative): 1673

EPC Information Services (EPCIS) Standard

1674

In the subsections below, services are specified using UML class diagram notation. UML class 1675

diagrams used for this purpose may contain interfaces having operations, but not fields or 1676

associations. Here is an example: 1677

1678

This diagram shows a service definition for

Service1, which provides three operations. 1679

Operation1 takes two arguments, arg11 and arg12, having types ArgType11 and ArgType12, 1680

respectively, and returns a value of type ReturnType1. Operation2 takes one argument but does 1681

not return a result. Operation3 does not take any arguments but returns a value of type 1682

ReturnType3. 1683

Within the UML descriptions, the notation <<

extension point>> identifies a place where 1684

implementations SHALL provide for extensibility through the addition of new operations. 1685

Extensibility mechanisms SHALL provide for both proprietary extensions by vendors of EPCIS-1686

compliant products, and for extensions defined by GS1 through future versions of this specification 1687

or through new specifications. 1688

EPCIS Capture Interface

EPCIS

Repository

EPCIS Capturing Application

EPCIS Query

Callback Interface

Control

(Manage subscriptions

to scheduled queries)

Possible

bypass for

real-

time

“push”

EPCIS Query Control

Interface

Consume Immediate Data

(Accept immediate data

response & exceptions)

Consume Scheduled Data

(Accept callback data

response & exceptions)

EPCIS

Accessing Application

EPCIS

Accessing Application

Request/response

(Synchronous in web

services binding, two

coupled one-way

One-way

<<interface>>

Service1

operation1(arg11 : ArgType11, arg12 : ArgType12) : ReturnType1

operation2(arg21 : ArgType21) : void

operation3() : ReturnType3

EPC Information Services (EPCIS) Standard

In the case of the standard WSDL bindings, the extension points are implemented simply by 1689

permitting the addition of additional operations. 1690

8.1 Core capture operations module 1691

The Core Capture Operations Module provides operations by which core events may be delivered 1692

from an EPCIS Capture Application. Within this section, the word “client” refers to an EPCIS Capture 1693

Application and “EPCIS Service” refers to a system that implements the EPCIS Capture Interface. 1694

8.1.1 Authentication and authorisation 1695

Some bindings of the EPCIS Capture Interface provide a means for the EPCIS Service to 1696

authenticate the client’s identity, for the client to authenticate the EPCIS Service’s identity, or both. 1697

The specification of the means to authenticate is included in the specification of each binding. If the 1698

EPCIS Service authenticates the identity of the client, an implementation MAY use the client identity 1699

to make authorisation decisions as described below. Moreover, an implementation MAY record the 1700

client identity with the captured data, for use in subsequent authorisation decisions by the system 1701

implementing the EPCIS Query Interfaces, as described in Section 8.2.2

. 1702

Because of the simplicity of the EPCIS Capture Interface, the authorisation provisions are very 1703

simple to state: namely, an implementation MAY use the authenticated client identity to decide 1704

whether a capture operation is permitted or not. 1705

Non-Normative: Explanation: It is expected that trading partners will always use bindings 1706

that provide for client identity authentication or mutual authentication when using EPCIS 1707

interfaces to share data across organisational boundaries. The bindings that do not offer 1708

authentication are expected to be used only within a single organisation in situations where 1709

authentication is not required to meet internal security requirements. 1710

8.1.2 Capture service 1711

1712

The capture interface contains only a single method,

capture, which takes a single argument and 1713

returns no results. Implementations of the EPCIS Capture Interface SHALL accept each element of 1714

the argument list that is a valid

EPCISEvent or subtype thereof according to this specification. 1715

Implementations MAY accept other types of events through vendor extension. The simplicity of this 1716

interface admits a wide variety of bindings, including simple message-queue type bindings. 1717

Non-Normative: Explanation: “Message-queue type bindings” means the following. 1718

Enterprises commonly use “message bus” technology for interconnection of different 1719

distributed system components. A message bus provides a reliable channel for in-order 1720

delivery of messages from a sender to a receiver. (The relationship between sender and 1721

receiver may be point-to-point (a message “queue”) or one-to-many via a publish/subscribe 1722

mechanism (a message “topic”).) A “message-queue type binding” of the EPCIS Capture 1723

Interface would simply be the designation of a particular message bus channel for the 1724

purpose of delivering EPCIS events from an EPCIS Capture Application to an EPCIS 1725

Repository, or to an EPCIS Accessing Application by way of the EPCIS Query Callback 1726

Interface. Each message would have a payload containing one or more EPCIS events 1727

(serialised through some binding at the Data Definition Layer; e.g., an XML binding). In such 1728

a binding, therefore, each transmission/delivery of a message corresponds to a single 1729

“capture” operation. 1730

The

capture operation records one or more EPCIS events, of any type. 1731

<<interface>>

CoreCaptureService

capture(event : List<EPCISEvent>) : void

<<extension point>>

EPC Information Services (EPCIS) Standard

Arguments: 1732

Argument Type Description

event

List of EPCISEvent The event(s) to capture. All relevant information such as the event time, EPCs,

etc., are contained within each event. Exception: the

recordTime MAY be

omitted. Whether the

recordTime is omitted or not in the input, following the

capture operation the

recordTime of the event as recorded by the EPCIS

Repository or EPCIS Accessing Application is the time of capture. Note that the

optional

eventID is not treated like recordTime; like any other EPCIS field,

eventID shall be captured without modification by the capture interface.

Explanation (non-normative): this treatment of

recordTime is necessary in

order for standing queries to be processed properly. See Section 8.2.5.2

1733

Return value: 1734

(none) 1735

The concrete bindings of the EPCIS Capture Interface in Section 10

use the EPCIS document 1736

structure defined in Section

9.5 to carry the list of EPCIS events to be captured. An EPCIS document 1737

may contain master data in the document header. An implementation of the EPCIS Capture 1738

Interface conforming to this standard MAY choose to record that master data or MAY choose to 1739

ignore it – the disposition of master data received through the EPCIS Capture Interface is not 1740

specified by the EPCIS standard. Likewise, a system that implements the EPCIS Capture Interface 1741

may provide a means to capture master data by receiving an EPCIS master data document 1742

(Section

9.7) but the EPCIS standard does not require this to be supported. 1743

On the other hand, any instance/lot master data carried in the ILMD section of an event SHALL be 1744

captured as part of the event, as is true for any data element within an EPCIS event. Such master 1745

data SHALL be queryable by using the query parameters of the SimpleEventQuery specified in 1746

Section 8.2.7.1

, but there is no requirement for an implementation to make master data in the ILMD 1747

section of an event available for query using the SimpleMasterDataQuery specified in 1748

Section 8.2.7.2. 1749

An implementation of the capture interface SHALL either capture all events specified in a given 1750

capture operation or fail to capture all events in that operation. That is, an implementation SHALL 1751

NOT have the possibility of partial success where some events in the list are captured and others 1752

are not. 1753

The reasons why a capture operation fails are implementation-specific. Examples of possible reasons 1754

a failure may occur include: 1755

■ The input to the capture operation is not well formed or does not conform to the syntactic 1756

requirements of the concrete binding being used, including schema-validity for concrete bindings 1757

that use the XML schemas defined in Section 9. 1758

■ The client is not authorized to perform the capture operation. 1759

■ Implementation-specific limits regarding the number of events in a single capture operation, the 1760

total number of events stored, the frequency of capture, etc., are exceeded. 1761

■ Implementation-specific rules regarding the content of events, either in isolation or with 1762

reference to previously captured events, are violated. Note that such rules may be appropriate 1763

in a closed system where the use of EPCIS is governed by a specific application standard, but 1764

may not be appropriate in an open system designed to handle any EPCIS data. Rules of this kind 1765

may limit interoperability if they are too narrow. 1766

■ A temporary failure, such as the temporary unavailability of a server or network. 1767

8.2 Core Query operations module 1768

The Core Query Operations Module provides two interfaces, called the EPCIS Query Control 1769

Interface and the EPCIS Query Callback Interface, by which EPCIS data can be retrieved by an 1770

EPCIS Accessing Application. The EPCIS Query Control Interface defines a means for EPCIS 1771

Accessing Applications and trading partners to obtain EPCIS data subsequent to capture from any 1772

source, typically by interacting with an EPCIS Repository. It provides a means for an EPCIS 1773

EPC Information Services (EPCIS) Standard

Accessing Application to retrieve data on-demand, and also enter subscriptions for standing queries. 1774

Results of standing queries are delivered to EPCIS Accessing Applications via the EPCIS Query 1775

Callback Interface. Within this section, the word “client” refers to an EPCIS Accessing Application 1776

and “EPCIS Service” refers to a system that implements the EPCIS Query Control Interface, and in 1777

addition delivers information to a client via the EPCIS Query Callback Interface. 1778

8.2.1 Authentication 1779

Some bindings of the EPCIS Query Control Interface provide a means for the EPCIS Service to 1780

authenticate the client’s identity, for the client to authenticate the EPCIS Service’s identity, or both. 1781

The specification of the means to authenticate is included in the specification of each binding. If the 1782

EPCIS Service authenticates the identity of the client, an implementation MAY use the client identity 1783

to make authorisation decisions as described in the next section. 1784

Non-Normative: Explanation: It is expected that trading partners will always use bindings 1785

that provide for client identity authentication or mutual authentication when using EPCIS 1786

interfaces to share data across organisational boundaries. The bindings that do not offer 1787

authentication are expected to be used only within a single organisation in situations where 1788

authentication is not required to meet internal security requirements. 1789

8.2.2 Authorisation 1790

An EPCIS service may wish to provide access to only a subset of information, depending on the 1791

identity of the requesting client. This situation commonly arises in cross-enterprise scenarios where 1792

the requesting client belongs to a different organisation than the operator of an EPCIS service, but 1793

may also arise in intra-enterprise scenarios. 1794

Given an EPCIS query, an EPCIS service MAY take any of the following actions in processing the 1795

query, based on the authenticated identity of the client: 1796

■ The service MAY refuse to honour the request altogether, by responding with a 1797

SecurityException as defined below. 1798

■ The service MAY respond with less data than requested. For example, if a client presents a 1799

query requesting all

ObjectEvent instances within a specified time interval, the service knows 1800

of 100 matching events, the service may choose to respond with fewer than 100 events (e.g., 1801

returning only those events whose EPCs are SGTINs with a company prefix known to be 1802

assigned to the client). 1803

■ The service MAY respond with coarser grained information. In particular, when the response to a 1804

query includes a location type (as defined in Section 7.3.4

), the service may substitute an 1805

aggregate location in place of a primitive location. 1806

■ The service MAY hide information. For example, if a client presents a query requesting 1807

ObjectEvent instances, the service may choose to delete the bizTransactionList fields in 1808

its response. The information returned, however, SHALL be well-formed EPCIS events consistent 1809

with this specification and industry guidelines. In addition, if hiding information would otherwise 1810

result in ambiguous, or misleading information, then the entire event SHOULD be withheld. This 1811

applies whether the original information was captured through the EPCIS Capture Interface or 1812

provided by some other means. For example, given an AggregationEvent with action equal to 1813

ADD, an attempt to hide the

parentID field would result in a non-well-formed event, because 1814

parentID is required when the action is ADD; in this instance, therefore, the entire event 1815

would have to be withheld. 1816

■ The service MAY limit the scope of the query to data that was originally captured by a particular 1817

client identity. This allows a single EPCIS service to be “partitioned” for use by groups of 1818

unrelated users whose data should be kept separate. 1819

An EPCIS implementation is free to determine which if any of these actions to take in processing any 1820

query, using any means it chooses. The specification of authorisation rules is outside the scope of 1821

this specification. 1822

EPC Information Services (EPCIS) Standard

Non-Normative: Explanation: Because the EPCIS specification is concerned with the query 1823

interfaces as opposed to any particular implementation, the EPCIS specification does not take 1824

a position as to how authorisation decisions are taken. Particular implementations of EPCIS 1825

may have arbitrarily complex business rules for authorisation. That said, the EPCIS 1826

specification may contain standard data that is needed for authorisation, whether exclusively 1827

for that purpose or not. 1828

8.2.3 Queries for large amounts of data 1829

Many of the query operations defined below allow a client to make a request for a potentially 1830

unlimited amount of data. For example, the response to a query that asks for all

ObjectEvent 1831

instances within a given interval of time could conceivably return one, a thousand, a million, or a 1832

billion events depending on the time interval and how many events had been captured. This may 1833

present performance problems for service implementations. 1834

To mitigate this problem, an EPCIS service MAY reject any request by raising a

QueryTooLarge 1835

exception. This exception indicates that the amount of data being requested is larger than the 1836

service is willing to provide to the client. The

QueryTooLarge exception is a hint to the client that 1837

the client might succeed by narrowing the scope of the original query, or by presenting the query at 1838

a different time (e.g., if the service accepts or rejects queries based on the current computational 1839

load on the service). 1840

Non-Normative: Roadmap: It is expected that future versions of this specification will 1841

provide more sophisticated ways to deal with the large query problem, such as paging, 1842

cursoring, etc. Nothing more complicated was agreed to in this version for the sake of 1843

expedience. 1844

8.2.4 Overly complex queries 1845

EPCIS service implementations may wish to restrict the kinds of queries that can be processed, to 1846

avoid processing queries that will consume more resources than the service is willing to expend. For 1847

example, a query that is looking for events having a specific value in a particular event field may 1848

require more or fewer resources to process depending on whether the implementation anticipated 1849

searching on that field (e.g., depending on whether or not a database column corresponding to that 1850

field is indexed). As with queries for too much data (Section 8.2.3

), this may present performance 1851

problems for service implementations. 1852

To mitigate this problem, an EPCIS service MAY reject any request by raising a QueryTooComplex 1853

exception. This exception indicates that structure of the query is such that the service is unwilling to 1854

carry it out for the client. Unlike the QueryTooLarge exception (Section 8.2.3), the 1855

QueryTooComplex indicates that merely narrowing the scope of the query (e.g., by asking for one 1856

week’s worth of events instead of one month’s) is unlikely to make the query succeed. 1857

A particular query language may specify conditions under which an EPCIS service is not permitted to 1858

reject a query with a

QueryTooComplex exception. This provides a minimum level of 1859

interoperability. 1860

8.2.5 Query framework (EPCIS query control interface) 1861

The EPCIS Query Control Interface provides a general framework by which client applications may 1862

query EPCIS data. The interface provides both on-demand queries, in which an explicit request from 1863

a client causes a query to be executed and results returned in response, and standing queries, in 1864

which a client registers ongoing interest in a query and thereafter receives periodic delivery of 1865

results via the EPCIS Query Callback Interface without making further requests. These two modes 1866

are informally referred to as “pull” and “push,” respectively. 1867

The EPCIS Query Control Interface is defined below. An implementation of the Query Control 1868

Interface SHALL implement all of the methods defined below. 1869

EPC Information Services (EPCIS) Standard

<<interface>> 1870

EPCISQueryControlInterface 1871

--- 1872

subscribe(queryName : String, params : QueryParams, dest : URI, controls : 1873

SubscriptionControls, subscriptionID : String) 1874

unsubscribe(subscriptionID : String) 1875

poll(queryName : String, params : QueryParams) : QueryResults 1876

getQueryNames() : List // of names 1877

getSubscriptionIDs(queryName : String) : List // of Strings 1878

getStandardVersion() : string 1879

getVendorVersion() : string 1880

<<extension point>> 1881

Standing queries are made by making one or more subscriptions to a previously defined query using 1882

the

subscribe method. Results will be delivered periodically via the Query Callback Interface to a 1883

specified destination, until the subscription is cancelled using the

unsubscribe method. On-1884

demand queries are made by executing a previously defined query using the

poll method. Each 1885

invocation of the

poll method returns a result directly to the caller. In either case, if the query is 1886

parameterised, specific settings for the parameters may be provided as arguments to

subscribe or 1887

poll. 1888

An implementation MAY provide one or more “pre-defined” queries. A pre-defined query is available 1889

for use by

subscribe or poll, and is returned in the list of query names returned by 1890

getQueryNames, without the client having previously taken any action to define the query. In 1891

particular, EPCIS 1.0 does not support any mechanism by which a client can define a new query, 1892

and so pre-defined queries are the only queries available. See Section 8.2.7

for specific pre-defined 1893

queries that SHALL be provided by an implementation of the EPCIS 1.0 Query Interface. 1894

An implementation MAY permit a given query to be used with poll but not with subscribe. 1895

Generally, queries for event data may be used with both

poll and subscribe, but queries for 1896

master data may be used only with

poll. This is because subscribe establishes a periodic 1897

schedule for running a query multiple times, each time restricting attention to new events recorded 1898

since the last time the query was run. This mechanism cannot apply to queries for master data, 1899

because master data is presumed to be quasi-static and does not have anything corresponding to a 1900

record time. 1901

The specification of these methods is as follows: 1902

Method Description

Registers a subscriber for a previously defined query having the specified name. The params

argument provides the values to be used for any named parameters defined by the query.

The dest parameter specifies a destination where results from the query are to be

delivered, via the Query Callback Interface. The dest parameter is a URI that both identifies

a specific binding of the Query Callback Interface to use and specifies addressing

information. The

controls parameter controls how the subscription is to be processed; in

particular, it specifies the conditions under which the query is to be invoked (e.g., specifying

a periodic schedule). The

subscriptionID is an arbitrary string that is copied into every

response delivered to the specified destination, and otherwise not interpreted by the EPCIS

service. The client may use the

subscriptionID to identify from which subscription a

given result was generated, especially when several subscriptions are made to the same

destination.

The dest argument may be null or empty, in which case the EPCIS implementation SHALL

deliver results to a pre-arranged destination based on the authenticated identity of the

caller; however, if the implementation does not have a destination pre-arranged for the

caller, or does not permit this usage, it SHALL raise an

InvalidURIException

instead.

unsubscribe

Removes a previously registered subscription having the specified

subscriptionID

EPC Information Services (EPCIS) Standard

Method Description

poll

Invokes a previously defined query having the specified name, returning the results. The

params argument provides the values to be used for any named parameters defined by the

query.

getQueryNames

Returns a list of all query names available for use with the subscribe and poll methods.

This includes all pre-defined queries provided by the implementation, including those

specified in Section 8.2.7

getSubscriptionIDs

Returns a list of all

subscriptionID

s currently subscribed to the specified named query.

getStandardVersion

Returns a string that identifies what version of the specification this implementation

complies with. The possible values for this string are defined by GS1. An implementation

SHALL return a string corresponding to a version of this specification to which the

implementation fully complies, and SHOULD return the string corresponding to the latest

version to which it complies. To indicate compliance with this Version 1.2 of the EPCIS

specification, the implementation SHALL return the string

1.2

getVendorVersion

Returns a string that identifies what vendor extensions this implementation provides. The

possible values of this string and their meanings are vendor-defined, except that the empty

string SHALL indicate that the implementation implements only standard functionality with

no vendor extensions. When an implementation chooses to return a non-empty string, the

value returned SHALL be a URI where the vendor is the owning authority. For example, this

may be an HTTP URL whose authority portion is a domain name owned by the vendor, a

URN having a URN namespace identifier issued to the vendor by IANA, an OID URN whose

initial path is a Private Enterprise Number assigned to the vendor, etc.

1903

This framework applies regardless of the content of a query. The detailed contents of a query, and 1904

the results as returned from

poll or delivered to a subscriber via the Query Callback Interface, are 1905

defined in later sections of this document. This structure is designed to facilitate extensibility, as 1906

new types of queries may be specified and fit into this general framework. 1907

An implementation MAY restrict the behaviour of any method according to authorisation decisions 1908

based on the authenticated client identity of the client making the request. For example, an 1909

implementation may limit the IDs returned by

getSubscriptionIDs and recognised by 1910

unsubscribe to just those subscribers that were previously subscribed by the same client identity. 1911

This allows a single EPCIS service to be “partitioned” for use by groups of unrelated users whose 1912

data should be kept separate. 1913

If a pre-defined query defines named parameters, values for those parameters may be supplied 1914

when the query is subsequently referred to using

poll or subscribe. A QueryParams instance is 1915

simply a set of name/value pairs, where the names correspond to parameter names defined by the 1916

query, and the values are the specific values to be used for that invocation of (poll) or subscription 1917

to (

subscribe) the query. If a QueryParams instance includes a name/value pair where the value 1918

is empty, it SHALL be interpreted as though that query parameter were omitted altogether. 1919

The

poll or subscribe method SHALL raise a QueryParameterException under any of the 1920

following circumstances: 1921

■ A parameter required by the specified query was omitted or was supplied with an empty value 1922

■ A parameter was supplied whose name does not correspond to any parameter name defined by 1923

the specified query 1924

■ Two parameters are supplied having the same name 1925

■ Any other constraint imposed by the specified query is violated. Such constraints may include 1926

restrictions on the range of values permitted for a given parameter, requirements that two or 1927

more parameters be mutually exclusive or must be supplied together, and so on. The specific 1928

constraints imposed by a given query are specified in the documentation for that query. 1929

8.2.5.1 Subscription controls 1930

Standing queries are subscribed to via the subscribe method. For each subscription, a 1931

SubscriptionControls instance defines how the query is to be processed. 1932

EPC Information Services (EPCIS) Standard

SubscriptionControls 1933

--- 1934

schedule : QuerySchedule // see Section 8.2.5.3 1935

trigger : URI // specifies a trigger event known by the service 1936

initialRecordTime : Time // see Section 8.2.5.2 1937

reportIfEmpty : boolean 1938

<<extension point>> 1939

The fields of a SubscriptionControls instance are defined below. 1940

Argument Type Description

schedule QuerySchedule

(Optional) Defines the periodic schedule on which the query is to be

executed. See Section 8.2.5.3

. Exactly one of schedule or trigger is

required; if both are specified or both are omitted, the implementation

SHALL raise a

SubscriptionControlsException

trigger URI

(Optional) Specifies a triggering event known to the EPCIS service that

will serve to trigger execution of this query. The

available trigger

URIs are service-dependent. Exactly one of

schedule or trigger is

required; if both are specified or both are omitted, the implementation

SHALL raise a

SubscriptionControlsException

initialRecordTime

Time

(Optional) Specifies a time used to constrain what events are

considered when processing the query when it is executed for the first

time. See Section 8.2.5.2

. If omitted, defaults to the time at which the

subscription is created.

reportIfEmpty boolean

If true, a QueryResults instance is always sent to the subscriber

when the query is executed. If false, a

QueryResults instance is sent

to the subscriber only when the results are non-empty.

1941

8.2.5.2 Automatic limitation based on event record time 1942

Each subscription to a query results in the query being executed many times in succession, the 1943

timing of each execution being controlled by the specified

schedule or being triggered by a 1944

triggering condition specified by

trigger. Having multiple executions of the same query is only 1945

sensible if each execution is limited in scope to new event data generated since the last execution – 1946

otherwise, the same events would be returned more than once. However, the time constraints 1947

cannot be specified explicitly in the query or query parameters, because these do not change from 1948

one execution to the next. 1949

For this reason, an EPCIS service SHALL constrain the scope of each query execution for a 1950

subscribed query in the following manner. The first time the query is executed for a given 1951

subscription, the only events considered are those whose

recordTime field is greater than or equal 1952

initialRecordTime specified when the subscription was created. For each execution of the 1953

query following the first, the only events considered are those whose

recordTime field is greater 1954

than or equal to the time when the query was last executed. It is implementation dependent as to 1955

the extent that failure to deliver query results to the subscriber affects this calculation; 1956

implementations SHOULD make best efforts to insure reliable delivery of query results so that a 1957

subscriber does not miss any data. The query or query parameters may specify additional 1958

constraints upon record time; these are applied after restricting the universe of events as described 1959

above. 1960

Non-Normative: Explanation: one possible implementation of this requirement is that the 1961

EPCIS service maintains a

minRecordTime value for each subscription that exists. The 1962

minRecordTime for a given subscription is initially set to initialRecordTime, and 1963

updated to the current time each time the query is executed for that subscription. Each time 1964

EPC Information Services (EPCIS) Standard

the query is executed, the only events considered are those whose recordTime is greater 1965

than or equal to

minRecordTime for that subscription. 1966

8.2.5.3 Query schedule 1967

A QuerySchedule may be specified to specify a periodic schedule for query execution for a specific 1968

subscription. Each field of

QuerySchedule is a string that specifies a pattern for matching some 1969

part of the current time. The query will be executed each time the current date and time matches 1970

the specification in the QuerySchedule. 1971

Each QuerySchedule field is a string, whose value must conform to the following grammar: 1972

QueryScheduleField ::= Element ( “,” Element )* 1973

1974

Element ::= Number | Range 1975

1976

Range ::= “[“ Number “-“ Number “]” 1977

1978

Number ::= Digit+ 1979

1980

Digit ::= “0” | “1” | “2” | “3” | “4” 1981

| “5” | “6” | “7” | “8” | “9” 1982

Each

Number that is part of the query schedule field value must fall within the legal range for that 1983

field as specified in the table below. An EPCIS implementation SHALL raise a 1984

SubscriptionControlsException if any query schedule field value does not conform to the 1985

grammar above, or contains a Number that falls outside the legal range, or includes a

Range where 1986

the first Number is greater than the second

Number. 1987

The QuerySchedule specifies a periodic sequence of time values (the “query times”). A query time 1988

is any time value that matches the

QuerySchedule, according to the following rule: 1989

■ Given a time value, extract the second, minute, hour (0 through 23, inclusive), dayOfMonth (1 1990

through 31, inclusive), and dayOfWeek (1 through 7, inclusive, denoting Monday through 1991

Sunday). This calculation is to be performed relative to a time zone chosen by the EPCIS 1992

Service. 1993

■ The time value matches the

QuerySchedule if each of the values extracted above matches (as 1994

defined below) the corresponding field of the

QuerySchedule, for all QuerySchedule fields 1995

that are not omitted. 1996

■ A value extracted from the time value matches a field of the

QuerySchedule if it matches any 1997

of the comma-separated Elements of the query schedule field. 1998

■ A value extracted from the time value matches an

Element of a query schedule field if 1999

■ the Element is a Number and the value extracted from the time value is equal to the Number; 2000

or 2001

■ the Element is a

Range and the value extracted from the time value is greater than or equal to 2002

the first Number in the

Range and less than or equal to the second Number in the Range. 2003

See examples following the table below. 2004

An EPCIS implementation SHALL interpret the

QuerySchedule as a client’s statement of when it 2005

would like the query to be executed, and SHOULD make reasonable efforts to adhere to that 2006

schedule. An EPCIS implementation MAY, however, deviate from the requested schedule according 2007

to its own policies regarding server load, authorisation, or any other reason. If an EPCIS 2008

implementation knows, at the time the

subscribe method is called, that it will not be able to 2009

honour the specified

QuerySchedule without deviating widely from the request, the EPCIS 2010

implementation SHOULD raise a

SubscriptionControlsException instead. 2011

Non-Normative: Explanation: The

QuerySchedule, taken literally, specifies the exact 2012

timing of query execution down to the second. In practice, an implementation may not wish 2013

to or may not be able to honour that request precisely, but can honour the general intent. For 2014

EPC Information Services (EPCIS) Standard

example, a QuerySchedule may specify that a query be executed every hour on the hour, 2015

while an implementation may choose to execute the query every hour plus or minus five 2016

minutes from the top of the hour. The paragraph above is intended to give implementations 2017

latitude for this kind of deviation. 2018

In any case, the automatic handling of recordTime as specified earlier SHALL be based on the 2019

actual time the query is executed, whether or not that exactly matches the

QuerySchedule. 2020

The field of a

QuerySchedule instance are as follows. 2021

Argument Type Description

second String

(Optional) Specifies that the query time must have a matching seconds value. The

range for this parameter is 0 through 59, inclusive.

minute String

(Optional) Specifies that the query time must have a matching minute value. The range

for this parameter is 0 through 59, inclusive.

hour String

(Optional) Specifies that the query time must have a matching hour value. The range

for this parameter is 0 through 23, inclusive, with 0 denoting the hour that begins at

midnight, and 23 denoting the hour that ends at midnight.

dayOfMonth String

(Optional) Specifies that the query time must have a matching day of month value. The

range for this parameter is 1 through 31, inclusive. (Values of 29, 30, and 31 will only

match during months that have at least that many days.)

month String

(Optional) Specifies that the query time must have a matching month value. The range

for this parameter is 1 through 12, inclusive.

dayOfWeek String

(Optional) Specifies that the query time must have a matching day of week value. The

range for this parameter is 1 through 7, inclusive, with 1 denoting Monday, 2 denoting

Tuesday, and so forth, up to 7 denoting Sunday.

Explanation (non-normative): this numbering scheme is consistent with ISO-8601.

2022

8.2.5.3.1 Query schedule examples (Non-Normative) 2023

Here are some examples of QuerySchedule and what they mean. 2024

Example 1 2025

QuerySchedule 2026

second = “0” 2027

minute = “0” 2028

all other fields omitted 2029

This means “run the query once per hour, at the top of the hour.” If the reportIfEmpty argument to 2030

subscribe is false, then this does not necessarily cause a report to be sent each hour – a report 2031

would be sent within an hour of any new event data becoming available that matches the query. 2032

Example 2 2033

QuerySchedule 2034

second = “0” 2035

minute = “30” 2036

hour = “2” 2037

all other fields omitted 2038

This means “run the query once per day, at 2:30 am.” 2039

Example 3 2040

QuerySchedule 2041

second = “0” 2042

minute = “0” 2043

dayOfWeek = “[1-5]” 2044

EPC Information Services (EPCIS) Standard

This means “run the query once per hour at the top of the hour, but only on weekdays.” 2045

Example 4 2046

QuerySchedule 2047

hour = “2” 2048

all other fields omitted 2049

This means “run the query once per second between 2:00:00 and 2:59:59 each day.” This example 2050

illustrates that it usually not desirable to omit a field of finer granularity than the fields that are 2051

specified. 2052

8.2.5.4 QueryResults 2053

A QueryResults instance is returned synchronously from the poll method of the EPCIS Query 2054

Control Interface, and also delivered asynchronously to a subscriber of a standing query via the 2055

EPCIS Query Callback Interface. 2056

QueryResults 2057

--- 2058

queryName : string 2059

subscriptionID : string 2060

resultsBody : QueryResultsBody 2061

<<extension point>> 2062

The fields of a QueryResults instance are defined below. 2063

Field Type Description

queryName String

This field SHALL contain the name of the query (the queryName

argument that was specified in the call to

poll

subscriptionID

string

(Conditional) When a QueryResults instance is delivered to a

subscriber as the result of a standing query,

subscriptionID SHALL

contain the same string provided as the

subscriptionID argument

the call to

subscribe.

When a

QueryResults instance is returned as the result of a poll

method, this field SHALL be omitted.

resultsBody QueryResultsBody

The information returned as the result of a query. The exact type of this

field depends on which query is executed. Each of the predefined

queries in Section 8.2.7

specifies the corresponding type for this field.

8.2.6 Error conditions 2064

Methods of the EPCIS Query Control API signal error conditions to the client by means of exceptions. 2065

The following exceptions are defined. All the exception types in the following table are extensions of 2066

a common

EPCISException base type, which contains one required string element giving the 2067

reason for the exception. 2068

Exception Name Meaning

SecurityException

The operation was not permitted due to an access control violation or

other security concern. This includes the case where the service wishes to

deny authorisation to execute a particular operation based on the

authenticated client identity. The specific circumstances that may cause

this exception are implementation-specific, and outside the scope of this

specification.

DuplicateNameException

(Not implemented in EPCIS 1.2)

The specified query name already exists.

EPC Information Services (EPCIS) Standard

Exception Name Meaning

QueryValidationException

(Not implemented in EPCIS 1.2)

The specified query is invalid; e.g., it contains a syntax error.

QueryParameterException

One or more query parameters are invalid, including any of the following

situations:

 the parameter name is not a recognised parameter for the specified

query

 the value of a parameter is of the wrong type or out of range

 two or more query parameters have the same parameter name

QueryTooLargeException

An attempt to execute a query resulted in more data than the service was

willing to provide.

QueryTooComplexException

The specified query parameters, while otherwise valid, implied a query

that was more complex than the service was willing to execute.

InvalidURIException

The URI specified for a subscriber cannot be parsed, does not name a

scheme recognised by the implementation, or violates rules imposed by a

particular scheme.

SubscriptionControlsException

The specified subscription controls was invalid; e.g., the schedule

parameters were out of range, the trigger URI could not be parsed or did

not name a recognised trigger, etc.

NoSuchNameException

The specified query name does not exist.

NoSuchSubscriptionException

The specified

subscriptionID

does not exist.

DuplicateSubscriptionException

The specified subscriptionID is identical to a previous subscription that

was created and not yet unsubscribed.

SubscribeNotPermittedException

The specified query name may not be used with subscribe, only with

poll

ValidationException

The input to the operation was not syntactically valid according to the

syntax defined by the binding. Each binding specifies the particular

circumstances under which this exception is raised.

ImplementationException

A generic exception thrown by the implementation for reasons that are

implementation-specific. This exception contains one additional element: a

severity member whose values are either

ERROR or SEVERE. ERROR

indicates that the EPCIS implementation is left in the same state it had

before the operation was attempted.

SEVERE indicates that the EPCIS

implementation is left in an indeterminate state.

2069

The exceptions that may be thrown by each method of the EPCIS Query Control Interface are 2070

indicated in the table below: 2071

EPCIS Method Exceptions

getQueryNames SecurityException

ValidationException

ImplementationException

subscribe NoSuchNameException

InvalidURIException

DuplicateSubscriptionException

QueryParameterException

QueryTooComplexException

SubscriptionControlsException

SubscribeNotPermittedException

SecurityException

ValidationException

ImplementationException

EPC Information Services (EPCIS) Standard

EPCIS Method Exceptions

unsubscribe NoSuchSubscriptionException

SecurityException

ValidationException

ImplementationException

poll NoSuchNameException

QueryParameterException

QueryTooComplexException

QueryTooLargeException

SecurityException

ValidationException

ImplementationException

getSubscriptionIDs NoSuchNameException

SecurityException

ValidationException

ImplementationException

getStandardVersion SecurityException

ValidationException

ImplementationException

getVendorVersion SecurityException

ValidationException

ImplementationException

2072

In addition to exceptions thrown from methods of the EPCIS Query Control Interface as enumerated 2073

above, an attempt to execute a standing query may result in a

QueryTooLargeException or an 2074

ImplementationException being sent to a subscriber via the EPCIS Query Callback Interface 2075

instead of a normal query result. In this case, the

QueryTooLargeException or 2076

ImplementationException SHALL include, in addition to the reason string, the query name and 2077

the

subscriptionID as specified in the subscribe call that created the standing query. 2078

8.2.7 Predefined queries for EPCIS 2079

In EPCIS, no query language is provided by which a client may express an arbitrary query for data. 2080

Instead, an EPCIS implementation SHALL provide the following predefined queries, which a client 2081

may invoke using the poll and subscribe methods of the EPCIS Query Control Interface. Each 2082

poll or subscribe call may include parameters via the params argument. The predefined queries 2083

defined in this section each have a large number of optional parameters; by appropriate choice of 2084

parameters a client can achieve a variety of effects. 2085

The parameters for each predefined query and what results it returns are specified in this section. 2086

An implementation of EPCIS is free to use any internal representation for data it wishes, and 2087

implement these predefined queries using any database or query technology it chooses, so long as 2088

the results seen by a client are consistent with this specification. 2089

8.2.7.1 SimpleEventQuery 2090

This query is invoked by specifying the string SimpleEventQuery as the queryName argument to 2091

poll or

subscribe. The result is a QueryResults instance whose body contains a (possibly 2092

empty) list of

EPCISEvent instances. Unless constrained by the eventType parameter, each 2093

element of the result list could be of any event type; i.e.,

ObjectEvent, AggregationEvent, 2094

QuantityEvent, TransactionEvent, or any extension event type that is a subclass of 2095

EPCISEvent. 2096

The

SimpleEventQuery SHALL be available via both poll and subscribe; that is, an 2097

implementation SHALL NOT raise

SubscribeNotPermittedException when 2098

SimpleEventQuery is specified as the queryName argument to subscribe. 2099

EPC Information Services (EPCIS) Standard

The SimpleEventQuery is defined to return a set of events that matches the criteria specified in 2100

the query parameters (as specified below). When returning events that were captured via the EPCIS 2101

Capture Interface, each event that is selected to be returned SHALL be identical to the originally 2102

captured event, subject to the provisions of authorisation (Section 8.2.2), the inclusion of the 2103

recordTime field, and any necessary conversions to and from an abstract internal representation. 2104

For any event field defined to hold an unordered list, however, an EPCIS implementation NEED NOT 2105

preserve the order. 2106

The parameters for this query are as follows. None of these parameters is required (though in most 2107

cases, a query will include at least one query parameter). 2108

Parameter name Parameter

value type

Meaning

eventType

List of String If specified, the result will only include events whose type matches one

of the types specified in the parameter value. Each element of the

parameter value may be one of the following strings:

ObjectEvent,

AggregationEvent, QuantityEvent, TransactionEvent, or

TransformationEvent. An element of the parameter value may also

be the name of an extension event type.

If omitted, all event types will be considered for inclusion in the result.

GE_eventTime

Time If specified, only events with eventTime greater than or equal to the

specified value will be included in the result.

If omitted, events are included regardless of their eventTime (unless

constrained by the

LT_eventTime

parameter).

LT_eventTime

Time If specified, only events with eventTime less than the specified value

will be included in the result.

If omitted, events are included regardless of their eventTime (unless

constrained by the

GE_eventTime

parameter).

GE_recordTime

Time If provided, only events with recordTime greater than or equal to the

specified value will be returned. The automatic limitation based on

event record time (Section 8.2.5.2

) may implicitly provide a constraint

similar to this parameter.

If omitted, events are included regardless of their recordTime, other

than automatic limitation based on event record time (Section 8.2.5.2

LT_recordTime

Time If provided, only events with recordTime less than the specified value

will be returned.

If omitted, events are included regardless of their

recordTime (unless

constrained by the GE_

recordTime parameter or the automatic

limitation based on event record time).

EQ_action

List of String If specified, the result will only include events that (a) have an action

field; and where (b) the value of the

action field matches one of the

specified values. The elements of the value of this parameter each must

be one of the strings

ADD, OBSERVE, or DELETE; if not, the

implementation SHALL raise a

QueryParameterException.

If omitted, events are included regardless of their

action

field.

EQ_bizStep

List of String If specified, the result will only include events that (a) have a non-null

bizStep field; and where (b) the value of the bizStep field matches

one of the specified values.

If this parameter is omitted, events are returned regardless of the

value of the

bizStep

field or whether the

bizStep

field exists at all.

EQ_disposition

List of String Like the EQ_

bizStep

parameter, but for the

disposition

field.

EQ_readPoint

List of String If specified, the result will only include events that (a) have a non-null

readPoint field; and where (b) the value of the readPoint field

matches one of the specified values.

If this parameter and WD_readPoint are both omitted, events are

returned regardless of the value of the

readPoint field or whether the

readPoint

field exists at all.

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

WD_readPoint

List of String If specified, the result will only include events that (a) have a non-null

readPoint field; and where (b) the value of the readPoint field

matches one of the specified values, or is a direct or indirect

descendant of one of the specified values. The meaning of “direct or

indirect descendant” is specified by master data, as described in

Section 6.5

. (WD is an abbreviation for “with descendants.”)

If this parameter and EQ_readPoint are both omitted, events are

returned regardless of the value of the

readPoint field or whether the

readPoint

field exists at all.

EQ_bizLocation

List of String Like the

EQ_readPoint

parameter, but for the

bizLocation

field.

WD_bizLocation

List of String Like the WD_

readPoint

parameter, but for the

bizLocation

field.

EQ_bizTransaction_

type

List of String This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only include

events that (a) include a

bizTransactionList; (b) where the

business transaction list includes an entry whose

type subfield is equal

type extracted from the name of this parameter; and (c) where the

bizTransaction subfield of that entry is equal to one of the values

specified in this parameter.

EQ_source_type

List of String This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only include

events that (a) include a

sourceList; (b) where the source list

includes an entry whose

type subfield is equal to type extracted from

the name of this parameter; and (c) where the

source subfield of that

entry is equal to one of the values specified in this parameter.

EQ_destination_type

List of String This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only include

events that (a) include a

destinationList; (b) where the

destination list includes an entry whose type subfield is equal to type

extracted from the name of this parameter; and (c) where the

destination subfield of that entry is equal to one of the values

specified in this parameter.

EQ_transformationID

List of String If this parameter is specified, the result will only include events that (a)

have a

transformationID field (that is, TransformationEvents

or extension event type that extend

TransformationEvent); and

where (b) the

transformationID field is equal to one of the values

specified in this parameter.

MATCH_epc

List of String If this parameter is specified, the result will only include events that (a)

have an

epcList or a childEPCs field (that is, ObjectEvent,

AggregationEvent, TransactionEvent or extension event types

that extend one of those three); and where (b) one of the EPCs listed in

the epcList or

childEPCs field (depending on event type) matches

one of the EPC patterns or URIs specified in this parameter, where the

meaning of “matches” is as specified in Section 8.2.7.1.1

If this parameter is omitted, events are included regardless of their

epcList or childEPCs field or whether the epcList or childEPCs

field exists.

MATCH_parentID

List of String Like MATCH_epc, but matches the parentID field of

AggregationEvent, the parentID field of TransactionEvent, and

extension event types that extend either

AggregationEvent or

TransactionEvent. The meaning of “matches” is as specified in

Section 8.2.7.1.1

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

MATCH_inputEPC

List of String If this parameter is specified, the result will only include events that (a)

have an

inputEPCList (that is, TransformationEvent or an

extension event type that extends

TransformationEvent); and

where (b) one of the EPCs listed in the

inputEPCList field matches

one of the EPC patterns or URIs specified in this parameter. The

meaning of “matches” is as specified in Section 8.2.7.1.1

If this parameter is omitted, events are included regardless of their

inputEPCList

field or whether the

inputEPCList

field exists.

MATCH_outputEPC

List of String If this parameter is specified, the result will only include events that (a)

have an

outputEPCList (that is, TransformationEvent or an

extension event type that extends

TransformationEvent); and

where (b) one of the EPCs listed in the

outputEPCList field matches

one of the EPC patterns or URIs specified in this parameter. The

meaning of “matches” is as specified in Section 8.2.7.1.1

If this parameter is omitted, events are included regardless of their

outputEPCList

field or whether the

outputEPCList

field exists.

MATCH_anyEPC

List of String If this parameter is specified, the result will only include events that (a)

have an

epcList field, a childEPCs field, a parentID field, an

inputEPCList field, or an outputEPCList field (that is,

ObjectEvent, AggregationEvent, TransactionEvent,

TransformationEvent, or extension event types that extend one of

those four); and where (b) the

parentID field or one of the EPCs listed

in the

epcList, childEPCs, inputEPCList, or outputEPCList

field (depending on event type) matches one of the EPC patterns or

URIs specified in this parameter. The meaning of “matches” is as

specified in Section 8.2.7.1.1

MATCH_epcClass

List of String If this parameter is specified, the result will only include events that (a)

have a

quantityList or a childQuantityList field (that is,

ObjectEvent, AggregationEvent, TransactionEvent or

extension event types that extend one of those three); and where (b)

one of the EPC classes listed in the quantityList or

childQuantityList field (depending on event type) matches one of

the EPC patterns or URIs specified in this parameter. The result will also

include

QuantityEvents whose epcClass field matches one of the

EPC patterns or URIs specified in this parameter. The meaning of

“matches” is as specified in Section 8.2.7.1.1

MATCH_inputEPCClass

List of String If this parameter is specified, the result will only include events that (a)

have an

inputQuantityList field (that is, TransformationEvent

or extension event types that extend it); and where (b) one of the EPC

classes listed in the

inputQuantityList field (depending on event

type) matches one of the EPC patterns or URIs specified in this

parameter. The meaning of “matches” is as specified in

Section 8.2.7.1.1

MATCH_outputEPCClass

List of String If this parameter is specified, the result will only include events that (a)

have an

outputQuantityList field (that is,

TransformationEvent or extension event types that extend it); and

where (b) one of the EPC classes listed in the

outputQuantityList

field (depending on event type) matches one of the EPC patterns or

URIs specified in this parameter. The meaning of “matches” is as

specified in Section 8.2.7.1.1

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

MATCH_anyEPCClass

List of String If this parameter is specified, the result will only include events that (a)

have a

quantityList, childQuantityList,

inputQuantityList, or outputQuantityList field (that is,

ObjectEvent, AggregationEvent, TransactionEvent,

TransformationEvent, or extension event types that extend one of

those four); and where (b) one of the EPC classes listed in any of those

fields matches one of the EPC patterns or URIs specified in this

parameter. The result will also include

QuantityEvents whose

epcClass field matches one of the EPC patterns or URIs specified in this

parameter. The meaning of “matches” is as specified in

Section 8.2.7.1.1

EQ_quantity

Int (DEPCRECATED in EPCIS 1.1) If this parameter is specified, the result

will only include events that (a) have a

quantity field (that is,

QuantityEvents or extension event type that extend

QuantityEvent); and where (b) the quantity field is equal to the

specified parameter.

GT_quantity

Int (DEPCRECATED in EPCIS 1.1) Like EQ_quantity, but includes events

whose

quantity

field is greater than the specified parameter.

GE_quantity

Int (DEPCRECATED in EPCIS 1.1) Like EQ_quantity, but includes events

whose

quantity field is greater than or equal to the specified

parameter.

LT_quantity

Int (DEPCRECATED in EPCIS 1.1) Like EQ_quantity, but includes events

whose

quantity

field is less than the specified parameter.

LE_quantity

Int (DEPCRECATED in EPCIS 1.1) Like EQ_quantity, but includes events

whose

quantity

field is less than or equal to the specified parameter.

EQ_fieldname

List of String This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only include

events that (a) have a top-level extension field named

fieldname

whose type is either String or a vocabulary type; and where (b) the

value of that field matches one of the values specified in this

parameter.

Fieldname is the fully qualified name of a top-level extension field. The

name of an extension field is an XML qname; that is, a pair consisting

of an XML namespace URI and a name. The name of the corresponding

query parameter is constructed by concatenating the following: the

string EQ_, the namespace URI for the extension field, a pound sign (#),

and the name of the extension field. “Top level” means that the

matching extension element must be an immediate child of the

containing EPCIS event, not an element nested within a top-level event

extension element. See EQ_INNER_fieldname for querying inner

extension elements.

EQ_fieldname

Int

Float

Time

Like EQ_

fieldname as described above, but may be applied to a field

of type Int, Float, or Time. The result will include events that (a) have a

field named fieldname; and where (b) the type of the field matches

the type of this parameter (Int, Float, or Time); and where (c) the

value of the field is equal to the specified value.

Fieldname is constructed as for EQ_fieldname.

GT_fieldname

Int

Float

Time

Like EQ_fieldname as described above, but may be applied to a field

of type Int, Float, or Time. The result will include events that (a) have a

field named

fieldname; and where (b) the type of the field matches

the type of this parameter (Int, Float, or Time); and where (c) the

value of the field is greater than the specified value.

Fieldname is constructed as for EQ_fieldname.

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

GE_fieldname

LT_fieldname

LE_

fieldname

Int

Float

Time

Analogous to GT_fieldname

EQ_ILMD_fieldname

List of String Analogous to EQ_fieldname, but matches events whose ILMD area

(Section 7.3.6

) contains a top-level field having the specified

fieldname whose value matches one of the specified values. “Top

level” means that the matching ILMD element must be an immediate

child of the <ilmd> element, not an element nested within such an

element. See EQ_INNER_ILMD_fieldname for querying inner extension

elements.

EQ_ILMD_fieldname

GT_ILMD_fieldname

GE_ILMD_fieldname

LT_ILMD_fieldname

LE_ILMD_

fieldname

Int

Float

Time

Analogous to EQ_fieldname, GT_fieldname, GE_fieldname,

GE_fieldname, LT_fieldname, and LE_fieldname, respectively,

but matches events whose ILMD area (Section 7.3.6

) contains a field

having the specified fieldname whose integer, float, or time value

matches the specified value according to the specified relational

operator.

EQ_INNER_fieldname

List of String Analogous to EQ_fieldname, but matches inner extension elements;

that is, any XML element nested at any level within a top-level

extension element. Note that a matching inner element may exist

within more than one top-level element or may occur more than once

within a single top-level element; this parameter matches if at least

one matching occurrence is found anywhere in the event (except at

top-level).

Note that unlike a top-level extension element, an inner extension

element may have a null XML namespace. To match such an inner

element, the empty string is used in place of the XML namespace when

constructing the query parameter name. For example, to match inner

element

<elt1> with no XML namespace, the query parameter would

EQ_INNER_#elt1

EQ_INNER_fieldname

GT_INNER_fieldname

GE_INNER_fieldname

LT_INNER_fieldname

LE_INNER_

fieldname

Int

Float

Time

Like EQ_INNER_fieldname as described above, but may be applied to

a field of type Int, Float, or Time.

EQ_INNER_ILMD_

fieldname

List of String Analogous to EQ_ILMD_fieldname, but matches inner ILMD

elements; that is, any XML element nested at any level within a top-

level ILMD element. Note that a matching inner element may exist

within more than one top-level element or may occur more than once

within a single top-level element; this parameter matches if at least

one matching occurrence is found anywhere in the ILMD section

(except at top-level).

EQ_INNER_ILMD_

fieldname

GT_INNER_

ILMD_fieldname

GE_INNER_

ILMD_fieldname

LT_INNER_

ILMD_fieldname

LE_INNER_

ILMD_

fieldname

Int

Float

Time

EQ_INNER_ILMD_fieldname as described above, but may be

applied to a field of type Int, Float, or Time.

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

EXISTS_fieldname

Void Like EQ_fieldname as described above, but may be applied to a field

of any type (including complex types). The result will include events

that have a non-empty field named

fieldname.

Fieldname is constructed as for EQ_fieldname.

Note that the value for this query parameter is ignored.

EXISTS_INNER_fieldna

Void Like EXISTS_fieldname as described above, but includes events that

have a non-empty inner extension field named

fieldname.

Note that the value for this query parameter is ignored.

EXISTS_

ILMD_fieldname

Void Like EXISTS_fieldname as described above, but events that have a

non-empty field named

fieldname in the ILMD area (Section 7.3.6).

Fieldname is constructed as for EQ_ILMD_fieldname.

Note that the value for this query parameter is ignored.

EXISTS_INNER_ILMD_fi

eldname

Void Like EXISTS_ILMD_fieldname as described above, but includes

events that have a non-empty inner extension field named

fieldname

within the ILMD area.

Note that the value for this query parameter is ignored.

HASATTR_fieldname

List of String This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only include

events that (a) have a field named

fieldname whose type is a

vocabulary type; and (b) where the value of that field is a vocabulary

element for which master data is available; and (c) the master data has

a non-null attribute whose name matches one of the values specified in

this parameter.

Fieldname is the fully qualified name of a field. For a standard field,

this is simply the field name; e.g.,

bizLocation. For an extension

field, the name of an extension field is an XML qname; that is, a pair

consisting of an XML namespace URI and a name. The name of the

corresponding query parameter is constructed by concatenating the

following: the string

HASATTR_, the namespace URI for the extension

field, a pound sign (

), and the name of the extension field.

EQATTR_fieldname

_attrname

List of String This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only include

events that (a) have a field named

fieldname whose type is a

vocabulary type; and (b) where the value of that field is a vocabulary

element for which master data is available; and (c) the master data has

a non-null attribute named

attrname; and (d) where the value of that

attribute matches one of the values specified in this parameter.

Fieldname is constructed as for HASATTR_fieldname.

The implementation MAY raise a

QueryParameterException if

fieldname or attrname includes an underscore character.

Explanation (non-normative): because the presence of an

underscore in fieldname or attrname presents an ambiguity as to where

the division between fieldname and attrname lies, an implementation is

free to reject the query parameter if it cannot disambiguate.

EQ_eventID

List of String If this parameter is specified, the result will only include events that (a)

have a non-null

eventID field; and where (b) the eventID field is

equal to one of the values specified in this parameter.

If this parameter is omitted, events are returned regardless of the

value of the

eventID

field or whether the

eventID

field exists at all.

EXISTS_

errorDeclaration

Void If this parameter is specified, the result will only include events that

contain an

ErrorDeclaration.

If this parameter is omitted, events are returned regardless of whether

they contain an

ErrorDeclaration

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

GE_errorDeclaration

Time

Time If this parameter is specified, the result will only include events that (a)

contain an

ErrorDeclaration; and where (b) the value of the

errorDeclarationTime field is greater than or equal to the specified

value.

If this parameter is omitted, events are returned regardless of whether

they contain an

ErrorDeclaration or what the value of the

errorDeclarationTime

field is.

LT_errorDeclaration

Time

Time If this parameter is specified, the result will only include events that (a)

contain an

ErrorDeclaration; and where (b) the value of the

errorDeclarationTime field is less than to the specified value.

If this parameter is omitted, events are returned regardless of whether

they contain an

ErrorDeclaration or what the value of the

errorDeclarationTime

field is.

EQ_errorReason

List of String If this parameter is specified, the result will only include events that (a)

contain an

ErrorDeclaration; and where (b) the error declaration

contains a non-null

reason field; and where (c) the reason field is

equal to one of the values specified in this parameter.

If this parameter is omitted, events are returned regardless of whether

they contain an

ErrorDeclaration or what the value of the reason

field is.

EQ_correctiveEventID

List of String If this parameter is specified, the result will only include events that (a)

contain an

ErrorDeclaration; and where (b) one of the elements of

the

correctiveEventIDs list is equal to one of the values specified

in this parameter.

If this parameter is omitted, events are returned regardless of whether

they contain an

ErrorDeclaration or the contents of the

correctiveEventIDs

list.

EQ_ERROR_DECLARATION

_fieldname

List of String Analogous to EQ_fieldname, but matches events containing an

ErrorDeclaration and where the ErrorDeclaration contains a

field having the specified

fieldname whose value matches one of the

specified values.

EQ_ERROR_DECLARATION

_fieldname

GT_ERROR_DECLARATION

_fieldname

GE_ERROR_DECLARATION

_fieldname

LT_ERROR_DECLARATION

_fieldname

LE_ERROR_DECLARATION

fieldname

Int

Float

Time

Analogous to EQ_fieldname, GT_fieldname, GE_fieldname,

GE_fieldname, LT_fieldname, and LE_fieldname, respectively,

but matches events containing an

ErrorDeclaration and where the

ErrorDeclaration contains a field having the specified fieldname

whose integer, float, or time value matches the specified value

according to the specified relational operator.

EQ_INNER_ERROR_DECLA

RATION_fieldname

List of String Analogous to EQ_ERROR_DECLARATION_fieldname, but matches

inner extension elements; that is, any XML element nested within a

top-level extension element. Note that a matching inner element may

exist within more than one top-level element or may occur more than

once within a single top-level element; this parameter matches if at

least one matching occurrence is found anywhere in the event (except

at top-level)..

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

EQ_INNER

_ERROR_DECLARATION_f

ieldname

GT_INNER

_ERROR_DECLARATION_f

ieldname

GE_INNER

_ERROR_DECLARATION_f

ieldname

LT_INNER

_ERROR_DECLARATION_f

ieldname

LE_INNER

_ERROR_DECLARATION_f

ieldname

Int

Float

Time

EQ_INNER_ERROR_DECLARATION_fieldname as described

above, but may be applied to a field of type Int, Float, or Time.

EXISTS_ERROR_DECLARA

TION_fieldname

Void Like EXISTS_fieldname as described above, but events that have an

error declaration containing a non-empty extension field named

fieldname.

Fieldname is constructed as for EQ_ERROR_DECLARATION_fieldname.

Note that the value for this query parameter is ignored

EXISTS_INNER_ERROR_D

ECLARATION_fieldname

Void Like EXISTS_ERROR_DECLARATION_fieldname as described above,

but includes events that have an error declaration containing a non-

empty inner extension field named

fieldname.

Note that the value for this query parameter is ignored.

orderBy

String If specified, names a single field that will be used to order the results.

The

orderDirection field specifies whether the ordering is in

ascending sequence or descending sequence. Events included in the

result that lack the specified field altogether may occur in any position

within the result event list.

The value of this parameter SHALL be one of:

eventTime,

recordTime, or the fully qualified name of an extension field whose

type is Int, Float, Time, or String. A fully qualified fieldname is

constructed as for the

EQ_fieldname parameter. In the case of a field

of type String, the ordering SHOULD be in lexicographic order based on

the Unicode encoding of the strings, or in some other collating

sequence appropriate to the locale.

If omitted, no order is specified. The implementation MAY order the

results in any order it chooses, and that order MAY differ even when the

same query is executed twice on the same data.

(In EPCIS 1.0, the value

quantity was also permitted, but its use is

deprecated in EPCIS 1.1.)

orderDirection

String If specified and orderBy is also specified, specifies whether the results

are ordered in ascending or descending sequence according to the key

specified by

orderBy. The value of this parameter must be one of ASC

(for ascending order) or

DESC (for descending order); if not, the

implementation SHALL raise a

QueryParameterException.

If omitted, defaults to

DESC

EPC Information Services (EPCIS) Standard

Parameter name Parameter

value type

Meaning

eventCountLimit

Int If specified, the results will only include the first N events that match

the other criteria, where N is the value of this parameter. The ordering

specified by the orderBy and

orderDirection parameters determine

the meaning of “first” for this purpose.

If omitted, all events matching the specified criteria will be included in

the results.

This parameter and

maxEventCount are mutually exclusive; if both

are specified, a

QueryParameterException SHALL be raised.

This parameter may only be used when

orderBy is specified; if

orderBy is omitted and eventCountLimit is specified, a

QueryParameterException SHALL be raised.

This parameter differs from

maxEventCount in that this parameter

limits the amount of data returned, whereas

maxEventCount causes

an exception to be thrown if the limit is exceeded.

Explanation (non-normative): A common use of the orderBy,

orderDirection, and eventCountLimit parameters is for extremal

queries. For example, to select the most recent event matching some

criteria, the query would include parameters that select events

matching the desired criteria, and set

orderBy to eventTime,

orderDirection

DESC

, and

eventCountLimit

to one.

maxEventCount

Int If specified, at most this many events will be included in the query

result. If the query would otherwise return more than this number of

events, a

QueryTooLargeException SHALL be raised instead of a

normal query result.

This parameter and

eventCountLimit are mutually exclusive; if both

are specified, a

QueryParameterException SHALL be raised.

If this parameter is omitted, any number of events may be included in

the query result. Note, however, that the EPCIS implementation is free

to raise a

QueryTooLargeException regardless of the setting of this

parameter (see Section 8.2.3

2109

As the descriptions above suggest, if multiple parameters are specified an event must satisfy all 2110

criteria in order to be included in the result set. In other words, if each parameter is considered to 2111

be a predicate, all such predicates are implicitly conjoined as though by an AND operator. For 2112

example, if a given call to

poll specifies a value for both the EQ_bizStep and EQ_disposition 2113

parameters, then an event must match one of the specified

bizStep values AND match one of the 2114

specified

disposition values in order to be included in the result. 2115

On the other hand, for those parameters whose value is a list, an event must match at least one of 2116

the elements of the list in order to be included in the result set. In other words, if each element of 2117

the list is considered to be a predicate, all such predicates for a given list are implicitly disjoined as 2118

though by an OR operator. For example, if the value of the

EQ_bizStep parameter is a two 2119

element list (“

bs1”, “bs2”), then an event is included if its bizStep field contains the value bs1 OR 2120

its bizStep field contains the value bs2. 2121

As another example, if the value of the EQ_

bizStep parameter is a two element list (“bs1”, “bs2”) 2122

and the

EQ_disposition parameter is a two element list (“d1”, “d2”), then the effect is to include 2123

events satisfying the following predicate: 2124

((

bizStep = “bs1” OR bizStep = “bs2”) 2125

AND (

disposition = “d1” OR disposition = “d2”)) 2126

8.2.7.1.1 Processing of MATCH query parameters 2127

The parameter list for

MATCH_epc, MATCH_parentID, MATCH_inputEPC, MATCH_outputEPC, 2128

and

MATCH_anyEPC SHALL be processed as follows. Each element of the parameter list may be a 2129

pure identity pattern as specified in [TDS1.9], or any other URI. If the element is a pure identity 2130

EPC Information Services (EPCIS) Standard

pattern, it is matched against event field values using the procedure for matching identity patterns 2131

specified in [TDS1.9, Section 8]. If the element is any other URI, it is matched against event field 2132

values by testing string equality. 2133

The parameter list for MATCH_epcClass, MATCH_inputEPCClass, MATCH_outputEPCClass, and 2134

MATCH_anyEPCClass SHALL be processed as follows. Let P be one of the patterns specified in the 2135

value for this parameter, and let C be the value of an epcClass field in the appropriate quantity list 2136

of an event being considered for inclusion in the result. Then the event is included if each 2137

component Pi of P matches the corresponding component Ci of C, where “matches” is as defined in 2138

[TDS1.9, Section 8]. 2139

Non-Normative: Explanation: The difference between MATCH_epcClass and MATCH_epc, 2140

and similar parameters, is that for MATCH_epcClass the value in the event (the epcClass field 2141

in a quantity list) may itself be a pattern, as specified in Section 7.3.3.3

). This means that the 2142

value in the event may contain a ‘*’ component. The above specification says that a ‘*’ in the 2143

EPCClass field of an event is only matched by a ‘*’ in the query parameter. For example, if the 2144

epcClass field within an event is urn:epc:idpat:sgtin:0614141.112345.*, then this event 2145

would be matched by the query parameter urn:epc:idpat:sgtin:0614141.*.* or by 2146

urn:epc:idpat:sgtin:0614141.112345.*, but not by urn:epc:idpat:sgtin:0614141.112345.400. 2147

8.2.7.2 SimpleMasterDataQuery 2148

This query is invoked by specifying the string

SimpleMasterDataQuery as the queryName 2149

argument to

poll. The result is a QueryResults instance whose body contains a (possibly empty) 2150

list of vocabulary elements together with selected attributes. 2151

The

SimpleMasterDataQuery SHALL be available via poll but not via subscribe; that is, an 2152

implementation SHALL raise

SubscribeNotPermittedException when 2153

SimpleMasterDataQuery is specified as the queryName argument to subscribe. 2154

The parameters for this query are as follows: 2155

Parameter Name Parameter

Value Type

Required Meaning

vocabularyName

List of String No If specified, only vocabulary elements drawn from one of the

specified vocabularies will be included in the results. Each

element of the specified list is the formal URI name for a

vocabulary; e.g., one of the URIs specified in the table at the

end of Section 7.2

If omitted, all vocabularies are considered.

includeAttributes

Boolean Yes If true, the results will include attribute names and values for

matching vocabulary elements. If false, attribute names and

values will not be included in the result.

includeChildren

Boolean Yes If true, the results will include the children list for matching

vocabulary elements. If false, children lists will not be included in

the result.

attributeNames

List of String No If specified, only those attributes whose names match one of the

specified names will be included in the results.

If omitted, all attributes for each matching vocabulary element

will be included. (To obtain a list of vocabulary element names

with no attributes, specify false for

includeAttributes.)

The value of this parameter SHALL be ignored if

includeAttributes is false.

Note that this parameter does not affect which vocabulary

elements are included in the result; it only limits which attributes

will be included with each vocabulary element.

EQ_name

List of String No If specified, the result will only include vocabulary elements

whose names are equal to one of the specified values.

If this parameter and

WD_name are both omitted, vocabulary

elements are included regardless of their names.

EPC Information Services (EPCIS) Standard

Parameter Name Parameter

Value Type

Required Meaning

WD_name

List of String No If specified, the result will only include vocabulary elements that

either match one of the specified names, or are direct or indirect

descendants of a vocabulary element that matches one of the

specified names. The meaning of “direct or indirect descendant”

is described in Section 6.5

. (WD is an abbreviation for “with

descendants.”)

If this parameter and EQ_name are both omitted, vocabulary

elements are included regardless of their names.

HASATTR

List of String No If specified, the result will only include vocabulary elements that

have a non-null attribute whose name matches one of the values

specified in this parameter.

EQATTR_attrname

List of String No This is not a single parameter, but a family of parameters.

If a parameter of this form is specified, the result will only

include vocabulary elements that have a non-null attribute

named

attrname, and where the value of that attribute

matches one of the values specified in this parameter.

maxElementCount

Int No If specified, at most this many vocabulary elements will be

included in the query result. If the query would otherwise return

more than this number of vocabulary elements, a

QueryTooLargeException SHALL be raised instead of a

normal query result.

If this parameter is omitted, any number of vocabulary elements

may be included in the query result. Note, however, that the

EPCIS implementation is free to raise a

QueryTooLargeException regardless of the setting of this

parameter (see Section 8.2.3

2156

As the descriptions above suggest, if multiple parameters are specified a vocabulary element must 2157

satisfy all criteria in order to be included in the result set. In other words, if each parameter is 2158

considered to be a predicate, all such predicates are implicitly conjoined as though by an AND 2159

operator. For example, if a given call to

poll specifies a value for both the WD_name and HASATTR 2160

parameters, then a vocabulary element must be a descendant of the specified element AND possess 2161

one of the specified attributes in order to be included in the result. 2162

On the other hand, for those parameters whose value is a list, a vocabulary element must match at 2163

least one of the elements of the list in order to be included in the result set. In other words, if each 2164

element of the list is considered to be a predicate, all such predicates for a given list are implicitly 2165

disjoined as though by an OR operator. For example, if the value of the EQATTR_sample parameter 2166

is a two element list (“s1”, “s2”), then a vocabulary element is included if it has a sample attribute 2167

whose value is equal to s1 OR equal to s2. 2168

As another example, if the value of the

EQ_name parameter is a two element list (“ve1”, “ve2”) 2169

and the

EQATTR_sample parameter is a two element list (“s1”, “s2”), then the effect is to include 2170

events satisfying the following predicate: 2171

((name = “ve1” OR name = “ve2”) 2172

AND (sample = “s1” OR sample = “s2”)) 2173

where name informally refers to the name of the vocabulary element and sample informally refers 2174

to the value of the sample attribute. 2175

8.2.8 Query callback interface 2176

The Query Callback Interface is the path by which an EPCIS service delivers standing query results 2177

to a client. 2178

EPC Information Services (EPCIS) Standard

<<interface>> 2179

EPCISQueryCallbackInterface 2180

--- 2181

callbackResults(resultData : QueryResults) : void 2182

callbackQueryTooLargeException(e : QueryTooLargeException) : void 2183

callbackImplementationException(e : ImplementationException) : void 2184

Each time the EPCIS service executes a standing query according to the QuerySchedule, it SHALL 2185

attempt to deliver results to the subscriber by invoking one of the three methods of the Query 2186

Callback Interface. If the query executed normally, the EPCIS service SHALL invoke the 2187

callbackResults method. If the query resulted in a QueryTooLargeException or 2188

ImplementationException, the EPCIS service SHALL invoke the corresponding method of the 2189

Query Callback Interface. 2190

Note that “exceptions” in the Query Callback Interface are not exceptions in the usual sense of an 2191

API exception, because they are not raised as a consequence of a client invoking a method. Instead, 2192

the exception is delivered to the recipient in a similar manner to a normal result, as an argument to 2193

an interface method. 2194

9 XML bindings for data definition modules 2195

This section specifies a standard XML binding for the Core Event Types data definition module, using 2196

the W3C XML Schema language [XSD1, XSD2]. Samples are also shown. 2197

The schema below conforms to GS1 standard schema design rules. The schema below imports the 2198

EPCglobal standard base schema, as mandated by the design rules [XMLDR]. 2199

9.1 Extensibility mechanism 2200

The XML schema in this section implements the <<extension point>> given in the UML of 2201

Section 6

using a methodology described in [XMLVersioning]. This methodology provides for both 2202

vendor/user extension, and for extension by GS1 in future versions of this specification or in 2203

supplemental specifications. Extensions introduced through this mechanism will be backward 2204

compatible, in that documents conforming to older versions of the schema will also conform to 2205

newer versions of the standard schema and to schema containing vendor-specific extensions. 2206

Extensions will also be forward compatible, in that documents that contain vendor/user extensions 2207

or that conform to newer versions of the standard schema will also conform to older versions of the 2208

schema. 2209

When a document contains extensions (vendor/user-specific or standardised in newer versions of 2210

schema), it may conform to more than one schema. For example, a document containing vendor 2211

extensions to the GS1 Version 1.0 schema will conform both to the GS1 Version 1.0 schema and to 2212

a vendor-specific schema that includes the vendor extensions. In this example, when the document 2213

is parsed using the standard schema there will be no validation of the extension elements and 2214

attributes, but when the document is parsed using the vendor-specific schema the extensions will be 2215

validated. Similarly, a document containing new features introduced in the GS1 Version 1.2 schema 2216

will conform to the GS1 Version 1.0 schema, the GS1 Version 1.1 schema, and the GS1 Version 1.2 2217

schema, but validation of the new features will only be available using the Version 1.2 schema. 2218

The design rules for this extensibility pattern are given in [XMLVersioning]. In summary, it amounts 2219

to the following rules: 2220

■ For each type in which <<extension point>> occurs, include an xsd:anyAttribute declaration. 2221

This declaration provides for the addition of new XML attributes, either in subsequent versions of 2222

the standard schema or in vendor/user-specific schema. 2223

■ For each type in which <<extension point>> occurs, include an optional (minOccurs = 0) 2224

element named extension. The type declared for the extension element will always be as 2225

follows: 2226

EPC Information Services (EPCIS) Standard

<xsd:sequence> 2227

<xsd:any processContents="lax" minOccurs="1" maxOccurs="unbounded" 2228

namespace="##local"/> 2229

</xsd:sequence> 2230

<xsd:anyAttribute processContents="lax"/> 2231

This declaration provides for forward-compatibility with new elements introduced into 2232

subsequent versions of the standard schema. 2233

■ For each type in which <<extension point>> occurs, include at the end of the element list a 2234

declaration 2235

<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded" 2236

namespace="##other"/> 2237

This declaration provides for forward-compatibility with new elements introduced in 2238

vendor/user-specific schema. 2239

The rules for adding vendor/user-specific extensions to the schema are as follows: 2240

■ Vendor/user-specific attributes may be added to any type in which

<<extension point>> 2241

occurs. Vendor/user-specific attributes SHALL NOT be in the EPCglobal EPCIS namespace 2242

(urn:epcglobal:epcis:xsd:1) nor in the empty namespace. Vendor/user-specific 2243

attributes SHALL be in a namespace whose namespace URI has the vendor as the owning 2244

authority. (In schema parlance, this means that all vendor/user-specific attributes must have 2245

qualified as their form.) For example, the namespace URI may be an HTTP URL whose 2246

authority portion is a domain name owned by the vendor/user, a URN having a URN namespace 2247

identifier issued to the vendor/user by IANA, an OID URN whose initial path is a Private 2248

Enterprise Number assigned to the vendor/user, etc. Declarations of vendor/user-specific 2249

attributes SHALL specify

use="optional". 2250

■ Vendor/user-specific elements may be added to any type in which <<extension point>> 2251

occurs. Vendor/user-specific elements SHALL NOT be in the EPCglobal EPCIS namespace 2252

(urn:epcglobal:epcis:xsd:1) nor in the empty namespace. Vendor/user-specific elements 2253

SHALL be in a namespace whose namespace URI has the vendor/user as the owning authority 2254

(as described above). (In schema parlance, this means that all vendor/user-specific elements 2255

must have qualified as their form.) 2256

To create a schema that contains vendor/user extensions, replace the

<xsd:any … 2257

namespace=”##other”/> declaration with a content group reference to a group defined in the 2258

vendor/user namespace; e.g.,

<xsd:group ref="vendor:VendorExtension">. In the schema 2259

file defining elements for the vendor/user namespace, define a content group using a declaration of 2260

the following form: 2261

<xsd:group name="VendorExtension"> 2262

<xsd:sequence> 2263

<!-- 2264

Definitions or references to vendor elements 2265

go here. Each SHALL specify minOccurs="0". 2266

--> 2267

<xsd:any processContents="lax" 2268

minOccurs="0" maxOccurs="unbounded" 2269

namespace="##other"/> 2270

</xsd:sequence> 2271

</xsd:group> 2272

(In the foregoing illustrations,

vendor and VendorExtension may be any strings the vendor/user 2273

chooses.) 2274

Non-Normative: Explanation: Because vendor/user-specific elements must be optional, 2275

including references to their definitions directly into the EPCIS schema would violate the XML 2276

Schema Unique Particle Attribution constraint, because the

<xsd:any …> element in the 2277

EPCIS schema can also match vendor/user-specific elements. Moving the

<xsd:any …> into 2278

the vendor/user’s schema avoids this problem, because ##other in that schema means 2279

EPC Information Services (EPCIS) Standard

“match an element that has a namespace other than the vendor/user’s namespace.” This 2280

does not conflict with standard elements, because the element form default for the standard 2281

EPCIS schema is unqualified, and hence the ##other in the vendor/user’s schema does not 2282

match standard EPCIS elements, either. 2283

The rules for adding attributes or elements to future versions of the GS1 standard schema are as 2284

follows: 2285

■ Standard attributes may be added to any type in which <<extension point>> occurs. 2286

Standard attributes SHALL NOT be in any namespace (i.e., SHALL be in the empty namespace), 2287

and SHALL NOT conflict with any existing standard attribute name. 2288

■ Standard elements may be added to any type in which

<<extension point>> occurs. New 2289

elements are added using the following rules: 2290

□ Find the innermost

extension element type. 2291

□ Replace the <xsd:any … namespace="##local"/> declaration with (a) new elements 2292

(which SHALL NOT be in any namespace; equivalently, which SHALL be in the empty 2293

namespace); followed by (b) a new extension element whose type is constructed as 2294

described before. In subsequent revisions of the standard schema, new standard elements 2295

will be added within this new

extension element rather than within this one. 2296

Non-Normative: Explanation: the reason that new standard attributes and elements are 2297

specified above not to be in any namespace is to be consistent with the EPCIS schema’s 2298

attribute and element form default of

unqualified. 2299

As applied to the EPCIS 1.2 XML schema for core events (Section 9.5

), this results in the following: 2300

Event types defined in EPCIS 1.0 appear within the <EventList> element. 2301

Event types defined in EPCIS 1.1 (i.e., TransformationEvent) each appear within an

<extension> 2302

element within the

<EventList> element. 2303

For event types defined in EPCIS 1.0, new fields added in EPCIS 1.1 appear within the 2304

<extension> element that follows the EPCIS 1.0 fields. If additional fields are added in the same 2305

place in a future version of EPCIS, they will appear within a second

<extension> element that is 2306

nested within the first

<extension> element, following the EPCIS 1.1 fields. New fields added in 2307

EPCIS 1.2 at a place where no new fields were added in EPCIS 1.1 (i.e., errorDeclaration) appear 2308

within the

<extension> element that follows the EPCIS 1.0 fields. 2309

For event types defined in EPCIS 1.1, there is no

<extension> element as the entire event type is 2310

new in EPCIS 1.1. If additional fields are added in a future version of EPCIS, they will appear within 2311

<extension> element following the fields defined in EPCIS 1.1. 2312

Vendor/user event-level extensions always appear just before the closing tag for the event (i.e., 2313

after any standard fields and any

<extension> element), and are always in a non-empty XML 2314

namespace. Under no circumstances do vendor/user extensions appear within an

<extension> 2315

element; the

<extension> element is reserved for fields defined in the EPCIS standard itself. 2316

See Section 9.6

for examples. 2317

9.2 Standard business document header 2318

The XML binding for the Core Event Types data definition module includes an optional

EPCISHeader 2319

element, which may be used by industry groups to incorporate additional information required for 2320

processing within that industry. The core schema includes a “Standard Business Document Header” 2321

(SBDH) as defined in [SBDH] as a required component of the EPCISHeader element. Industry 2322

groups MAY also require some other kind of header within the

EPCISHeader element in addition to 2323

the SBDH. 2324

The XSD schema for the Standard Business Document Header may be obtained from the 2325

UN/CEFACT website; see [SBDH]. This schema is incorporated herein by reference. 2326

EPC Information Services (EPCIS) Standard

When the Standard Business Document Header is included, the following values SHALL be used for 2327

those elements of the SBDH schema specified below. 2328

SBDH Field (XPath) Value

HeaderVersion

1.0

DocumentIdentification/Standard

EPCglobal

DocumentIdentification/TypeVersion

1.0

DocumentIdentification/Type

As specified below.

2329

The value for

DocumentIdentification/Type SHALL be set according to the following table, 2330

which specifies a value for this field based on the kind of EPCIS document and the context in which 2331

it is used. 2332

Document Type and Context

Value for

DocumentIdentification/Type

EPCISDocument

used in any context

Events

EPCISMasterData

used in any context

MasterData

EPCISQueryDocument used as the request side of the binding

in Section 11.3

QueryControl-Request

EPCISQueryDocument used as the response side of the

binding in Section 11.3

QueryControl-Response

EPCISQueryDocument used in any XML binding of the Query

Callback interface (Sections 11.4.2 – 11.4.4)

QueryCallback

EPCISQueryDocument used in any other context

Query

2333

The AS2 binding for the Query Control Interface (Section 11.3) also specifies additional Standard 2334

Business Document Header fields that must be present in an EPCISQueryDocument instance used as 2335

a Query Control Interface response message. See Section 11.3 for details. 2336

In addition to the fields specified above, the Standard Business Document Header SHALL include all 2337

other fields that are required by the SBDH schema, and MAY include additional SBDH fields. In all 2338

cases, the values for those fields SHALL be set in accordance with [SBDH]. An industry group MAY 2339

specify additional constraints on SBDH contents to be used within that industry group, but such 2340

constraints SHALL be consistent with the specifications herein. 2341

9.3 EPCglobal Base schema 2342

The XML binding for the Core Event Types data definition module, as well as other XML bindings in 2343

this specification, make reference to the EPCglobal Base Schema. This schema is reproduced below. 2344

<xsd:schema targetNamespace="urn:epcglobal:xsd:1" 2345

xmlns:epcglobal="urn:epcglobal:xsd:1" 2346

xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2347

elementFormDefault="unqualified" 2348

attributeFormDefault="unqualified" 2349

version="1.0"> 2350

<xsd:annotation> 2351

<xsd:documentation> 2352

Reserved.</epcglobal:copyright> 2354

<epcglobal:disclaimer>EPCglobal Inc., its members, officers, directors, 2355

employees, or agents shall not be liable for any injury, loss, damages, financial or 2356

otherwise, arising from, related to, or caused by the use of this document. The use 2357

of said document shall constitute your express consent to the foregoing 2358

exculpation.</epcglobal:disclaimer> 2359

<epcglobal:specification>EPCglobal common components Version 2360

1.0</epcglobal:specification> 2361

</xsd:documentation> 2362

EPC Information Services (EPCIS) Standard

</xsd:annotation> 2363

<xsd:complexType name="Document" abstract="true"> 2364

<xsd:annotation> 2365

<xsd:documentation xml:lang="en"> 2366

EPCglobal document properties for all messages. 2367

</xsd:documentation> 2368

</xsd:annotation> 2369

<xsd:attribute name="schemaVersion" type="xsd:decimal" use="required"> 2370

<xsd:annotation> 2371

<xsd:documentation xml:lang="en"> 2372

The version of the schema corresponding to which the instance conforms. 2373

</xsd:documentation> 2374

</xsd:annotation> 2375

</xsd:attribute> 2376

<xsd:attribute name="creationDate" type="xsd:dateTime" use="required"> 2377

<xsd:annotation> 2378

<xsd:documentation xml:lang="en"> 2379

The date the message was created. Used for auditing and logging. 2380

</xsd:documentation> 2381

</xsd:annotation> 2382

</xsd:attribute> 2383

</xsd:complexType> 2384

<xsd:complexType name="EPC"> 2385

<xsd:annotation> 2386

<xsd:documentation xml:lang="en"> 2387

EPC represents the Electronic Product Code. 2388

</xsd:documentation> 2389

</xsd:annotation> 2390

<xsd:simpleContent> 2391

<xsd:extension base="xsd:string"/> 2392

</xsd:simpleContent> 2393

</xsd:complexType> 2394

</xsd:schema> 2395

9.4 Master data in the XML binding 2396

As noted in Section 6.1.1

, EPCIS provides four ways to transmit master data. These four ways are 2397

supported by different parts of the XML schema specified in the remainder of this section, as 2398

summarised in the following table: 2399

Mechanism Schema Support

Master data query VocabularyElement within VocabularyList, as contained within

epcisq:QueryResults

ILMD XML element contained within

ILMD

element

Header of EPCIS document VocabularyElement within VocabularyList, as contained within

EPCISHeader

EPCIS master data document VocabularyElement within VocabularyList, as contained within

EPCISBody

within

epcismd:EPCISMasterDataDocument

Each master data attribute is a name/value pair, where the name part is a qualified name consisting 2400

of a namespace URI and a local name, and the value is any data type expressible in XML. 2401

Regardless of which of the four mechanisms above are used to transmit master data, the data 2402

transmitted SHALL always use the same namespace URI and local name for a given attribute. The 2403

way the namespace URI and local name are encoded into XML, however, differs depending on the 2404

mechanism: 2405

■ For ILMD elements, the master data attribute SHALL be an XML element whose element name is 2406

a qualified name, where the prefix of the qualified name is bound to the namespace URI of the 2407

master data attribute and the local name of the qualified name is the local name of the master 2408

data attribute. The content of the element SHALL be the value of the master data attribute. 2409

■ For the mechanisms that use

VocabularyElement, the id attribute of the 2410

VocabularyElement element SHALL be a string consisting of the namespace URI, a pound 2411

EPC Information Services (EPCIS) Standard

sign (#) character, and the local name. The content of the VocabularyElement element 2412

SHALL be the value of the master data attribute. 2413

Non-Normative: Example: Consider a master data attribute whose namespace URI is 2414

http://epcis.example.com/ns/md, whose local name is myAttrName, and whose value is 2415

the string myAttrValue. Here is how that attribute would appear in an ILMD section: 2416

<epcis:EPCISDocument 2417

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 2418

xmlns:example="http://epcis.example.com/ns/md" ...> 2419

... 2420

<ObjectEvent> 2421

... 2422

<ILMD> 2423

<example:myAttrName>myAttrValue</example:myAttrName> 2424

... 2425

</ObjectEvent> 2426

... 2427

</epcis:EPCISDocument> 2428

And here is how that attribute would appear in a VocabularyElement: 2429

<VocabularyElement 2430

id="http://epcis.example.com/ns/md#myAttrName"> 2431

myAttrValue 2432

</VocabularyElement> 2433

(Newlines and whitespace have been added on either side of myAttrValue for clarity, but 2434

they would not be present in actual XML.) 2435

DEPRECATED: The XML binding for the Core Event Types data definition module includes a facility 2436

for the inclusion of additional information in the readPoint and bizLocation fields of all event 2437

types by including additional subelements within those fields following the required id subelement. 2438

This facility was originally conceived as a means to communicate master data for location identifiers. 2439

However, this facility is DEPRECATED as of EPCIS 1.2, and SHOULD NOT be used in EPCIS data 2440

conforming to EPCIS 1.2 or later. One or more of the other mechanisms for communicating master 2441

data should be used instead. 2442

9.5 Schema for core event types 2443

The following is an XML Schema (XSD) for the Core Event Types data definition module. This 2444

schema imports additional schemas as shown in the following table: 2445

Namespace Location Reference Source

urn:epcglobal:xsd:1

EPCglobal.xsd

Section 9.3

http://www.unece.org/cefact/

namespaces/StandardBusinessD

ocumentHeader

StandardBusinessDocumentHeader.xsd UN/CEFACT web site; see

Section 9.2

2446

In addition to the constraints implied by the schema, any value of type

xsd:dateTime in an 2447

instance document SHALL include a time zone specifier (either “

Z” for UTC or an explicit offset from 2448

UTC). 2449

For any XML element that specifies

minOccurs="0" of type xsd:anyURI, xsd:string, or a type 2450

derived from one of those, an EPCIS implementation SHALL treat an instance having the empty 2451

string as its value in exactly the same way as it would if the element were omitted altogether. The 2452

same is true for any XML attribute of similar type that specifies use="optional". 2453

EPC Information Services (EPCIS) Standard

This schema also includes the XML binding of master data for the Core Event Types data definition 2454

module. The master data portions of the schema are used (a) for returning results from the 2455

SimpleMasterDataQuery query type (Section 8.2.7.2); (b) to provide the body of a master data 2456

document as defined in Section 9.7; and (c) to provide for an optional master data section of the

2457

EPCIS header which may be used in an EPCIS document or EPCIS query document. 2458

The EPCISDocument top-level element defined in the schema is used by the concrete bindings of 2459

the EPCIS Capture Interface specified in Section 10. In addition, trading partners may by mutual 2460

agreement use an EPCIS Document as a means to transport a collection of EPCIS events, optionally 2461

accompanied by relevant master data, as a single electronic document. 2462

An EPCIS document MAY include master data in its header. This is intended to allow the creator of 2463

an EPCIS document to include master data that the recipient of the document might otherwise need 2464

to query using the EPCIS Query Interface. It is not required that an EPCIS document include master 2465

data in the header, nor is it required that master data in the header include master data for every 2466

identifier used in the body of the EPCIS document, or that master data in the header be limited to 2467

identifiers used in the body of the EPCIS document. If master data in the header does pertain to an 2468

identifier in the body, however, it SHALL be current master data for that identifier at the time the 2469

EPCIS document is created. The receiver of an EPCIS document, including an implementation of the 2470

EPCIS capture interface, may use or ignore such master data as it sees fit. Master data in the 2471

header of an EPCIS document SHALL NOT specify attribute values that conflict with the ILMD section 2472

of any event contained within the EPCIS document body. 2473

The XML Schema (XSD) for the Core Event Types data definition module is given below. 2474

<?xml version="1.0" encoding="UTF-8"?> 2475

<xsd:schema xmlns:epcis="urn:epcglobal:epcis:xsd:1" 2476

xmlns:sbdh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" 2477

xmlns:epcglobal="urn:epcglobal:xsd:1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 2478

targetNamespace="urn:epcglobal:epcis:xsd:1" elementFormDefault="unqualified" 2479

attributeFormDefault="unqualified" version="1.2"> 2480

<xsd:annotation> 2481

<xsd:documentation xml:lang="en"> 2482

Reserved.</epcglobal:copyright> 2484

<epcglobal:disclaimer> 2485

THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY 2486

WARRANTY OF MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY 2487

WARRANTY OTHER WISE ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all liability 2488

for any damages arising from use or misuse of this Standard, whether special, 2489

indirect, consequential, or compensatory damages, and including liability for 2490

infringement of any intellectual property rights, relating to use of information in 2491

or reliance upon this document. 2492

2493

GS1 retains the right to make changes to this document at any time, without notice. 2494

GS1 makes no warranty for the use of this document and assumes no responsibility for 2495

any errors which may appear in the document, nor does it make a commitment to update 2496

the information contained herein. 2497

</epcglobal:disclaimer> 2498

<epcglobal:specification>EPC INFORMATION SERVICE (EPCIS) Version 2499

1.2</epcglobal:specification> 2500

</xsd:documentation> 2501

</xsd:annotation> 2502

<xsd:import namespace="urn:epcglobal:xsd:1" schemaLocation="./EPCglobal.xsd"/> 2503

<xsd:import 2504

namespace="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" 2505

schemaLocation="./StandardBusinessDocumentHeader.xsd"/> 2506

2507

<xsd:element name="EPCISDocument" type="epcis:EPCISDocumentType"/> 2508

<xsd:complexType name="EPCISDocumentType"> 2509

<xsd:annotation> 2510

<xsd:documentation xml:lang="en"> 2511

document that contains a Header and a Body. 2512

</xsd:documentation> 2513

</xsd:annotation> 2514

<xsd:complexContent> 2515

EPC Information Services (EPCIS) Standard

<xsd:extension base="epcglobal:Document"> 2516

<xsd:sequence> 2517

<xsd:element name="EPCISHeader" type="epcis:EPCISHeaderType" 2518

minOccurs="0"/> 2519

<xsd:element name="EPCISBody" type="epcis:EPCISBodyType"/> 2520

<xsd:element name="extension" type="epcis:EPCISDocumentExtensionType" 2521

minOccurs="0"/> 2522

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2523

maxOccurs="unbounded"/> 2524

</xsd:sequence> 2525

<xsd:anyAttribute processContents="lax"/> 2526

</xsd:extension> 2527

</xsd:complexContent> 2528

</xsd:complexType> 2529

<xsd:complexType name="EPCISDocumentExtensionType"> 2530

<xsd:sequence> 2531

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2532

</xsd:sequence> 2533

<xsd:anyAttribute processContents="lax"/> 2534

</xsd:complexType> 2535

2536

<xsd:complexType name="EPCISHeaderType"> 2537

<xsd:annotation> 2538

<xsd:documentation xml:lang="en"> 2539

specific header(s) including the Standard Business Document Header. 2540

</xsd:documentation> 2541

</xsd:annotation> 2542

<xsd:sequence> 2543

<xsd:element ref="sbdh:StandardBusinessDocumentHeader"/> 2544

<xsd:element name="extension" type="epcis:EPCISHeaderExtensionType" 2545

minOccurs="0"/> 2546

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2547

maxOccurs="unbounded"/> 2548

</xsd:sequence> 2549

<xsd:anyAttribute processContents="lax"/> 2550

</xsd:complexType> 2551

<xsd:complexType name="EPCISHeaderExtensionType"> 2552

<xsd:sequence> 2553

<xsd:element name="EPCISMasterData" type="epcis:EPCISMasterDataType" 2554

minOccurs="0"/> 2555

<xsd:element name="extension" type="epcis:EPCISHeaderExtension2Type" 2556

minOccurs="0"/> 2557

</xsd:sequence> 2558

<xsd:anyAttribute processContents="lax"/> 2559

</xsd:complexType> 2560

<xsd:complexType name="EPCISHeaderExtension2Type"> 2561

<xsd:sequence> 2562

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2563

</xsd:sequence> 2564

<xsd:anyAttribute processContents="lax"/> 2565

</xsd:complexType> 2566

2567

2568

<xsd:complexType name="EPCISMasterDataType"> 2569

<xsd:sequence> 2570

<xsd:element name="VocabularyList" type="epcis:VocabularyListType" /> 2571

<xsd:element name="extension" type="epcis:EPCISMasterDataExtensionType" 2572

minOccurs="0"/> 2573

</xsd:sequence> 2574

</xsd:complexType> 2575

<xsd:complexType name="EPCISMasterDataExtensionType"> 2576

<xsd:sequence> 2577

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2578

</xsd:sequence> 2579

</xsd:complexType> 2580

2581

EPC Information Services (EPCIS) Standard

2582

<xsd:complexType name="VocabularyListType"> 2583

<xsd:sequence> 2584

<xsd:element name="Vocabulary" type="epcis:VocabularyType" minOccurs="0" 2585

maxOccurs="unbounded"/> 2586

</xsd:sequence> 2587

</xsd:complexType> 2588

2589

<xsd:complexType name="VocabularyType"> 2590

<xsd:sequence> 2591

<xsd:element name="VocabularyElementList" 2592

type="epcis:VocabularyElementListType" minOccurs="0"/> 2593

<xsd:element name="extension" type="epcis:VocabularyExtensionType" 2594

minOccurs="0"/> 2595

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2596

maxOccurs="unbounded"/> 2597

</xsd:sequence> 2598

<xsd:attribute name="type" type="xsd:anyURI" use="required"/> 2599

<xsd:anyAttribute processContents="lax"/> 2600

</xsd:complexType> 2601

2602

<xsd:complexType name="VocabularyElementListType"> 2603

<xsd:sequence> 2604

<xsd:element name="VocabularyElement" type="epcis:VocabularyElementType" 2605

maxOccurs="unbounded"/> 2606

</xsd:sequence> 2607

</xsd:complexType> 2608

2609

<!-- Implementations SHALL treat a <children list containing zero elements 2610

in the same way as if the <children> element were omitted altogether. 2611

--> 2612

<xsd:complexType name="VocabularyElementType"> 2613

<xsd:sequence> 2614

<xsd:element name="attribute" type="epcis:AttributeType" minOccurs="0" 2615

maxOccurs="unbounded"/> 2616

<xsd:element name="children" type="epcis:IDListType" minOccurs="0"/> 2617

<xsd:element name="extension" type="epcis:VocabularyElementExtensionType" 2618

minOccurs="0"/> 2619

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2620

maxOccurs="unbounded"/> 2621

</xsd:sequence> 2622

<xsd:attribute name="id" type="xsd:anyURI" use="required"/> 2623

<xsd:anyAttribute processContents="lax"/> 2624

</xsd:complexType> 2625

2626

<xsd:complexType name="AttributeType"> 2627

<xsd:complexContent mixed="true"> 2628

<xsd:extension base="xsd:anyType"> 2629

<xsd:attribute name="id" type="xsd:anyURI" use="required"/> 2630

<xsd:anyAttribute processContents="lax"/> 2631

</xsd:extension> 2632

</xsd:complexContent> 2633

</xsd:complexType> 2634

2635

<xsd:complexType name="IDListType"> 2636

<xsd:sequence> 2637

<xsd:element name="id" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded"/> 2638

</xsd:sequence> 2639

<xsd:anyAttribute processContents="lax"/> 2640

</xsd:complexType> 2641

2642

<xsd:complexType name="VocabularyExtensionType"> 2643

<xsd:sequence> 2644

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2645

</xsd:sequence> 2646

<xsd:anyAttribute processContents="lax"/> 2647

EPC Information Services (EPCIS) Standard

</xsd:complexType> 2648

2649

<xsd:complexType name="VocabularyElementExtensionType"> 2650

<xsd:sequence> 2651

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2652

</xsd:sequence> 2653

<xsd:anyAttribute processContents="lax"/> 2654

</xsd:complexType> 2655

2656

<xsd:complexType name="EPCISBodyType"> 2657

<xsd:annotation> 2658

<xsd:documentation xml:lang="en"> 2659

specific body that contains EPCIS related Events. 2660

</xsd:documentation> 2661

</xsd:annotation> 2662

<xsd:sequence> 2663

<xsd:element name="EventList" type="epcis:EventListType" minOccurs="0"/> 2664

<xsd:element name="extension" type="epcis:EPCISBodyExtensionType" 2665

minOccurs="0"/> 2666

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2667

maxOccurs="unbounded"/> 2668

</xsd:sequence> 2669

<xsd:anyAttribute processContents="lax"/> 2670

</xsd:complexType> 2671

<xsd:complexType name="EPCISBodyExtensionType"> 2672

<xsd:sequence> 2673

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2674

</xsd:sequence> 2675

<xsd:anyAttribute processContents="lax"/> 2676

</xsd:complexType> 2677

2678

2679

<xsd:complexType name="EventListType"> 2680

<xsd:choice minOccurs="0" maxOccurs="unbounded"> 2681

<xsd:element name="ObjectEvent" type="epcis:ObjectEventType" minOccurs="0" 2682

maxOccurs="unbounded"/> 2683

<xsd:element name="AggregationEvent" type="epcis:AggregationEventType" 2684

minOccurs="0" maxOccurs="unbounded"/> 2685

<xsd:element name="QuantityEvent" type="epcis:QuantityEventType" minOccurs="0" 2686

maxOccurs="unbounded"/> 2687

<xsd:element name="TransactionEvent" type="epcis:TransactionEventType" 2688

minOccurs="0" maxOccurs="unbounded"/> 2689

<xsd:element name="extension" type="epcis:EPCISEventListExtensionType"/> 2690

<xsd:any namespace="##other" processContents="lax"/> 2691

</xsd:choice> 2692

<!-- Note: the use of "unbounded" in both the xsd:choice element 2693

and the enclosed xsd:element elements is, strictly speaking, 2694

redundant. However, this was found to avoid problems with 2695

certain XML processing tools, and so is retained here. 2696

--> 2697

</xsd:complexType> 2698

2699

<xsd:complexType name="EPCISEventListExtensionType"> 2700

<xsd:choice> 2701

<xsd:element name="TransformationEvent" type="epcis:TransformationEventType"/> 2702

<xsd:element name="extension" type="epcis:EPCISEventListExtension2Type"/> 2703

</xsd:choice> 2704

</xsd:complexType> 2705

2706

<xsd:complexType name="EPCISEventListExtension2Type"> 2707

<xsd:sequence> 2708

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2709

</xsd:sequence> 2710

<xsd:anyAttribute processContents="lax"/> 2711

</xsd:complexType> 2712

2713

EPC Information Services (EPCIS) Standard

<xsd:complexType name="EPCListType"> 2714

<xsd:sequence> 2715

<xsd:element name="epc" type="epcglobal:EPC" minOccurs="0" 2716

maxOccurs="unbounded"/> 2717

</xsd:sequence> 2718

</xsd:complexType> 2719

<xsd:simpleType name="ActionType"> 2720

<xsd:restriction base="xsd:string"> 2721

<xsd:enumeration value="ADD"/> 2722

<xsd:enumeration value="OBSERVE"/> 2723

<xsd:enumeration value="DELETE"/> 2724

</xsd:restriction> 2725

</xsd:simpleType> 2726

<xsd:simpleType name="ParentIDType"> 2727

<xsd:restriction base="xsd:anyURI"/> 2728

</xsd:simpleType> 2729

2730

<xsd:simpleType name="BusinessStepIDType"> 2731

<xsd:restriction base="xsd:anyURI"/> 2732

</xsd:simpleType> 2733

2734

<xsd:simpleType name="DispositionIDType"> 2735

<xsd:restriction base="xsd:anyURI"/> 2736

</xsd:simpleType> 2737

2738

<xsd:simpleType name="EPCClassType"> 2739

<xsd:restriction base="xsd:anyURI"/> 2740

</xsd:simpleType> 2741

2742

2743

<xsd:simpleType name="UOMType"> 2744

<xsd:restriction base="xsd:string"/> 2745

</xsd:simpleType> 2746

2747

<xsd:complexType name="QuantityElementType"> 2748

<xsd:sequence> 2749

<xsd:element name="epcClass" type="epcis:EPCClassType"/> 2750

<xsd:sequence minOccurs="0"> 2751

<xsd:element name="quantity" type="xsd:decimal"/> 2752

<xsd:element name="uom" type="epcis:UOMType" minOccurs="0"/> 2753

</xsd:sequence> 2754

</xsd:sequence> 2755

</xsd:complexType> 2756

<xsd:complexType name="QuantityListType"> 2757

<xsd:sequence> 2758

<xsd:element name="quantityElement" type="epcis:QuantityElementType" 2759

minOccurs="0" maxOccurs="unbounded"/> 2760

</xsd:sequence> 2761

</xsd:complexType> 2762

2763

2764

<xsd:simpleType name="ReadPointIDType"> 2765

<xsd:restriction base="xsd:anyURI"/> 2766

</xsd:simpleType> 2767

<xsd:complexType name="ReadPointType"> 2768

<xsd:sequence> 2769

<xsd:element name="id" type="epcis:ReadPointIDType"/> 2770

<xsd:element name="extension" type="epcis:ReadPointExtensionType" 2771

minOccurs="0"/> 2772

<!-- The wildcard below provides the extension mechanism described in Section 2773

9.4 --> 2774

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2775

maxOccurs="unbounded"/> 2776

</xsd:sequence> 2777

</xsd:complexType> 2778

<xsd:complexType name="ReadPointExtensionType"> 2779

EPC Information Services (EPCIS) Standard

<xsd:sequence> 2780

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2781

</xsd:sequence> 2782

<xsd:anyAttribute processContents="lax"/> 2783

</xsd:complexType> 2784

2785

<xsd:simpleType name="BusinessLocationIDType"> 2786

<xsd:restriction base="xsd:anyURI"/> 2787

</xsd:simpleType> 2788

<xsd:complexType name="BusinessLocationType"> 2789

<xsd:sequence> 2790

<xsd:element name="id" type="epcis:BusinessLocationIDType"/> 2791

<xsd:element name="extension" type="epcis:BusinessLocationExtensionType" 2792

minOccurs="0"/> 2793

<!-- The wildcard below provides the extension mechanism described in Section 2794

9.4 --> 2795

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2796

maxOccurs="unbounded"/> 2797

</xsd:sequence> 2798

</xsd:complexType> 2799

<xsd:complexType name="BusinessLocationExtensionType"> 2800

<xsd:sequence> 2801

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2802

</xsd:sequence> 2803

<xsd:anyAttribute processContents="lax"/> 2804

</xsd:complexType> 2805

2806

<xsd:simpleType name="BusinessTransactionIDType"> 2807

<xsd:restriction base="xsd:anyURI"/> 2808

</xsd:simpleType> 2809

2810

<xsd:simpleType name="BusinessTransactionTypeIDType"> 2811

<xsd:restriction base="xsd:anyURI"/> 2812

</xsd:simpleType> 2813

<xsd:complexType name="BusinessTransactionType"> 2814

<xsd:simpleContent> 2815

<xsd:extension base="epcis:BusinessTransactionIDType"> 2816

<xsd:attribute name="type" type="epcis:BusinessTransactionTypeIDType" 2817

use="optional"/> 2818

</xsd:extension> 2819

</xsd:simpleContent> 2820

</xsd:complexType> 2821

<xsd:complexType name="BusinessTransactionListType"> 2822

<xsd:sequence> 2823

<xsd:element name="bizTransaction" type="epcis:BusinessTransactionType" 2824

maxOccurs="unbounded"/> 2825

</xsd:sequence> 2826

</xsd:complexType> 2827

2828

2829

<xsd:simpleType name="SourceDestIDType"> 2830

<xsd:restriction base="xsd:anyURI"/> 2831

</xsd:simpleType> 2832

2833

2834

<xsd:simpleType name="SourceDestTypeIDType"> 2835

<xsd:restriction base="xsd:anyURI"/> 2836

</xsd:simpleType> 2837

2838

<xsd:complexType name="SourceDestType"> 2839

<xsd:simpleContent> 2840

<xsd:extension base="epcis:SourceDestIDType"> 2841

<xsd:attribute name="type" type="epcis:SourceDestTypeIDType" 2842

use="required"/> 2843

</xsd:extension> 2844

</xsd:simpleContent> 2845

EPC Information Services (EPCIS) Standard

</xsd:complexType> 2846

<xsd:complexType name="SourceListType"> 2847

<xsd:sequence> 2848

<xsd:element name="source" type="epcis:SourceDestType" maxOccurs="unbounded"/> 2849

</xsd:sequence> 2850

</xsd:complexType> 2851

<xsd:complexType name="DestinationListType"> 2852

<xsd:sequence> 2853

<xsd:element name="destination" type="epcis:SourceDestType" 2854

maxOccurs="unbounded"/> 2855

</xsd:sequence> 2856

</xsd:complexType> 2857

2858

2859

2860

<xsd:simpleType name="TransformationIDType"> 2861

<xsd:restriction base="xsd:anyURI"/> 2862

</xsd:simpleType> 2863

2864

2865

<xsd:complexType name="ILMDType"> 2866

<xsd:sequence> 2867

<xsd:element name="extension" type="epcis:ILMDExtensionType" minOccurs="0"/> 2868

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2869

maxOccurs="unbounded"/> 2870

</xsd:sequence> 2871

<xsd:anyAttribute processContents="lax"/> 2872

</xsd:complexType> 2873

<xsd:complexType name="ILMDExtensionType"> 2874

<xsd:sequence> 2875

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2876

</xsd:sequence> 2877

<xsd:anyAttribute processContents="lax"/> 2878

</xsd:complexType> 2879

2880

2881

2882

<xsd:simpleType name="EventIDType"> 2883

<xsd:restriction base="xsd:anyURI"/> 2884

</xsd:simpleType> 2885

2886

2887

2888

<xsd:simpleType name="ErrorReasonIDType"> 2889

<xsd:restriction base="xsd:anyURI"/> 2890

</xsd:simpleType> 2891

2892

2893

<xsd:complexType name="CorrectiveEventIDsType"> 2894

<xsd:sequence> 2895

<xsd:element name="correctiveEventID" type="epcis:EventIDType" minOccurs="0" 2896

maxOccurs="unbounded"/> 2897

</xsd:sequence> 2898

</xsd:complexType> 2899

2900

2901

<xsd:complexType name="ErrorDeclarationType"> 2902

<xsd:sequence> 2903

<xsd:element name="declarationTime" type="xsd:dateTime"/> 2904

<xsd:element name="reason" type="epcis:ErrorReasonIDType" minOccurs="0"/> 2905

<xsd:element name="correctiveEventIDs" type="epcis:CorrectiveEventIDsType" 2906

minOccurs="0"/> 2907

<xsd:element name="extension" type="epcis:ErrorDeclarationExtensionType" 2908

minOccurs="0"/> 2909

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2910

maxOccurs="unbounded"/> 2911

EPC Information Services (EPCIS) Standard

</xsd:sequence> 2912

<xsd:anyAttribute processContents="lax"/> 2913

</xsd:complexType> 2914

2915

<xsd:complexType name="ErrorDeclarationExtensionType"> 2916

<xsd:sequence> 2917

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2918

</xsd:sequence> 2919

<xsd:anyAttribute processContents="lax"/> 2920

</xsd:complexType> 2921

2922

2923

2924

2925

<!-- Some element types accommodate extensibility in the manner of 2926

"Versioning XML Vocabularies" by David Orchard (see 2927

http://www.xml.com/pub/a/2003/12/03/versioning.html). 2928

2929

In this approach, an optional <extension> element is defined 2930

for each extensible element type, where an <extension> element 2931

may contain future elements defined in the target namespace. 2932

2933

In addition to the optional <extension> element, extensible element 2934

types are declared with a final xsd:any wildcard to accommodate 2935

future elements defined by third parties (as denoted by the ##other 2936

namespace). 2937

2938

Finally, the xsd:anyAttribute facility is used to allow arbitrary 2939

attributes to be added to extensible element types. --> 2940

<xsd:complexType name="EPCISEventType" abstract="true"> 2941

<xsd:annotation> 2942

<xsd:documentation xml:lang="en"> 2943

base type for all EPCIS events. 2944

</xsd:documentation> 2945

</xsd:annotation> 2946

<xsd:sequence> 2947

<xsd:element name="eventTime" type="xsd:dateTime"/> 2948

<xsd:element name="recordTime" type="xsd:dateTime" minOccurs="0"/> 2949

<xsd:element name="eventTimeZoneOffset" type="xsd:string"/> 2950

<xsd:element name="baseExtension" type="epcis:EPCISEventExtensionType" 2951

minOccurs="0"/> 2952

</xsd:sequence> 2953

<xsd:anyAttribute processContents="lax"/> 2954

</xsd:complexType> 2955

2956

<xsd:complexType name="EPCISEventExtensionType"> 2957

<xsd:sequence> 2958

<xsd:element name="eventID" type="epcis:EventIDType" minOccurs="0"/> 2959

<xsd:element name="errorDeclaration" type="epcis:ErrorDeclarationType" 2960

minOccurs="0"/> 2961

<xsd:element name="extension" type="epcis:EPCISEventExtension2Type" 2962

minOccurs="0"/> 2963

</xsd:sequence> 2964

<xsd:anyAttribute processContents="lax"/> 2965

</xsd:complexType> 2966

2967

<xsd:complexType name="EPCISEventExtension2Type"> 2968

<xsd:sequence> 2969

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 2970

</xsd:sequence> 2971

<xsd:anyAttribute processContents="lax"/> 2972

</xsd:complexType> 2973

2974

<xsd:complexType name="ObjectEventType"> 2975

<xsd:annotation> 2976

<xsd:documentation xml:lang="en"> 2977

EPC Information Services (EPCIS) Standard

Object Event captures information about an event pertaining to one or more 2978

objects identified by EPCs. 2979

</xsd:documentation> 2980

</xsd:annotation> 2981

<xsd:complexContent> 2982

<xsd:extension base="epcis:EPCISEventType"> 2983

<xsd:sequence> 2984

<xsd:element name="epcList" type="epcis:EPCListType"/> 2985

<xsd:element name="action" type="epcis:ActionType"/> 2986

<xsd:element name="bizStep" type="epcis:BusinessStepIDType" 2987

minOccurs="0"/> 2988

<xsd:element name="disposition" type="epcis:DispositionIDType" 2989

minOccurs="0"/> 2990

<xsd:element name="readPoint" type="epcis:ReadPointType" minOccurs="0"/> 2991

<xsd:element name="bizLocation" type="epcis:BusinessLocationType" 2992

minOccurs="0"/> 2993

<xsd:element name="bizTransactionList" 2994

type="epcis:BusinessTransactionListType" minOccurs="0"/> 2995

<xsd:element name="extension" type="epcis:ObjectEventExtensionType" 2996

minOccurs="0"/> 2997

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 2998

maxOccurs="unbounded"/> 2999

</xsd:sequence> 3000

<xsd:anyAttribute processContents="lax"/> 3001

</xsd:extension> 3002

</xsd:complexContent> 3003

</xsd:complexType> 3004

3005

<xsd:complexType name="ObjectEventExtensionType"> 3006

<xsd:sequence> 3007

<xsd:element name="quantityList" type="epcis:QuantityListType" minOccurs="0"/> 3008

<xsd:element name="sourceList" type="epcis:SourceListType" minOccurs="0"/> 3009

<xsd:element name="destinationList" type="epcis:DestinationListType" 3010

minOccurs="0"/> 3011

<xsd:element name="ilmd" type="epcis:ILMDType" minOccurs="0"/> 3012

<xsd:element name="extension" type="epcis:ObjectEventExtension2Type" 3013

minOccurs="0"/> 3014

</xsd:sequence> 3015

<xsd:anyAttribute processContents="lax"/> 3016

</xsd:complexType> 3017

3018

<xsd:complexType name="ObjectEventExtension2Type"> 3019

<xsd:sequence> 3020

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3021

</xsd:sequence> 3022

<xsd:anyAttribute processContents="lax"/> 3023

</xsd:complexType> 3024

3025

<xsd:complexType name="AggregationEventType"> 3026

<xsd:annotation> 3027

<xsd:documentation xml:lang="en"> 3028

Aggregation Event captures an event that applies to objects that 3029

have a physical association with one another. 3030

</xsd:documentation> 3031

</xsd:annotation> 3032

<xsd:complexContent> 3033

<xsd:extension base="epcis:EPCISEventType"> 3034

<xsd:sequence> 3035

<xsd:element name="parentID" type="epcis:ParentIDType" minOccurs="0"/> 3036

<xsd:element name="childEPCs" type="epcis:EPCListType"/> 3037

<xsd:element name="action" type="epcis:ActionType"/> 3038

<xsd:element name="bizStep" type="epcis:BusinessStepIDType" 3039

minOccurs="0"/> 3040

<xsd:element name="disposition" type="epcis:DispositionIDType" 3041

minOccurs="0"/> 3042

<xsd:element name="readPoint" type="epcis:ReadPointType" minOccurs="0"/> 3043

EPC Information Services (EPCIS) Standard

<xsd:element name="bizLocation" type="epcis:BusinessLocationType" 3044

minOccurs="0"/> 3045

<xsd:element name="bizTransactionList" 3046

type="epcis:BusinessTransactionListType" minOccurs="0"/> 3047

<xsd:element name="extension" type="epcis:AggregationEventExtensionType" 3048

minOccurs="0"/> 3049

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3050

maxOccurs="unbounded"/> 3051

</xsd:sequence> 3052

<xsd:anyAttribute processContents="lax"/> 3053

</xsd:extension> 3054

</xsd:complexContent> 3055

</xsd:complexType> 3056

3057

<xsd:complexType name="AggregationEventExtensionType"> 3058

<xsd:sequence> 3059

<xsd:element name="childQuantityList" type="epcis:QuantityListType" 3060

minOccurs="0"/> 3061

<xsd:element name="sourceList" type="epcis:SourceListType" minOccurs="0"/> 3062

<xsd:element name="destinationList" type="epcis:DestinationListType" 3063

minOccurs="0"/> 3064

<xsd:element name="extension" type="epcis:AggregationEventExtension2Type" 3065

minOccurs="0"/> 3066

</xsd:sequence> 3067

<xsd:anyAttribute processContents="lax"/> 3068

</xsd:complexType> 3069

3070

<xsd:complexType name="AggregationEventExtension2Type"> 3071

<xsd:sequence> 3072

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3073

</xsd:sequence> 3074

<xsd:anyAttribute processContents="lax"/> 3075

</xsd:complexType> 3076

3077

<xsd:complexType name="QuantityEventType"> 3078

<xsd:annotation> 3079

<xsd:documentation xml:lang="en"> 3080

Quantity Event captures an event that takes place with respect to a specified 3081

quantity of 3082

object class. 3083

</xsd:documentation> 3084

</xsd:annotation> 3085

<xsd:complexContent> 3086

<xsd:extension base="epcis:EPCISEventType"> 3087

<xsd:sequence> 3088

<xsd:element name="epcClass" type="epcis:EPCClassType"/> 3089

<xsd:element name="quantity" type="xsd:int"/> 3090

<xsd:element name="bizStep" type="epcis:BusinessStepIDType" 3091

minOccurs="0"/> 3092

<xsd:element name="disposition" type="epcis:DispositionIDType" 3093

minOccurs="0"/> 3094

<xsd:element name="readPoint" type="epcis:ReadPointType" minOccurs="0"/> 3095

<xsd:element name="bizLocation" type="epcis:BusinessLocationType" 3096

minOccurs="0"/> 3097

<xsd:element name="bizTransactionList" 3098

type="epcis:BusinessTransactionListType" minOccurs="0"/> 3099

<xsd:element name="extension" type="epcis:QuantityEventExtensionType" 3100

minOccurs="0"/> 3101

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3102

maxOccurs="unbounded"/> 3103

</xsd:sequence> 3104

<xsd:anyAttribute processContents="lax"/> 3105

</xsd:extension> 3106

</xsd:complexContent> 3107

</xsd:complexType> 3108

<xsd:complexType name="QuantityEventExtensionType"> 3109

EPC Information Services (EPCIS) Standard

<xsd:sequence> 3110

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3111

</xsd:sequence> 3112

<xsd:anyAttribute processContents="lax"/> 3113

</xsd:complexType> 3114

3115

<xsd:complexType name="TransactionEventType"> 3116

<xsd:annotation> 3117

<xsd:documentation xml:lang="en"> 3118

Transaction Event describes the association or disassociation of physical 3119

objects to one or more business 3120

transactions. 3121

</xsd:documentation> 3122

</xsd:annotation> 3123

<xsd:complexContent> 3124

<xsd:extension base="epcis:EPCISEventType"> 3125

<xsd:sequence> 3126

<xsd:element name="bizTransactionList" 3127

type="epcis:BusinessTransactionListType"/> 3128

<xsd:element name="parentID" type="epcis:ParentIDType" minOccurs="0"/> 3129

<xsd:element name="epcList" type="epcis:EPCListType"/> 3130

<xsd:element name="action" type="epcis:ActionType"/> 3131

<xsd:element name="bizStep" type="epcis:BusinessStepIDType" 3132

minOccurs="0"/> 3133

<xsd:element name="disposition" type="epcis:DispositionIDType" 3134

minOccurs="0"/> 3135

<xsd:element name="readPoint" type="epcis:ReadPointType" minOccurs="0"/> 3136

<xsd:element name="bizLocation" type="epcis:BusinessLocationType" 3137

minOccurs="0"/> 3138

<xsd:element name="extension" type="epcis:TransactionEventExtensionType" 3139

minOccurs="0"/> 3140

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3141

maxOccurs="unbounded"/> 3142

</xsd:sequence> 3143

<xsd:anyAttribute processContents="lax"/> 3144

</xsd:extension> 3145

</xsd:complexContent> 3146

</xsd:complexType> 3147

3148

<xsd:complexType name="TransactionEventExtensionType"> 3149

<xsd:sequence> 3150

<xsd:element name="quantityList" type="epcis:QuantityListType" minOccurs="0"/> 3151

<xsd:element name="sourceList" type="epcis:SourceListType" minOccurs="0"/> 3152

<xsd:element name="destinationList" type="epcis:DestinationListType" 3153

minOccurs="0"/> 3154

<xsd:element name="extension" type="epcis:TransactionEventExtension2Type" 3155

minOccurs="0"/> 3156

</xsd:sequence> 3157

<xsd:anyAttribute processContents="lax"/> 3158

</xsd:complexType> 3159

3160

<xsd:complexType name="TransactionEventExtension2Type"> 3161

<xsd:sequence> 3162

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3163

</xsd:sequence> 3164

<xsd:anyAttribute processContents="lax"/> 3165

</xsd:complexType> 3166

3167

3168

<xsd:complexType name="TransformationEventType"> 3169

<xsd:annotation> 3170

<xsd:documentation xml:lang="en"> 3171

Transformation Event captures an event in which inputs are consumed 3172

and outputs are produced 3173

</xsd:documentation> 3174

</xsd:annotation> 3175

EPC Information Services (EPCIS) Standard

<xsd:complexContent> 3176

<xsd:extension base="epcis:EPCISEventType"> 3177

<xsd:sequence> 3178

<xsd:element name="inputEPCList" type="epcis:EPCListType" minOccurs="0"/> 3179

<xsd:element name="inputQuantityList" type="epcis:QuantityListType" 3180

minOccurs="0"/> 3181

<xsd:element name="outputEPCList" type="epcis:EPCListType" minOccurs="0"/> 3182

<xsd:element name="outputQuantityList" type="epcis:QuantityListType" 3183

minOccurs="0"/> 3184

<xsd:element name="transformationID" type="epcis:TransformationIDType" 3185

minOccurs="0"/> 3186

<xsd:element name="bizStep" type="epcis:BusinessStepIDType" 3187

minOccurs="0"/> 3188

<xsd:element name="disposition" type="epcis:DispositionIDType" 3189

minOccurs="0"/> 3190

<xsd:element name="readPoint" type="epcis:ReadPointType" minOccurs="0"/> 3191

<xsd:element name="bizLocation" type="epcis:BusinessLocationType" 3192

minOccurs="0"/> 3193

<xsd:element name="bizTransactionList" 3194

type="epcis:BusinessTransactionListType" minOccurs="0"/> 3195

<xsd:element name="sourceList" type="epcis:SourceListType" minOccurs="0"/> 3196

<xsd:element name="destinationList" type="epcis:DestinationListType" 3197

minOccurs="0"/> 3198

<xsd:element name="ilmd" type="epcis:ILMDType" minOccurs="0"/> 3199

<xsd:element name="extension" 3200

type="epcis:TransformationEventExtensionType" minOccurs="0"/> 3201

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3202

maxOccurs="unbounded"/> 3203

</xsd:sequence> 3204

<xsd:anyAttribute processContents="lax"/> 3205

</xsd:extension> 3206

</xsd:complexContent> 3207

</xsd:complexType> 3208

3209

<xsd:complexType name="TransformationEventExtensionType"> 3210

<xsd:sequence> 3211

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3212

</xsd:sequence> 3213

<xsd:anyAttribute processContents="lax"/> 3214

</xsd:complexType> 3215

</xsd:schema> 3216

9.6 Core event types – examples (Non-Normative) 3217

This section provides examples of EPCISDocuments, rendered into XML [XML1.0]. 3218

9.6.1 Example 1 – Object Events with instance-level identification 3219

The example in this section contains two ObjectEvents, each containing instance-level 3220

identification. This example only uses features from EPCIS 1.0 and vocabulary from CBV 1.1. The 3221

second event shows an event-level vendor/user extension element named myField, following the 3222

method for vendor/user extensions specified in Section 9.1. 3223

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 3224

<epcis:EPCISDocument 3225

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 3226

xmlns:example="http://ns.example.com/epcis" 3227

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 3228

creationDate="2005-07-11T11:30:47.0Z" 3229

schemaVersion="1.2"> 3230

<EPCISBody> 3231

<EventList> 3232

<ObjectEvent> 3233

<eventTime>2005-04-03T20:33:31.116-06:00</eventTime> 3234

<eventTimeZoneOffset>-06:00</eventTimeZoneOffset> 3235

EPC Information Services (EPCIS) Standard

<epcList> 3236

<epc>urn:epc:id:sgtin:0614141.107346.2017</epc> 3237

<epc>urn:epc:id:sgtin:0614141.107346.2018</epc> 3238

</epcList> 3239

<action>OBSERVE</action> 3240

<bizStep>urn:epcglobal:cbv:bizstep:shipping</bizStep> 3241

<disposition>urn:epcglobal:cbv:disp:in_transit</disposition> 3242

<readPoint> 3243

<id>urn:epc:id:sgln:0614141.07346.1234</id> 3244

</readPoint> 3245

<bizTransactionList> 3246

<bizTransaction 3247

type="urn:epcglobal:cbv:btt:po">http://transaction.acme.com/po/12345678</bizTransact3248

ion> 3249

</bizTransactionList> 3250

</ObjectEvent> 3251

<ObjectEvent> 3252

<eventTime>2005-04-04T20:33:31.116-06:00</eventTime> 3253

<eventTimeZoneOffset>-06:00</eventTimeZoneOffset> 3254

<epcList> 3255

<epc>urn:epc:id:sgtin:0614141.107346.2018</epc> 3256

</epcList> 3257

<action>OBSERVE</action> 3258

<bizStep>urn:epcglobal:cbv:bizstep:receiving</bizStep> 3259

<disposition>urn:epcglobal:cbv:disp:in_progress</disposition> 3260

<readPoint> 3261

<id>urn:epc:id:sgln:0012345.11111.400</id> 3262

</readPoint> 3263

<bizLocation> 3264

<id>urn:epc:id:sgln:0012345.11111.0</id> 3265

</bizLocation> 3266

<bizTransactionList> 3267

<bizTransaction 3268

type="urn:epcglobal:cbv:btt:po">http://transaction.acme.com/po/12345678</bizTransact3269

ion> 3270

<bizTransaction 3271

type="urn:epcglobal:cbv:btt:desadv">urn:epcglobal:cbv:bt:0614141073467:1152</bizTran3272

saction> 3273

</bizTransactionList> 3274

<example:myField>Example of a vendor/user extension</example:myField> 3275

</ObjectEvent> 3276

</EventList> 3277

</EPCISBody> 3278

</epcis:EPCISDocument> 3279

9.6.2 Example 2 – Object Event with class-level identification 3280

The example in this section contains one ObjectEvent, containing only class-level identification. 3281

Note that the

<epcList> element is still present, though empty, as this is required by the XML 3282

schema in order to maintain backward-compatibility with EPCIS 1.0. The

QuantityList, along 3283

with other elements new in EPCIS 1.1, are all found in the

<extension> area which is reserved for 3284

new features in EPCIS 1.1 (see Section 9.1

). A vendor/user extension named myField is also 3285

included. 3286

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 3287

<epcis:EPCISDocument 3288

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 3289

xmlns:example="http://ns.example.com/epcis" 3290

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 3291

creationDate="2005-07-11T11:30:47.0Z" 3292

schemaVersion="1.2"> 3293

<EPCISBody> 3294

<EventList> 3295

<ObjectEvent> 3296

<eventTime>2013-06-08T14:58:56.591Z</eventTime> 3297

EPC Information Services (EPCIS) Standard

<eventTimeZoneOffset>+02:00</eventTimeZoneOffset> 3298

<epcList/> 3299

<action>OBSERVE</action> 3300

<bizStep>urn:epcglobal:cbv:bizstep:receiving</bizStep> 3301

<disposition>urn:epcglobal:cbv:disp:in_progress</disposition> 3302

<readPoint> 3303

<id>urn:epc:id:sgln:0614141.00777.0</id> 3304

</readPoint> 3305

<bizLocation> 3306

<id>urn:epc:id:sgln:0614141.00888.0</id> 3307

</bizLocation> 3308

<extension> 3309

<quantityList> 3310

<quantityElement> 3311

<epcClass>urn:epc:class:lgtin:4012345.012345.998877</epcClass> 3312

<quantity>200</quantity> 3313

<uom>KGM</uom> 3314

<!-- Meaning: 200 kg of GTIN '04012345123456' belonging to lot 3315

'998877'--> 3316

</quantityElement> 3317

</quantityList> 3318

<sourceList> 3319

<source 3320

type="urn:epcglobal:cbv:sdt:possessing_party">urn:epc:id:sgln:4012345.00001.0</sourc3321

e> 3322

<!-- Party which had physical possession at the originating endpoint of 3323

the business transfer, e.g., a forwarder--> 3324

<source 3325

type="urn:epcglobal:cbv:sdt:location">urn:epc:id:sgln:4012345.00225.0</source> 3326

<!-- Physical location of the originating endpoint, e.g., a distribution 3327

centre of the forwarder--> 3328

</sourceList> 3329

<destinationList> 3330

<destination 3331

type="urn:epcglobal:cbv:sdt:owning_party">urn:epc:id:sgln:0614141.00001.0</destinati3332

on> 3333

<!-- Party which owns the physical objects at the terminating endpoint, 3334

e.g., a retail company --> 3335

<destination 3336

type="urn:epcglobal:cbv:sdt:location">urn:epc:id:sgln:0614141.00777.0</destination> 3337

<!-- Physical location of the terminating endpoint, e.g., a warehouse of 3338

the retail company--> 3339

</destinationList> 3340

</extension> 3341

<example:myField>Example of a vendor/user extension</example:myField> 3342

</ObjectEvent> 3343

</EventList> 3344

</EPCISBody> 3345

</epcis:EPCISDocument> 3346

9.6.3 Example 3 – Aggregation event with mixed identification 3347

The example in this section contains one AggregationEvent, containing children having both 3348

instance-level and class-level identification. The

ChildQuantityList is found in the 3349

extension> area which is reserved for new features in EPCIS 1.1 (see Section 9.1). A 3350

vendor/user extension named

myField is also included. 3351

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 3352

<epcis:EPCISDocument 3353

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 3354

xmlns:example="http://ns.example.com/epcis" 3355

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 3356

creationDate="2005-07-11T11:30:47.0Z" 3357

schemaVersion="1.2"> 3358

<EPCISBody> 3359

<EventList> 3360

EPC Information Services (EPCIS) Standard

<AggregationEvent> 3361

<eventTime>2013-06-08T14:58:56.591Z</eventTime> 3362

<eventTimeZoneOffset>+02:00</eventTimeZoneOffset> 3363

<parentID>urn:epc:id:sscc:0614141.1234567890</parentID> 3364

<childEPCs> 3365

<epc>urn:epc:id:sgtin:0614141.107346.2017</epc> 3366

<epc>urn:epc:id:sgtin:0614141.107346.2018</epc> 3367

</childEPCs> 3368

<action>OBSERVE</action> 3369

<bizStep>urn:epcglobal:cbv:bizstep:receiving</bizStep> 3370

<disposition>urn:epcglobal:cbv:disp:in_progress</disposition> 3371

<readPoint> 3372

<id>urn:epc:id:sgln:0614141.00777.0</id> 3373

</readPoint> 3374

<bizLocation> 3375

<id>urn:epc:id:sgln:0614141.00888.0</id> 3376

</bizLocation> 3377

<extension> 3378

<childQuantityList> 3379

<quantityElement> 3380

<epcClass>urn:epc:idpat:sgtin:4012345.098765.*</epcClass> 3381

<quantity>10</quantity> 3382

3383

</quantityElement> 3384

<quantityElement> 3385

<epcClass>urn:epc:class:lgtin:4012345.012345.998877</epcClass> 3386

<quantity>200.5</quantity> 3387

<uom>KGM</uom> 3388

<!-- Meaning: 200.5 kg of GTIN '04012345123456' belonging to lot 3389

'998877'--> 3390

</quantityElement> 3391

</childQuantityList> 3392

</extension> 3393

<example:myField>Example of a vendor/user extension</example:myField> 3394

</AggregationEvent> 3395

</EventList> 3396

</EPCISBody> 3397

</epcis:EPCISDocument> 3398

9.6.4 Example 4 – Transformation event 3399

The example in this section contains one

TransformationEvent, containing children having both 3400

instance-level and class-level identification. Instance/lot master data (ILMD) is also included, which 3401

describes the outputs of the transformation. A vendor/user extension named

myField is also 3402

included. The entire event is wrapped in the

<extension> element of EventList which is reserved 3403

for new event types in EPCIS 1.1 (see Section 9.1). 3404

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 3405

<epcis:EPCISDocument schemaVersion="1.2" creationDate="2013-06-3406

04T14:59:02.099+02:00" xmlns:epcis="urn:epcglobal:epcis:xsd:1" 3407

xmlns:example="http://ns.example.com/epcis"> 3408

<EPCISBody> 3409

<EventList> 3410

<extension> 3411

<TransformationEvent> 3412

<eventTime>2013-10-31T14:58:56.591Z</eventTime> 3413

<eventTimeZoneOffset>+02:00</eventTimeZoneOffset> 3414

<inputEPCList> 3415

<epc>urn:epc:id:sgtin:4012345.011122.25</epc> 3416

<epc>urn:epc:id:sgtin:4000001.065432.99886655</epc> 3417

</inputEPCList> 3418

<inputQuantityList> 3419

<quantityElement> 3420

<epcClass>urn:epc:class:lgtin:4012345.011111.4444</epcClass> 3421

<quantity>10</quantity> 3422

<uom>KGM</uom> 3423

EPC Information Services (EPCIS) Standard

</quantityElement> 3424

<quantityElement> 3425

<epcClass>urn:epc:class:lgtin:0614141.077777.987</epcClass> 3426

<quantity>30</quantity> 3427

<!-- As the uom field has been omitted, 30 instances (e.g., pieces) of 3428

GTIN '00614141777778' belonging to lot '987' have been used. --> 3429

</quantityElement> 3430

<quantityElement> 3431

<epcClass>urn:epc:idpat:sgtin:4012345.066666.*</epcClass> 3432

<quantity>220</quantity> 3433

<!-- As the uom field has been omitted and as an EPC pattern is 3434

indicated, 220 instances (e.g., pieces) of GTIN '04012345666663' have been used. --> 3435

</quantityElement> 3436

</inputQuantityList> 3437

<outputEPCList> 3438

<epc>urn:epc:id:sgtin:4012345.077889.25</epc> 3439

<epc>urn:epc:id:sgtin:4012345.077889.26</epc> 3440

<epc>urn:epc:id:sgtin:4012345.077889.27</epc> 3441

<epc>urn:epc:id:sgtin:4012345.077889.28</epc> 3442

</outputEPCList> 3443

<bizStep>urn:epcglobal:cbv:bizstep:commissioning</bizStep> 3444

<disposition>urn:epcglobal:cbv:disp:in_progress</disposition> 3445

<readPoint> 3446

<id>urn:epc:id:sgln:4012345.00001.0</id> 3447

</readPoint> 3448

<ilmd> 3449

<!-- Section, in which the instance/ lot master data referring to the 3450

objects indicated in the outputEPCList are defined.--> 3451

<example:bestBeforeDate>2014-12-10</example:bestBeforeDate> 3452

<!-- The namespace 'example' is just a placeholder for the domain under 3453

which the ILMD attributes are defined (for instance, by a GS1 working group). 3454

Meaning: the best before date of the above GTIN + lot is the 10th December 2014. --> 3455

<example:batch>XYZ</example:batch> 3456

</ilmd> 3457

<example:myField>Example of a vendor/user extension</example:myField> 3458

</TransformationEvent> 3459

</extension> 3460

</EventList> 3461

</EPCISBody> 3462

</epcis:EPCISDocument> 3463

9.7 Schema for master data document 3464

The following is an XML Schema (XSD) defining an EPCIS master data document. An EPCIS master 3465

data document may be used for transmitting master data by mutual agreement. This schema 3466

imports additional schemas as shown in the following table: 3467

Namespace Location reference Source

urn:epcglobal:xsd:1

EPCglobal.xsd Section 9.3

http://www.unece.org/cefact/namesp

aces/StandardBusinessDocumentHeade

StandardBusinessDocumentHeader.xsd UN/CEFACT web site; see

Section 9.2

urn:epcglobal:epcis:xsd:1

EPCglobal-epcis-1_2.xsd Section 9.5

3468

In addition to the constraints implied by the schema, any value of type

xsd:dateTime in an 3469

instance document SHALL include a time zone specifier (either “Z” for UTC or an explicit offset from 3470

UTC). 3471

For any XML element of type xsd:anyURI or xsd:string that specifies minOccurs="0", an 3472

EPCIS implementation SHALL treat an instance having the empty string as its value in exactly the 3473

same way as it would if the element were omitted altogether. 3474

EPC Information Services (EPCIS) Standard

This schema includes the EPCIS header from the core event types schema specified in Section 9.5. 3475

That header allows for the optional inclusion of master data. However, an EPCIS master data 3476

document (an XML document whose root element is EPCISMasterDataDocument defined by the 3477

schema below) SHALL NOT include the optional

EPCISMasterData element within its EPCIS 3478

header. 3479

The XML Schema (XSD) for master data is given below: 3480

<?xml version="1.0" encoding="UTF-8"?> 3481

<xsd:schema xmlns:epcismd="urn:epcglobal:epcis-masterdata:xsd:1" 3482

3483

xmlns:sbdh="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" 3484

xmlns:epcglobal="urn:epcglobal:xsd:1" 3485

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 3486

xmlns:xsd="http://www.w3.org/2001/XMLSchema" 3487

targetNamespace="urn:epcglobal:epcis-masterdata:xsd:1" 3488

elementFormDefault="unqualified" 3489

attributeFormDefault="unqualified" 3490

version="1.2"> 3491

<xsd:annotation> 3492

<xsd:documentation xml:lang="en"> 3493

Reserved.</epcglobal:copyright> 3495

<epcglobal:disclaimer> 3496

THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY 3497

WARRANTY OF MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY 3498

WARRANTY OTHER WISE ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all liability 3499

for any damages arising from use or misuse of this Standard, whether special, 3500

indirect, consequential, or compensatory damages, and including liability for 3501

infringement of any intellectual property rights, relating to use of information in 3502

or reliance upon this document. 3503

GS1 retains the right to make changes to this document at any time, without notice. 3504

GS1 makes no warranty for the use of this document and assumes no responsibility for 3505

any errors which may appear in the document, nor does it make a commitment to update 3506

the information contained herein. 3507

</epcglobal:disclaimer> 3508

<epcglobal:specification>EPC INFORMATION SERVICE (EPCIS) Version 3509

1.2</epcglobal:specification> 3510

</xsd:documentation> 3511

</xsd:annotation> 3512

<xsd:import namespace="urn:epcglobal:xsd:1" schemaLocation="./EPCglobal.xsd"/> 3513

<xsd:import 3514

3515

namespace="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" 3516

schemaLocation="./StandardBusinessDocumentHeader.xsd"/> 3517

<xsd:import 3518

namespace="urn:epcglobal:epcis:xsd:1" 3519

schemaLocation="./EPCglobal-epcis-1_2.xsd"/> 3520

3521

3522

<xsd:element name="EPCISMasterDataDocument" 3523

type="epcismd:EPCISMasterDataDocumentType"/> 3524

<xsd:complexType name="EPCISMasterDataDocumentType"> 3525

<xsd:annotation> 3526

<xsd:documentation xml:lang="en"> 3527

MasterData document that contains a Header and a Body. 3528

</xsd:documentation> 3529

</xsd:annotation> 3530

<xsd:complexContent> 3531

<xsd:extension base="epcglobal:Document"> 3532

<xsd:sequence> 3533

<xsd:element name="EPCISHeader" type="epcis:EPCISHeaderType" 3534

minOccurs="0"/> 3535

<xsd:element name="EPCISBody" type="epcismd:EPCISMasterDataBodyType"/> 3536

<xsd:element name="extension" 3537

type="epcismd:EPCISMasterDataDocumentExtensionType" minOccurs="0"/> 3538

EPC Information Services (EPCIS) Standard

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3539

maxOccurs="unbounded"/> 3540

</xsd:sequence> 3541

<xsd:anyAttribute processContents="lax"/> 3542

</xsd:extension> 3543

</xsd:complexContent> 3544

</xsd:complexType> 3545

3546

<xsd:complexType name="EPCISMasterDataBodyType"> 3547

<xsd:annotation> 3548

<xsd:documentation xml:lang="en"> 3549

MasterData specific body that contains Vocabularies. 3550

</xsd:documentation> 3551

</xsd:annotation> 3552

<xsd:sequence> 3553

<xsd:element name="VocabularyList" type="epcis:VocabularyListType" 3554

minOccurs="0"/> 3555

<xsd:element name="extension" type="epcismd:EPCISMasterDataBodyExtensionType" 3556

minOccurs="0"/> 3557

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3558

maxOccurs="unbounded"/> 3559

</xsd:sequence> 3560

<xsd:anyAttribute processContents="lax"/> 3561

</xsd:complexType> 3562

3563

<xsd:complexType name="EPCISMasterDataDocumentExtensionType"> 3564

<xsd:sequence> 3565

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3566

</xsd:sequence> 3567

<xsd:anyAttribute processContents="lax"/> 3568

</xsd:complexType> 3569

3570

<xsd:complexType name="EPCISMasterDataHeaderExtensionType"> 3571

<xsd:sequence> 3572

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3573

</xsd:sequence> 3574

<xsd:anyAttribute processContents="lax"/> 3575

</xsd:complexType> 3576

3577

<xsd:complexType name="EPCISMasterDataBodyExtensionType"> 3578

<xsd:sequence> 3579

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3580

</xsd:sequence> 3581

<xsd:anyAttribute processContents="lax"/> 3582

</xsd:complexType> 3583

3584

</xsd:schema> 3585

9.8 Master data – example (non-normative) 3586

Here is an example EPCISMasterDataDocument containing master data for BusinessLocation 3587

and

ReadPoint vocabularies, rendered into XML [XML1.0]: 3588

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 3589

<epcismd:EPCISMasterDataDocument 3590

xmlns:epcismd="urn:epcglobal:epcis-masterdata:xsd:1" 3591

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 3592

schemaVersion="1.0" 3593

creationDate="2005-07-11T11:30:47.0Z"> 3594

<EPCISBody> 3595

<VocabularyList> 3596

<Vocabulary type="urn:epcglobal:epcis:vtype:BusinessLocation"> 3597

<VocabularyElementList> 3598

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.0"> 3599

<attribute 3600

id="http://epcis.example.com/mda/latitude">+18.0000</attribute> 3601

EPC Information Services (EPCIS) Standard

<attribute id="http://epcis.example.com/mda/longitude">-3602

70.0000</attribute> 3603

<attribute id="http://epcis.example.com/mda/address"> 3604

<example:Address xmlns:example="http://epcis.example.com/ns"> 3605

<Street>100 Nowhere Street</Street> 3606

<City>Fancy</City> 3607

<State>DC</State> 3608

<Zip>99999</Zip> 3609

</example:Address> 3610

</attribute> 3611

<children> 3612

<id>urn:epc:id:sgln:0037000.00729.8201</id> 3613

<id>urn:epc:id:sgln:0037000.00729.8202</id> 3614

<id>urn:epc:id:sgln:0037000.00729.8203</id> 3615

</children> 3616

</VocabularyElement> 3617

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.8201"> 3618

<attribute id="urn:epcglobal:cbv:mda:sst">201</attribute> 3619

</VocabularyElement> 3620

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.8202"> 3621

<attribute id="urn:epcglobal:cbv:mda:sst">202</attribute> 3622

<children> 3623

<id>urn:epc:id:sgln:0037000.00729.8203</id> 3624

</children> 3625

</VocabularyElement> 3626

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.8203"> 3627

<attribute id="urn:epcglobal:cbv:mda:sst">202</attribute> 3628

<attribute id="urn:epcglobal:cbv:mda:ssa">402</attribute> 3629

</VocabularyElement> 3630

</VocabularyElementList> 3631

</Vocabulary> 3632

<Vocabulary type="urn:epcglobal:epcis:vtype:ReadPoint"> 3633

<VocabularyElementList> 3634

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.8201"> 3635

<attribute id="urn:epcglobal:cbv:mda:site">0037000007296</attribute> 3636

<attribute id="urn:epcglobal:cbv:mda:sst">201</attribute> 3637

</VocabularyElement> 3638

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.8202"> 3639

<attribute id="urn:epcglobal:cbv:mda:site">0037000007296</attribute> 3640

<attribute id="urn:epcglobal:cbv:mda:sst">202</attribute> 3641

</VocabularyElement> 3642

<VocabularyElement id="urn:epc:id:sgln:0037000.00729.8203"> 3643

<attribute id="urn:epcglobal:cbv:mda:site">0037000007296</attribute> 3644

<attribute id="urn:epcglobal:cbv:mda:sst">203</attribute> 3645

</VocabularyElement> 3646

</VocabularyElementList> 3647

</Vocabulary> 3648

</VocabularyList> 3649

</EPCISBody> 3650

</epcismd:EPCISMasterDataDocument> 3651

10 Bindings for core capture operations module 3652

This section defines bindings for the Core Capture Operations Module. All bindings specified here are 3653

based on the XML representation of events defined in Section 9.5. An implementation of EPCIS MAY 3654

provide support for one or more Core Capture Operations Module bindings as specified below. 3655

10.1 Message queue binding 3656

This section defines a binding of the Core Capture Operations Module to a message queue system, 3657

as commonly deployed within large enterprises. A message queue system is defined for the purpose 3658

of this section as any system which allows one application to send an XML message to another 3659

application. Message queue systems commonly support both point-to-point message delivery and 3660

EPC Information Services (EPCIS) Standard

publish/subscribe message delivery. Message queue systems often include features for guaranteed 3661

reliable delivery and other quality-of-service (QoS) guarantees. 3662

Because there is no universally accepted industry standard message queue system, this 3663

specification is designed to apply to any such system. Many implementation details, therefore, 3664

necessarily fall outside the scope of this specification. Such details include message queue system to 3665

use, addressing, protocols, use of QoS or other system-specific parameters, and so on. 3666

An EPCIS implementation MAY provide a message queue binding of the Core Capture Operations 3667

Module in the following manner. For the purposes of this binding, a “capture client” is an EPCIS 3668

Capture Application that wishes to deliver an EPCIS event through the EPCIS Capture Interface, and 3669

a “capture server” is an EPCIS Repository or EPCIS Accessing Application that receives an event 3670

from a capture client. 3671

A capture server SHALL provide one or more message queue endpoints through which a capture 3672

client may deliver one or more EPCIS events. Each message queue endpoint MAY be a point-to-3673

point queue, a publish/subscribe topic, or some other appropriate addressable channel provided by 3674

the message queue system; the specifics are outside the scope of this specification. 3675

A capture client SHALL exercise the

capture operation defined in Section 8.1.2 by delivering a 3676

message to the endpoint provided by the capture server. The message SHALL be one of the 3677

following: 3678

■ an XML document whose root element conforms to the EPCISDocument element as defined by 3679

the schema of Section 9.5; or 3680

■ an XML document whose root element conforms to the EPCISQueryDocument element as 3681

defined by the schema of Section 11.1

, where the element immediately nested within the 3682

EPCISBody element is a QueryResults element, and where the resultsBody element within 3683

the

QueryResults element contains an EventList element. 3684

An implementation of the capture interface SHALL accept the EPCISDocument form and SHOULD 3685

accept the

EPCISQueryDocument form. An implementation of the capture interface SHALL NOT 3686

accept documents that are not valid as defined above.

Successful acceptance of this message by 3687

the server SHALL constitute capture of all EPCIS events included in the message. 3688

Message queue systems vary in their ability to provide positive and negative acknowledgements to 3689

message senders. When a positive acknowledgement feature is available from the message queue 3690

system, a positive acknowledgement MAY be used to indicate successful capture by the capture 3691

server. When a negative acknowledgement feature is available from the message queue system, a 3692

negative acknowledgement MAY be used to indicate a failure to complete the capture operation. 3693

Failure may be due to an invalid document, an authorisation failure as described in Section 8.1.1

, or 3694

for some other reason. The specific circumstances under which a positive or negative 3695

acknowledgement are indicated is implementation-dependent. All implementations, however, SHALL 3696

either accept all events in the message or reject all events. 3697

10.2 HTTP binding 3698

This section defines a binding of the Core Capture Operations Module to HTTP [RFC2616]. 3699

An EPCIS implementation MAY provide an HTTP binding of the Core Capture Operations Module in 3700

the following manner. For the purposes of this binding, a “capture client” is an EPCIS Capture 3701

Application that wishes to deliver an EPCIS event through the EPCIS Capture Interface, and a 3702

“capture server” is an EPCIS Repository or EPCIS Accessing Application that receives an event from 3703

a capture client. 3704

A capture server SHALL provide an HTTP URL through which a capture client may deliver one or 3705

more EPCIS events. 3706

A capture client SHALL exercise the capture operation defined in Section 8.1.2

by invoking an HTTP 3707

POST operation on the URL provided by the capture server. The message payload SHALL be one of 3708

the following: 3709

■ an XML document whose root element conforms to the EPCISDocument element as defined by 3710

the schema of Section 9.5

; or 3711

EPC Information Services (EPCIS) Standard

■ an XML document whose root element conforms to the EPCISQueryDocument element as 3712

defined by the schema of Section 11.1, where the element immediately nested within the 3713

EPCISBody element is a QueryResults element, and where the resultsBody element within 3714

the

QueryResults element contains an EventList element. 3715

An implementation of the capture interface SHALL accept the EPCISDocument form and SHOULD 3716

accept the

EPCISQueryDocument form. An implementation of the capture interface SHALL NOT 3717

accept documents that are not valid as defined above. Successful acceptance of this message by the 3718

server SHALL constitute capture of all EPCIS events included in the message. 3719

Status codes returned by the capture server SHALL conform to [RFC2616], Section 10. In particular, 3720

the capture server SHALL return status code 200 to indicate successful completion of the capture 3721

operation, and any status code 3xx, 4xx, or 5xx SHALL indicate that the capture operation was not 3722

successfully completed. The specific circumstances under which a success or failure code is returned 3723

are implementation-dependent. All implementations, however, SHALL either accept all events in the 3724

message or reject all events. 3725

11 Bindings for core query operations module 3726

This section defines bindings for the Core Query Operations Module, as follows: 3727

Interface Binding Document section

Query Control Interface SOAP over HTTP (WSDL)

Section 11.2

XML over AS2

Section 11.3

Query Callback Interface XML over HTTP

Section 11.4.2

XML over HTTP+TLS

(HTTPS)

Section 11.4.3

XML over AS2

Section 11.4.4

3728

All of these bindings share a common XML syntax, specified in Section 11.1. The XML schema has 3729

the following ingredients: 3730

■ XML elements for the argument and return signature of each method in the Query Control 3731

Interface as defined in Section 8.2.5

3732

■ XML types for each of the datatypes used in those argument and return signatures 3733

■ XML elements for each of the exceptions defined in Section 8.2.6 3734

■ XML elements for the Query Callback Interface as defined in Section 8.2.8. (These are actually 3735

just a subset of the previous three bullets.) 3736

■ An EPCISQueryDocument element, which is used as an “envelope” by bindings whose 3737

underlying technology does not provide its own envelope or header mechanism (specifically, all 3738

bindings except for the SOAP binding). The AS2 binding uses this to provide a header to match 3739

requests and responses. The EPCISQueryDocument element shares the EPCISHeader type 3740

defined in Section 9.5

. Each binding specifies its own rules for using this header, if applicable. 3741

11.1 XML schema for core query operations module 3742

The following schema defines XML representations of data types, requests, responses, and 3743

exceptions used by the EPCIS Query Control Interface and EPCIS Query Callback Interface in the 3744

Core Query Operations Module. This schema is incorporated by reference into all of the bindings for 3745

these two interfaces specified in the remainder of this Section 11. This schema SHOULD be used by 3746

any new binding of any interface within the Core Query Operations Module that uses XML as the 3747

underlying message format. 3748

The QueryParam type defined in the schema below is used to represent a query parameter as used 3749

by the

poll and subscribe methods of the query interface defined in Section 8.2.5. A query 3750

parameter consists of a name and a value. The XML schema specifies

xsd:anyType for the value, 3751

EPC Information Services (EPCIS) Standard

so that a parameter value of any type can be represented. When creating a document instance, the 3752

actual value SHALL conform to a type appropriate for the query parameter, as defined in the 3753

following table: 3754

Parameter type

XML type for

value

element

Int

xsd:integer

Float

xsd:double

Time

xsd:dateTime

String

xsd:string

List of String

epcisq:ArrayOfString

Void

epcisq:VoidHolder

3755

In particular, the table above SHALL be used to map the parameter types specified for the 3756

predefined queries of Section 8.2.7

into the corresponding XML types. 3757

Each <value> element specifying a query parameter value in an instance document MAY include an 3758

xsi:type attribute as specified in [XSD1]. The following rules specify how query parameter values 3759

are processed: 3760

■ When a <

value> element does not include an xsi:type attribute, the subscribe or poll 3761

method of the Query Control Interface SHALL raise a

QueryParameterException if the 3762

specified value is not valid syntax for the type required by the query parameter. 3763

■ When a

<value> element does include an xsi:type attribute, the following rules apply: 3764

□ If the body of the <value> element is not valid syntax for the type specified by the 3765

xsi:type attribute, the EPCISQueryDocument or SOAP request MAY be rejected by the 3766

implementation’s XML parser. 3767

□ If the value of the xsi:type attribute is not the correct type for that query parameter as 3768

specified in the second column of the table above, the subscribe or poll method of the 3769

Query Control Interface MAY raise a QueryParameterException, even if the body of the 3770

<value> element is valid syntax for the type required by the query parameter. 3771

□ If the body of the <

value> element is not valid syntax for the type required by the query 3772

parameter, the

subscribe or poll method of the Query Control Interface SHALL raise a 3773

QueryParameterException unless the EPCISQueryDocument or SOAP request was 3774

rejected by the implementation’s XML parser according to the rule above. 3775

This schema imports additional schemas as shown in the following table: 3776

Namespace Location reference Source

urn:epcglobal:xsd:1

EPCglobal.xsd

Section 9.3

http://www.unece.org/cefact/namesp

aces/StandardBusinessDocumentHeade

StandardBusinessDocumentHeader.xsd UN/CEFACT web site; see

Section 9.2

urn:epcglobal:epcis:xsd:1

EPCglobal-epcis-1_0.xsd

Section 9.5

urn:epcglobal:epcis-

masterdata:xsd:1

EPCglobal-epcis-masterdata-1_0.xsd

Section 9.7

3777

In addition to the constraints implied by the schema, any value of type

xsd:dateTime in an 3778

instance document SHALL include a time zone specifier (either “

Z” for UTC or an explicit offset from 3779

UTC). 3780

For any XML element of type

xsd:anyURI or xsd:string that specifies minOccurs="0", an 3781

EPCIS implementation SHALL treat an instance having the empty string as its value in exactly the 3782

same way as it would if the element were omitted altogether. 3783

EPC Information Services (EPCIS) Standard

The XML Schema (XSD) for the Core Query Operations Module is given below: 3784

<?xml version="1.0" encoding="UTF-8"?> 3785

3786

<xsd:schema targetNamespace="urn:epcglobal:epcis-query:xsd:1" 3787

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 3788

xmlns:epcismd="urn:epcglobal:epcis-masterdata:xsd:1" 3789

xmlns:epcisq="urn:epcglobal:epcis-query:xsd:1" 3790

xmlns:epcglobal="urn:epcglobal:xsd:1" 3791

xmlns:xsd="http://www.w3.org/2001/XMLSchema" 3792

elementFormDefault="unqualified" 3793

attributeFormDefault="unqualified" 3794

version="1.2"> 3795

3796

<xsd:annotation> 3797

<xsd:documentation xml:lang="en"> 3798

<epcglobal:copyright> 3799

</epcglobal:copyright> 3801

<epcglobal:disclaimer> 3802

THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY 3803

WARRANTY OF MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY 3804

WARRANTY OTHER WISE ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all liability 3805

for any damages arising from use or misuse of this Standard, whether special, 3806

indirect, consequential, or compensatory damages, and including liability for 3807

infringement of any intellectual property rights, relating to use of information in 3808

or reliance upon this document. 3809

GS1 retains the right to make changes to this document at any time, without notice. 3810

GS1 makes no warranty for the use of this document and assumes no responsibility for 3811

any errors which may appear in the document, nor does it make a commitment to update 3812

the information contained herein. 3813

</epcglobal:disclaimer> 3814

<epcglobal:specification> 3815

EPCIS Query 1.2 3816

</epcglobal:specification> 3817

</xsd:documentation> 3818

</xsd:annotation> 3819

3820

<xsd:import namespace="urn:epcglobal:xsd:1" schemaLocation="./EPCglobal.xsd"/> 3821

<xsd:import namespace="urn:epcglobal:epcis:xsd:1" schemaLocation="./EPCglobal-3822

epcis-1_2.xsd"/> 3823

3824

<xsd:element name="EPCISQueryDocument" type="epcisq:EPCISQueryDocumentType"/> 3825

<xsd:complexType name="EPCISQueryDocumentType"> 3826

<xsd:complexContent> 3827

<xsd:extension base="epcglobal:Document"> 3828

<xsd:sequence> 3829

<xsd:element name="EPCISHeader" type="epcis:EPCISHeaderType" 3830

minOccurs="0"/> 3831

<xsd:element name="EPCISBody" type="epcisq:EPCISQueryBodyType"/> 3832

<xsd:element name="extension" 3833

type="epcisq:EPCISQueryDocumentExtensionType" minOccurs="0"/> 3834

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3835

maxOccurs="unbounded"/> 3836

</xsd:sequence> 3837

<xsd:anyAttribute processContents="lax"/> 3838

</xsd:extension> 3839

</xsd:complexContent> 3840

</xsd:complexType> 3841

3842

<xsd:complexType name="EPCISQueryDocumentExtensionType"> 3843

<xsd:sequence> 3844

<xsd:any namespace="##local" processContents="lax" 3845

maxOccurs="unbounded"/> 3846

</xsd:sequence> 3847

<xsd:anyAttribute processContents="lax"/> 3848

</xsd:complexType> 3849

EPC Information Services (EPCIS) Standard

3850

<xsd:complexType name="EPCISQueryBodyType"> 3851

<xsd:choice> 3852

<xsd:element ref="epcisq:GetQueryNames"/> 3853

<xsd:element ref="epcisq:GetQueryNamesResult"/> 3854

<xsd:element ref="epcisq:Subscribe"/> 3855

<xsd:element ref="epcisq:SubscribeResult"/> 3856

<xsd:element ref="epcisq:Unsubscribe"/> 3857

<xsd:element ref="epcisq:UnsubscribeResult"/> 3858

<xsd:element ref="epcisq:GetSubscriptionIDs"/> 3859

<xsd:element ref="epcisq:GetSubscriptionIDsResult"/> 3860

<xsd:element ref="epcisq:Poll"/> 3861

<xsd:element ref="epcisq:GetStandardVersion"/> 3862

<xsd:element ref="epcisq:GetStandardVersionResult"/> 3863

<xsd:element ref="epcisq:GetVendorVersion"/> 3864

<xsd:element ref="epcisq:GetVendorVersionResult"/> 3865

<xsd:element ref="epcisq:DuplicateNameException"/> 3866

<!-- queryValidationException unimplemented in EPCIS 1.0 3867

<xsd:element ref="epcisq:QueryValidationException"/> 3868

--> 3869

<xsd:element ref="epcisq:InvalidURIException"/> 3870

<xsd:element ref="epcisq:NoSuchNameException"/> 3871

<xsd:element ref="epcisq:NoSuchSubscriptionException"/> 3872

<xsd:element ref="epcisq:DuplicateSubscriptionException"/> 3873

<xsd:element ref="epcisq:QueryParameterException"/> 3874

<xsd:element ref="epcisq:QueryTooLargeException"/> 3875

<xsd:element ref="epcisq:QueryTooComplexException"/> 3876

<xsd:element ref="epcisq:SubscriptionControlsException"/> 3877

<xsd:element ref="epcisq:SubscribeNotPermittedException"/> 3878

<xsd:element ref="epcisq:SecurityException"/> 3879

<xsd:element ref="epcisq:ValidationException"/> 3880

<xsd:element ref="epcisq:ImplementationException"/> 3881

<xsd:element ref="epcisq:QueryResults"/> 3882

</xsd:choice> 3883

</xsd:complexType> 3884

3885

3886

3887

<xsd:element name="GetQueryNames" type="epcisq:EmptyParms"/> 3888

<xsd:element name="GetQueryNamesResult" type="epcisq:ArrayOfString"/> 3889

3890

<xsd:element name="Subscribe" type="epcisq:Subscribe"/> 3891

<xsd:complexType name="Subscribe"> 3892

<xsd:sequence> 3893

<xsd:element name="queryName" type="xsd:string"/> 3894

<xsd:element name="params" type="epcisq:QueryParams"/> 3895

<xsd:element name="dest" type="xsd:anyURI"/> 3896

<xsd:element name="controls" type="epcisq:SubscriptionControls"/> 3897

<xsd:element name="subscriptionID" type="xsd:string"/> 3898

</xsd:sequence> 3899

</xsd:complexType> 3900

<xsd:element name="SubscribeResult" type="epcisq:VoidHolder"/> 3901

3902

<xsd:element name="Unsubscribe" type="epcisq:Unsubscribe"/> 3903

<xsd:complexType name="Unsubscribe"> 3904

<xsd:sequence> 3905

<xsd:element name="subscriptionID" type="xsd:string"/> 3906

</xsd:sequence> 3907

</xsd:complexType> 3908

<xsd:element name="UnsubscribeResult" type="epcisq:VoidHolder"/> 3909

3910

<xsd:element name="GetSubscriptionIDs" type="epcisq:GetSubscriptionIDs"/> 3911

<xsd:complexType name="GetSubscriptionIDs"> 3912

<xsd:sequence> 3913

<xsd:element name="queryName" type="xsd:string"/> 3914

</xsd:sequence> 3915

EPC Information Services (EPCIS) Standard

</xsd:complexType> 3916

<xsd:element name="GetSubscriptionIDsResult" type="epcisq:ArrayOfString"/> 3917

3918

<xsd:element name="Poll" type="epcisq:Poll"/> 3919

<xsd:complexType name="Poll"> 3920

<xsd:sequence> 3921

<xsd:element name="queryName" type="xsd:string"/> 3922

<xsd:element name="params" type="epcisq:QueryParams"/> 3923

</xsd:sequence> 3924

</xsd:complexType> 3925

<!-- The response from a Poll method is the QueryResults element, defined below. 3926

The QueryResults element is also used to deliver standing query results 3927

through the Query Callback Interface --> 3928

3929

<xsd:element name="GetStandardVersion" type="epcisq:EmptyParms"/> 3930

<xsd:element name="GetStandardVersionResult" type="xsd:string"/> 3931

3932

<xsd:element name="GetVendorVersion" type="epcisq:EmptyParms"/> 3933

<xsd:element name="GetVendorVersionResult" type="xsd:string"/> 3934

3935

<xsd:element name="VoidHolder" type="epcisq:VoidHolder"/> 3936

<xsd:complexType name="VoidHolder"> 3937

<xsd:sequence> 3938

</xsd:sequence> 3939

</xsd:complexType> 3940

3941

<xsd:complexType name="EmptyParms"/> 3942

3943

<xsd:complexType name="ArrayOfString"> 3944

<xsd:sequence> 3945

<xsd:element name="string" type="xsd:string" minOccurs="0" 3946

maxOccurs="unbounded"/> 3947

</xsd:sequence> 3948

</xsd:complexType> 3949

3950

<xsd:complexType name="SubscriptionControls"> 3951

<xsd:sequence> 3952

<xsd:element name="schedule" type="epcisq:QuerySchedule" minOccurs="0"/> 3953

<xsd:element name="trigger" type="xsd:anyURI" minOccurs="0"/> 3954

<xsd:element name="initialRecordTime" type="xsd:dateTime" minOccurs="0"/> 3955

<xsd:element name="reportIfEmpty" type="xsd:boolean"/> 3956

<xsd:element name="extension" type="epcisq:SubscriptionControlsExtensionType" 3957

minOccurs="0"/> 3958

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3959

maxOccurs="unbounded"/> 3960

</xsd:sequence> 3961

</xsd:complexType> 3962

3963

<xsd:complexType name="SubscriptionControlsExtensionType"> 3964

<xsd:sequence> 3965

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3966

</xsd:sequence> 3967

<xsd:anyAttribute processContents="lax"/> 3968

</xsd:complexType> 3969

3970

<xsd:complexType name="QuerySchedule"> 3971

<xsd:sequence> 3972

<xsd:element name="second" type="xsd:string" minOccurs="0"/> 3973

<xsd:element name="minute" type="xsd:string" minOccurs="0"/> 3974

<xsd:element name="hour" type="xsd:string" minOccurs="0"/> 3975

<xsd:element name="dayOfMonth" type="xsd:string" minOccurs="0"/> 3976

<xsd:element name="month" type="xsd:string" minOccurs="0"/> 3977

<xsd:element name="dayOfWeek" type="xsd:string" minOccurs="0"/> 3978

<xsd:element name="extension" type="epcisq:QueryScheduleExtensionType" 3979

minOccurs="0"/> 3980

EPC Information Services (EPCIS) Standard

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 3981

maxOccurs="unbounded"/> 3982

</xsd:sequence> 3983

</xsd:complexType> 3984

3985

<xsd:complexType name="QueryScheduleExtensionType"> 3986

<xsd:sequence> 3987

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 3988

</xsd:sequence> 3989

<xsd:anyAttribute processContents="lax"/> 3990

</xsd:complexType> 3991

3992

<xsd:complexType name="QueryParams"> 3993

<xsd:sequence> 3994

<xsd:element name="param" type="epcisq:QueryParam" minOccurs="0" 3995

maxOccurs="unbounded"/> 3996

</xsd:sequence> 3997

</xsd:complexType> 3998

3999

<xsd:complexType name="QueryParam"> 4000

<xsd:sequence> 4001

<xsd:element name="name" type="xsd:string"/> 4002

4003

<xsd:element name="value" type="xsd:anyType"/> 4004

</xsd:sequence> 4005

</xsd:complexType> 4006

4007

<xsd:element name="QueryResults" type="epcisq:QueryResults"/> 4008

<xsd:complexType name="QueryResults"> 4009

<xsd:sequence> 4010

<xsd:element name="queryName" type="xsd:string"/> 4011

<xsd:element name="subscriptionID" type="xsd:string" minOccurs="0"/> 4012

<xsd:element name="resultsBody" type="epcisq:QueryResultsBody"/> 4013

<xsd:element name="extension" type="epcisq:QueryResultsExtensionType" 4014

minOccurs="0"/> 4015

<xsd:any namespace="##other" processContents="lax" minOccurs="0" 4016

maxOccurs="unbounded"/> 4017

</xsd:sequence> 4018

</xsd:complexType> 4019

4020

<xsd:complexType name="QueryResultsExtensionType"> 4021

<xsd:sequence> 4022

<xsd:any namespace="##local" processContents="lax" maxOccurs="unbounded"/> 4023

</xsd:sequence> 4024

<xsd:anyAttribute processContents="lax"/> 4025

</xsd:complexType> 4026

4027

<xsd:complexType name="QueryResultsBody"> 4028

<xsd:choice> 4029

<xsd:element name="EventList" type="epcis:EventListType"/> 4030

<xsd:element name="VocabularyList" type="epcis:VocabularyListType"/> 4031

</xsd:choice> 4032

</xsd:complexType> 4033

4034

4035

4036

<xsd:element name="EPCISException" type="epcisq:EPCISException"/> 4037

<xsd:complexType name="EPCISException"> 4038

<xsd:sequence> 4039

<xsd:element name="reason" type="xsd:string"/> 4040

</xsd:sequence> 4041

</xsd:complexType> 4042

4043

<xsd:element name="DuplicateNameException" type="epcisq:DuplicateNameException"/> 4044

<xsd:complexType name="DuplicateNameException"> 4045

<xsd:complexContent> 4046

EPC Information Services (EPCIS) Standard

<xsd:extension base="epcisq:EPCISException"> 4047

<xsd:sequence/> 4048

</xsd:extension> 4049

</xsd:complexContent> 4050

</xsd:complexType> 4051

4052

<!-- QueryValidationException not implemented in EPCIS 1.0 4053

<xsd:element name="QueryValidationException" 4054

type="epcisq:QueryValidationException"/> 4055

<xsd:complexType name="QueryValidationException"> 4056

<xsd:complexContent> 4057

<xsd:extension base="epcisq:EPCISException"> 4058

<xsd:sequence/> 4059

</xsd:extension> 4060

</xsd:complexContent> 4061

</xsd:complexType> 4062

--> 4063

4064

<xsd:element name="InvalidURIException" type="epcisq:InvalidURIException"/> 4065

<xsd:complexType name="InvalidURIException"> 4066

<xsd:complexContent> 4067

<xsd:extension base="epcisq:EPCISException"> 4068

<xsd:sequence/> 4069

</xsd:extension> 4070

</xsd:complexContent> 4071

</xsd:complexType> 4072

4073

<xsd:element name="NoSuchNameException" type="epcisq:NoSuchNameException"/> 4074

<xsd:complexType name="NoSuchNameException"> 4075

<xsd:complexContent> 4076

<xsd:extension base="epcisq:EPCISException"> 4077

<xsd:sequence/> 4078

</xsd:extension> 4079

</xsd:complexContent> 4080

</xsd:complexType> 4081

4082

<xsd:element name="NoSuchSubscriptionException" 4083

type="epcisq:NoSuchSubscriptionException"/> 4084

<xsd:complexType name="NoSuchSubscriptionException"> 4085

<xsd:complexContent> 4086

<xsd:extension base="epcisq:EPCISException"> 4087

<xsd:sequence/> 4088

</xsd:extension> 4089

</xsd:complexContent> 4090

</xsd:complexType> 4091

4092

<xsd:element name="DuplicateSubscriptionException" 4093

type="epcisq:DuplicateSubscriptionException"/> 4094

<xsd:complexType name="DuplicateSubscriptionException"> 4095

<xsd:complexContent> 4096

<xsd:extension base="epcisq:EPCISException"> 4097

<xsd:sequence/> 4098

</xsd:extension> 4099

</xsd:complexContent> 4100

</xsd:complexType> 4101

4102

<xsd:element name="QueryParameterException" 4103

type="epcisq:QueryParameterException"/> 4104

<xsd:complexType name="QueryParameterException"> 4105

<xsd:complexContent> 4106

<xsd:extension base="epcisq:EPCISException"> 4107

<xsd:sequence/> 4108

</xsd:extension> 4109

</xsd:complexContent> 4110

</xsd:complexType> 4111

4112

EPC Information Services (EPCIS) Standard

<xsd:element name="QueryTooLargeException" type="epcisq:QueryTooLargeException"/> 4113

<xsd:complexType name="QueryTooLargeException"> 4114

<xsd:complexContent> 4115

<xsd:extension base="epcisq:EPCISException"> 4116

<xsd:sequence> 4117

<xsd:element name="queryName" type="xsd:string" minOccurs="0"/> 4118

<xsd:element name="subscriptionID" type="xsd:string" minOccurs="0"/> 4119

</xsd:sequence> 4120

</xsd:extension> 4121

</xsd:complexContent> 4122

</xsd:complexType> 4123

4124

<xsd:element name="QueryTooComplexException" 4125

type="epcisq:QueryTooComplexException"/> 4126

<xsd:complexType name="QueryTooComplexException"> 4127

<xsd:complexContent> 4128

<xsd:extension base="epcisq:EPCISException"> 4129

<xsd:sequence/> 4130

</xsd:extension> 4131

</xsd:complexContent> 4132

</xsd:complexType> 4133

4134

<xsd:element name="SubscriptionControlsException" 4135

type="epcisq:SubscriptionControlsException"/> 4136

<xsd:complexType name="SubscriptionControlsException"> 4137

<xsd:complexContent> 4138

<xsd:extension base="epcisq:EPCISException"> 4139

<xsd:sequence/> 4140

</xsd:extension> 4141

</xsd:complexContent> 4142

</xsd:complexType> 4143

4144

<xsd:element name="SubscribeNotPermittedException" 4145

type="epcisq:SubscribeNotPermittedException"/> 4146

<xsd:complexType name="SubscribeNotPermittedException"> 4147

<xsd:complexContent> 4148

<xsd:extension base="epcisq:EPCISException"> 4149

<xsd:sequence/> 4150

</xsd:extension> 4151

</xsd:complexContent> 4152

</xsd:complexType> 4153

4154

<xsd:element name="SecurityException" type="epcisq:SecurityException"/> 4155

<xsd:complexType name="SecurityException"> 4156

<xsd:complexContent> 4157

<xsd:extension base="epcisq:EPCISException"> 4158

<xsd:sequence/> 4159

</xsd:extension> 4160

</xsd:complexContent> 4161

</xsd:complexType> 4162

4163

<xsd:element name="ValidationException" type="epcisq:ValidationException"/> 4164

<xsd:complexType name="ValidationException"> 4165

<xsd:complexContent> 4166

<xsd:extension base="epcisq:EPCISException"> 4167

<xsd:sequence/> 4168

</xsd:extension> 4169

</xsd:complexContent> 4170

</xsd:complexType> 4171

4172

<xsd:element name="ImplementationException" 4173

type="epcisq:ImplementationException"/> 4174

<xsd:complexType name="ImplementationException"> 4175

<xsd:complexContent> 4176

<xsd:extension base="epcisq:EPCISException"> 4177

<xsd:sequence> 4178

EPC Information Services (EPCIS) Standard

<xsd:element name="severity" 4179

type="epcisq:ImplementationExceptionSeverity"/> 4180

<xsd:element name="queryName" type="xsd:string" minOccurs="0"/> 4181

<xsd:element name="subscriptionID" type="xsd:string" minOccurs="0"/> 4182

</xsd:sequence> 4183

</xsd:extension> 4184

</xsd:complexContent> 4185

</xsd:complexType> 4186

4187

<xsd:simpleType name="ImplementationExceptionSeverity"> 4188

<xsd:restriction base="xsd:NCName"> 4189

<xsd:enumeration value="ERROR"/> 4190

<xsd:enumeration value="SEVERE"/> 4191

</xsd:restriction> 4192

</xsd:simpleType> 4193

4194

</xsd:schema> 4195

11.2 SOAP/HTTP binding for the query control interface 4196

The following is a Web Service Description Language (WSDL) 1.1 [WSDL1.1] specification defining 4197

the standard SOAP/HTTP binding of the EPCIS Query Control Interface. An EPCIS implementation 4198

MAY provide a SOAP/HTTP binding of the EPCIS Query Control Interface; if a SOAP/HTTP binding is 4199

provided, it SHALL conform to the following WSDL. This SOAP/HTTP binding is compliant with the 4200

WS-I Basic Profile Version 1.0 [WSI]. This binding builds upon the schema defined in Section 11.1

. 4201

If an EPCIS implementation providing the SOAP binding receives an input that is syntactically invalid 4202

according to this WSDL, the implementation SHALL indicate this in one of the two following ways: 4203

the implementation MAY raise a

ValidationException, or it MAY raise a more generic exception 4204

provided by the SOAP processor being used. 4205

<?xml version="1.0" encoding="UTF-8"?> 4206

4207

4208

4209

<wsdl:definitions 4210

targetNamespace="urn:epcglobal:epcis:wsdl:1" 4211

xmlns="http://schemas.xmlsoap.org/wsdl/" 4212

xmlns:apachesoap="http://xml.apache.org/xml-soap" 4213

xmlns:epcis="urn:epcglobal:epcis:xsd:1" 4214

xmlns:epcisq="urn:epcglobal:epcis-query:xsd:1" 4215

xmlns:epcglobal="urn:epcglobal:xsd:1" 4216

xmlns:impl="urn:epcglobal:epcis:wsdl:1" 4217

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 4218

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 4219

xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" 4220

xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 4221

4222

<wsdl:documentation> 4223

<epcglobal:copyright> 4224

</epcglobal:copyright> 4226

<epcglobal:disclaimer> 4227

THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY 4228

WARRANTY OF MERCHANTABILITY, NONINFRINGMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY 4229

WARRANTY OTHER WISE ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all liability 4230

for any damages arising from use or misuse of this Standard, whether special, 4231

indirect, consequential, or compensatory damages, and including liability for 4232

infringement of any intellectual property rights, relating to use of information in 4233

or reliance upon this document. 4234

GS1 retains the right to make changes to this document at any time, without notice. 4235

GS1 makes no warranty for the use of this document and assumes no responsibility for 4236

any errors which may appear in the document, nor does it make a commitment to update 4237

the information contained herein. 4238

</epcglobal:disclaimer> 4239

<epcglobal:specification> 4240

EPC Information Services (EPCIS) Standard

</epcglobal:specification> 4241

</wsdl:documentation> 4242

4243

4244

<wsdl:types> 4245

<xsd:schema targetNamespace="urn:epcglobal:epcis:wsdl:1" 4246

xmlns:impl="urn:epcglobal:epcis:wsdl:1" 4247

xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 4248

4249

<xsd:import 4250

namespace="urn:epcglobal:xsd:1" 4251

schemaLocation="EPCglobal.xsd"/> 4252

<xsd:import 4253

namespace="urn:epcglobal:epcis:xsd:1" 4254

schemaLocation="EPCglobal-epcis-1_2.xsd"/> 4255

<xsd:import 4256

namespace="urn:epcglobal:epcis-query:xsd:1" 4257

schemaLocation="EPCglobal-epcis-query-1_2.xsd"/> 4258

</xsd:schema> 4259

</wsdl:types> 4260

4261

4262

4263

<wsdl:message name="getQueryNamesRequest"> 4264

<wsdl:part name="parms" element="epcisq:GetQueryNames"/> 4265

</wsdl:message> 4266

<wsdl:message name="getQueryNamesResponse"> 4267

<wsdl:part name="getQueryNamesReturn" element="epcisq:GetQueryNamesResult"/> 4268

</wsdl:message> 4269

4270

<wsdl:message name="subscribeRequest"> 4271

<wsdl:part name="parms" element="epcisq:Subscribe"/> 4272

</wsdl:message> 4273

<wsdl:message name="subscribeResponse"> 4274

<wsdl:part name="subscribeReturn" element="epcisq:SubscribeResult"/> 4275

</wsdl:message> 4276

4277

<wsdl:message name="unsubscribeRequest"> 4278

<wsdl:part name="parms" element="epcisq:Unsubscribe"/> 4279

</wsdl:message> 4280

<wsdl:message name="unsubscribeResponse"> 4281

<wsdl:part name="unsubscribeReturn" element="epcisq:UnsubscribeResult"/> 4282

</wsdl:message> 4283

4284

<wsdl:message name="getSubscriptionIDsRequest"> 4285

<wsdl:part name="parms" element="epcisq:GetSubscriptionIDs"/> 4286

</wsdl:message> 4287

<wsdl:message name="getSubscriptionIDsResponse"> 4288

<wsdl:part name="getSubscriptionIDsReturn" 4289

element="epcisq:GetSubscriptionIDsResult"/> 4290

</wsdl:message> 4291

4292

<wsdl:message name="pollRequest"> 4293

<wsdl:part name="parms" element="epcisq:Poll"/> 4294

</wsdl:message> 4295

<wsdl:message name="pollResponse"> 4296

<wsdl:part name="pollReturn" element="epcisq:QueryResults"/> 4297

</wsdl:message> 4298

4299

<wsdl:message name="getStandardVersionRequest"> 4300

<wsdl:part name="parms" element="epcisq:GetStandardVersion"/> 4301

</wsdl:message> 4302

<wsdl:message name="getStandardVersionResponse"> 4303

<wsdl:part name="getStandardVersionReturn" 4304

element="epcisq:GetStandardVersionResult"/> 4305

</wsdl:message> 4306

EPC Information Services (EPCIS) Standard

4307

<wsdl:message name="getVendorVersionRequest"> 4308

<wsdl:part name="parms" element="epcisq:GetVendorVersion"/> 4309

</wsdl:message> 4310

<wsdl:message name="getVendorVersionResponse"> 4311

<wsdl:part name="getVendorVersionReturn" 4312

element="epcisq:GetVendorVersionResult"/> 4313

</wsdl:message> 4314

4315

4316

<wsdl:message name="DuplicateNameExceptionResponse"> 4317

<wsdl:part name="fault" element="epcisq:DuplicateNameException"/> 4318

</wsdl:message> 4319

<!-- QueryValidationException not implemented in EPCIS 1.0 4320

<wsdl:message name="QueryValidationExceptionResponse"> 4321

<wsdl:part name="fault" element="epcisq:QueryValidationException"/> 4322

</wsdl:message> 4323

--> 4324

<wsdl:message name="InvalidURIExceptionResponse"> 4325

<wsdl:part name="fault" element="epcisq:InvalidURIException"/> 4326

</wsdl:message> 4327

<wsdl:message name="NoSuchNameExceptionResponse"> 4328

<wsdl:part name="fault" element="epcisq:NoSuchNameException"/> 4329

</wsdl:message> 4330

<wsdl:message name="NoSuchSubscriptionExceptionResponse"> 4331

<wsdl:part name="fault" element="epcisq:NoSuchSubscriptionException"/> 4332

</wsdl:message> 4333

<wsdl:message name="DuplicateSubscriptionExceptionResponse"> 4334

<wsdl:part name="fault" element="epcisq:DuplicateSubscriptionException"/> 4335

</wsdl:message> 4336

<wsdl:message name="QueryParameterExceptionResponse"> 4337

<wsdl:part name="fault" element="epcisq:QueryParameterException"/> 4338

</wsdl:message> 4339

<wsdl:message name="QueryTooLargeExceptionResponse"> 4340

<wsdl:part name="fault" element="epcisq:QueryTooLargeException"/> 4341

</wsdl:message> 4342

<wsdl:message name="QueryTooComplexExceptionResponse"> 4343

<wsdl:part name="fault" element="epcisq:QueryTooComplexException"/> 4344

</wsdl:message> 4345

<wsdl:message name="SubscriptionControlsExceptionResponse"> 4346

<wsdl:part name="fault" element="epcisq:SubscriptionControlsException"/> 4347

</wsdl:message> 4348

<wsdl:message name="SubscribeNotPermittedExceptionResponse"> 4349

<wsdl:part name="fault" element="epcisq:SubscribeNotPermittedException"/> 4350

</wsdl:message> 4351

<wsdl:message name="SecurityExceptionResponse"> 4352

<wsdl:part name="fault" element="epcisq:SecurityException"/> 4353

</wsdl:message> 4354

<wsdl:message name="ValidationExceptionResponse"> 4355

<wsdl:part name="fault" element="epcisq:ValidationException"/> 4356

</wsdl:message> 4357

<wsdl:message name="ImplementationExceptionResponse"> 4358

<wsdl:part name="fault" element="epcisq:ImplementationException"/> 4359

</wsdl:message> 4360

4361

4362

<wsdl:portType name="EPCISServicePortType"> 4363

4364

<wsdl:operation name="getQueryNames"> 4365

<wsdl:input message="impl:getQueryNamesRequest" name="getQueryNamesRequest"/> 4366

<wsdl:output message="impl:getQueryNamesResponse" 4367

name="getQueryNamesResponse"/> 4368

<wsdl:fault message="impl:SecurityExceptionResponse" 4369

name="SecurityExceptionFault"/> 4370

<wsdl:fault message="impl:ValidationExceptionResponse" 4371

name="ValidationExceptionFault"/> 4372

EPC Information Services (EPCIS) Standard

<wsdl:fault message="impl:ImplementationExceptionResponse" 4373

name="ImplementationExceptionFault"/> 4374

</wsdl:operation> 4375

4376

<wsdl:operation name="subscribe"> 4377

<wsdl:input message="impl:subscribeRequest" name="subscribeRequest"/> 4378

<wsdl:output message="impl:subscribeResponse" name="subscribeResponse"/> 4379

<wsdl:fault message="impl:NoSuchNameExceptionResponse" 4380

name="NoSuchNameExceptionFault"/> 4381

<wsdl:fault message="impl:InvalidURIExceptionResponse" 4382

name="InvalidURIExceptionFault"/> 4383

<wsdl:fault message="impl:DuplicateSubscriptionExceptionResponse" 4384

name="DuplicateSubscriptionExceptionFault"/> 4385

<wsdl:fault message="impl:QueryParameterExceptionResponse" 4386

name="QueryParameterExceptionFault"/> 4387

<wsdl:fault message="impl:QueryTooComplexExceptionResponse" 4388

name="QueryTooComplexExceptionFault"/> 4389

<wsdl:fault message="impl:SubscriptionControlsExceptionResponse" 4390

name="SubscriptionControlsExceptionFault"/> 4391

<wsdl:fault message="impl:SubscribeNotPermittedExceptionResponse" 4392

name="SubscribeNotPermittedExceptionFault"/> 4393

<wsdl:fault message="impl:SecurityExceptionResponse" 4394

name="SecurityExceptionFault"/> 4395

<wsdl:fault message="impl:ValidationExceptionResponse" 4396

name="ValidationExceptionFault"/> 4397

<wsdl:fault message="impl:ImplementationExceptionResponse" 4398

name="ImplementationExceptionFault"/> 4399

</wsdl:operation> 4400

4401

<wsdl:operation name="unsubscribe"> 4402

<wsdl:input message="impl:unsubscribeRequest" name="unsubscribeRequest"/> 4403

<wsdl:output message="impl:unsubscribeResponse" name="unsubscribeResponse"/> 4404

<wsdl:fault message="impl:NoSuchSubscriptionExceptionResponse" 4405

name="NoSuchSubscriptionExceptionFault"/> 4406

<wsdl:fault message="impl:SecurityExceptionResponse" 4407

name="SecurityExceptionFault"/> 4408

<wsdl:fault message="impl:ValidationExceptionResponse" 4409

name="ValidationExceptionFault"/> 4410

<wsdl:fault message="impl:ImplementationExceptionResponse" 4411

name="ImplementationExceptionFault"/> 4412

</wsdl:operation> 4413

4414

<wsdl:operation name="getSubscriptionIDs"> 4415

<wsdl:input message="impl:getSubscriptionIDsRequest" 4416

name="getSubscriptionIDsRequest"/> 4417

<wsdl:output message="impl:getSubscriptionIDsResponse" 4418

name="getSubscriptionIDsResponse"/> 4419

<wsdl:fault message="impl:NoSuchNameExceptionResponse" 4420

name="NoSuchNameExceptionFault"/> 4421

<wsdl:fault message="impl:SecurityExceptionResponse" 4422

name="SecurityExceptionFault"/> 4423

<wsdl:fault message="impl:ValidationExceptionResponse" 4424

name="ValidationExceptionFault"/> 4425

<wsdl:fault message="impl:ImplementationExceptionResponse" 4426

name="ImplementationExceptionFault"/> 4427

</wsdl:operation> 4428

4429

<wsdl:operation name="poll"> 4430

<wsdl:input message="impl:pollRequest" name="pollRequest"/> 4431

<wsdl:output message="impl:pollResponse" name="pollResponse"/> 4432

<wsdl:fault message="impl:QueryParameterExceptionResponse" 4433

name="QueryParameterExceptionFault"/> 4434

<wsdl:fault message="impl:QueryTooLargeExceptionResponse" 4435

name="QueryTooLargeExceptionFault"/> 4436

<wsdl:fault message="impl:QueryTooComplexExceptionResponse" 4437

name="QueryTooComplexExceptionFault"/> 4438

EPC Information Services (EPCIS) Standard

<wsdl:fault message="impl:NoSuchNameExceptionResponse" 4439

name="NoSuchNameExceptionFault"/> 4440

<wsdl:fault message="impl:SecurityExceptionResponse" 4441

name="SecurityExceptionFault"/> 4442

<wsdl:fault message="impl:ValidationExceptionResponse" 4443

name="ValidationExceptionFault"/> 4444

<wsdl:fault message="impl:ImplementationExceptionResponse" 4445

name="ImplementationExceptionFault"/> 4446

</wsdl:operation> 4447

4448

<wsdl:operation name="getStandardVersion"> 4449

<wsdl:input message="impl:getStandardVersionRequest" 4450

name="getStandardVersionRequest"/> 4451

<wsdl:output message="impl:getStandardVersionResponse" 4452

name="getStandardVersionResponse"/> 4453

<wsdl:fault message="impl:SecurityExceptionResponse" 4454

name="SecurityExceptionFault"/> 4455

<wsdl:fault message="impl:ValidationExceptionResponse" 4456

name="ValidationExceptionFault"/> 4457

<wsdl:fault message="impl:ImplementationExceptionResponse" 4458

name="ImplementationExceptionFault"/> 4459

</wsdl:operation> 4460

4461

<wsdl:operation name="getVendorVersion"> 4462

<wsdl:input message="impl:getVendorVersionRequest" 4463

name="getVendorVersionRequest"/> 4464

<wsdl:output message="impl:getVendorVersionResponse" 4465

name="getVendorVersionResponse"/> 4466

<wsdl:fault message="impl:SecurityExceptionResponse" 4467

name="SecurityExceptionFault"/> 4468

<wsdl:fault message="impl:ValidationExceptionResponse" 4469

name="ValidationExceptionFault"/> 4470

<wsdl:fault message="impl:ImplementationExceptionResponse" 4471

name="ImplementationExceptionFault"/> 4472

</wsdl:operation> 4473

</wsdl:portType> 4474

4475

4476

<wsdl:binding name="EPCISServiceBinding" type="impl:EPCISServicePortType"> 4477

<wsdlsoap:binding style="document" 4478

transport="http://schemas.xmlsoap.org/soap/http"/> 4479

4480

<wsdl:operation name="getQueryNames"> 4481

<wsdlsoap:operation soapAction=""/> 4482

<wsdl:input name="getQueryNamesRequest"> 4483

<wsdlsoap:body 4484

use="literal"/> 4485

</wsdl:input> 4486

<wsdl:output name="getQueryNamesResponse"> 4487

<wsdlsoap:body 4488

use="literal"/> 4489

</wsdl:output> 4490

<wsdl:fault name="SecurityExceptionFault"> 4491

<wsdlsoap:fault 4492

name="SecurityExceptionFault" 4493

use="literal"/> 4494

</wsdl:fault> 4495

<wsdl:fault name="ValidationExceptionFault"> 4496

<wsdlsoap:fault 4497

name="ValidationExceptionFault" 4498

use="literal"/> 4499

</wsdl:fault> 4500

<wsdl:fault name="ImplementationExceptionFault"> 4501

<wsdlsoap:fault 4502

name="ImplementationExceptionFault" 4503

use="literal"/> 4504

EPC Information Services (EPCIS) Standard

</wsdl:fault> 4505

</wsdl:operation> 4506

4507

<wsdl:operation name="subscribe"> 4508

<wsdlsoap:operation soapAction=""/> 4509

<wsdl:input name="subscribeRequest"> 4510

<wsdlsoap:body 4511

use="literal"/> 4512

</wsdl:input> 4513

<wsdl:output name="subscribeResponse"> 4514

<wsdlsoap:body 4515

use="literal"/> 4516

</wsdl:output> 4517

<wsdl:fault name="NoSuchNameExceptionFault"> 4518

<wsdlsoap:fault 4519

name="NoSuchNameExceptionFault" 4520

use="literal"/> 4521

</wsdl:fault> 4522

<wsdl:fault name="InvalidURIExceptionFault"> 4523

<wsdlsoap:fault 4524

name="InvalidURIExceptionFault" 4525

use="literal"/> 4526

</wsdl:fault> 4527

<wsdl:fault name="DuplicateSubscriptionExceptionFault"> 4528

<wsdlsoap:fault 4529

name="DuplicateSubscriptionExceptionFault" 4530

use="literal"/> 4531

</wsdl:fault> 4532

<wsdl:fault name="QueryParameterExceptionFault"> 4533

<wsdlsoap:fault 4534

name="QueryParameterExceptionFault" 4535

use="literal"/> 4536

</wsdl:fault> 4537

<wsdl:fault name="QueryTooComplexExceptionFault"> 4538

<wsdlsoap:fault 4539

name="QueryTooComplexExceptionFault" 4540

use="literal"/> 4541

</wsdl:fault> 4542

<wsdl:fault name="SubscribeNotPermittedExceptionFault"> 4543

<wsdlsoap:fault 4544

name="SubscribeNotPermittedExceptionFault" 4545

use="literal"/> 4546

</wsdl:fault> 4547

<wsdl:fault name="SubscriptionControlsExceptionFault"> 4548

<wsdlsoap:fault 4549

name="SubscriptionControlsExceptionFault" 4550

use="literal"/> 4551

</wsdl:fault> 4552

<wsdl:fault name="SecurityExceptionFault"> 4553

<wsdlsoap:fault 4554

name="SecurityExceptionFault" 4555

use="literal"/> 4556

</wsdl:fault> 4557

<wsdl:fault name="ValidationExceptionFault"> 4558

<wsdlsoap:fault 4559

name="ValidationExceptionFault" 4560

use="literal"/> 4561

</wsdl:fault> 4562

<wsdl:fault name="ImplementationExceptionFault"> 4563

<wsdlsoap:fault 4564

name="ImplementationExceptionFault" 4565

use="literal"/> 4566

</wsdl:fault> 4567

</wsdl:operation> 4568

4569

<wsdl:operation name="unsubscribe"> 4570

EPC Information Services (EPCIS) Standard

<wsdlsoap:operation soapAction=""/> 4571

<wsdl:input name="unsubscribeRequest"> 4572

<wsdlsoap:body 4573

use="literal"/> 4574

</wsdl:input> 4575

<wsdl:output name="unsubscribeResponse"> 4576

<wsdlsoap:body 4577

use="literal"/> 4578

</wsdl:output> 4579

<wsdl:fault name="NoSuchSubscriptionExceptionFault"> 4580

<wsdlsoap:fault 4581

name="NoSuchSubscriptionExceptionFault" 4582

use="literal"/> 4583

</wsdl:fault> 4584

<wsdl:fault name="SecurityExceptionFault"> 4585

<wsdlsoap:fault 4586

name="SecurityExceptionFault" 4587

use="literal"/> 4588

</wsdl:fault> 4589

<wsdl:fault name="ValidationExceptionFault"> 4590

<wsdlsoap:fault 4591

name="ValidationExceptionFault" 4592

use="literal"/> 4593

</wsdl:fault> 4594

<wsdl:fault name="ImplementationExceptionFault"> 4595

<wsdlsoap:fault 4596

name="ImplementationExceptionFault" 4597

use="literal"/> 4598

</wsdl:fault> 4599

</wsdl:operation> 4600

4601

<wsdl:operation name="getSubscriptionIDs"> 4602

<wsdlsoap:operation soapAction=""/> 4603

<wsdl:input name="getSubscriptionIDsRequest"> 4604

<wsdlsoap:body 4605

use="literal"/> 4606

</wsdl:input> 4607

<wsdl:output name="getSubscriptionIDsResponse"> 4608

<wsdlsoap:body 4609

use="literal"/> 4610

</wsdl:output> 4611

<wsdl:fault name="NoSuchNameExceptionFault"> 4612

<wsdlsoap:fault 4613

name="NoSuchNameExceptionFault" 4614

use="literal"/> 4615

</wsdl:fault> 4616

<wsdl:fault name="SecurityExceptionFault"> 4617

<wsdlsoap:fault 4618

name="SecurityExceptionFault" 4619

use="literal"/> 4620

</wsdl:fault> 4621

<wsdl:fault name="ValidationExceptionFault"> 4622

<wsdlsoap:fault 4623

name="ValidationExceptionFault" 4624

use="literal"/> 4625

</wsdl:fault> 4626

<wsdl:fault name="ImplementationExceptionFault"> 4627

<wsdlsoap:fault 4628

name="ImplementationExceptionFault" 4629

use="literal"/> 4630

</wsdl:fault> 4631

</wsdl:operation> 4632

4633

<wsdl:operation name="poll"> 4634

<wsdlsoap:operation soapAction=""/> 4635

<wsdl:input name="pollRequest"> 4636

EPC Information Services (EPCIS) Standard

<wsdlsoap:body 4637

use="literal"/> 4638

</wsdl:input> 4639

<wsdl:output name="pollResponse"> 4640

<wsdlsoap:body 4641

use="literal"/> 4642

</wsdl:output> 4643

<wsdl:fault name="QueryParameterExceptionFault"> 4644

<wsdlsoap:fault 4645

name="QueryParameterExceptionFault" 4646

use="literal"/> 4647

</wsdl:fault> 4648

<wsdl:fault name="QueryTooComplexExceptionFault"> 4649

<wsdlsoap:fault 4650

name="QueryTooComplexExceptionFault" 4651

use="literal"/> 4652

</wsdl:fault> 4653

<wsdl:fault name="QueryTooLargeExceptionFault"> 4654

<wsdlsoap:fault 4655

name="QueryTooLargeExceptionFault" 4656

use="literal"/> 4657

</wsdl:fault> 4658

<wsdl:fault name="NoSuchNameExceptionFault"> 4659

<wsdlsoap:fault 4660

name="NoSuchNameExceptionFault" 4661

use="literal"/> 4662

</wsdl:fault> 4663

<wsdl:fault name="SecurityExceptionFault"> 4664

<wsdlsoap:fault 4665

name="SecurityExceptionFault" 4666

use="literal"/> 4667

</wsdl:fault> 4668

<wsdl:fault name="ValidationExceptionFault"> 4669

<wsdlsoap:fault 4670

name="ValidationExceptionFault" 4671

use="literal"/> 4672

</wsdl:fault> 4673

<wsdl:fault name="ImplementationExceptionFault"> 4674

<wsdlsoap:fault 4675

name="ImplementationExceptionFault" 4676

use="literal"/> 4677

</wsdl:fault> 4678

</wsdl:operation> 4679

4680

<wsdl:operation name="getStandardVersion"> 4681

<wsdlsoap:operation soapAction=""/> 4682

<wsdl:input name="getStandardVersionRequest"> 4683

<wsdlsoap:body 4684

use="literal"/> 4685

</wsdl:input> 4686

<wsdl:output name="getStandardVersionResponse"> 4687

<wsdlsoap:body 4688

use="literal"/> 4689

</wsdl:output> 4690

<wsdl:fault name="SecurityExceptionFault"> 4691

<wsdlsoap:fault 4692

name="SecurityExceptionFault" 4693

use="literal"/> 4694

</wsdl:fault> 4695

<wsdl:fault name="ValidationExceptionFault"> 4696

<wsdlsoap:fault 4697

name="ValidationExceptionFault" 4698

use="literal"/> 4699

</wsdl:fault> 4700

<wsdl:fault name="ImplementationExceptionFault"> 4701

<wsdlsoap:fault 4702

EPC Information Services (EPCIS) Standard

name="ImplementationExceptionFault" 4703

use="literal"/> 4704

</wsdl:fault> 4705

</wsdl:operation> 4706

4707

<wsdl:operation name="getVendorVersion"> 4708

<wsdlsoap:operation soapAction=""/> 4709

<wsdl:input name="getVendorVersionRequest"> 4710

<wsdlsoap:body 4711

use="literal"/> 4712

</wsdl:input> 4713

<wsdl:output name="getVendorVersionResponse"> 4714

<wsdlsoap:body 4715

use="literal"/> 4716

</wsdl:output> 4717

<wsdl:fault name="SecurityExceptionFault"> 4718

<wsdlsoap:fault 4719

name="SecurityExceptionFault" 4720

use="literal"/> 4721

</wsdl:fault> 4722

<wsdl:fault name="ValidationExceptionFault"> 4723

<wsdlsoap:fault 4724

name="ValidationExceptionFault" 4725

use="literal"/> 4726

</wsdl:fault> 4727

<wsdl:fault name="ImplementationExceptionFault"> 4728

<wsdlsoap:fault 4729

name="ImplementationExceptionFault" 4730

use="literal"/> 4731

</wsdl:fault> 4732

</wsdl:operation> 4733

4734

</wsdl:binding> 4735

4736

4737

<wsdl:service name="EPCglobalEPCISService"> 4738

<wsdl:port binding="impl:EPCISServiceBinding" name="EPCglobalEPCISServicePort"> 4739

<!-- The address shown below is an example; an implementation MAY specify 4740

any port it wishes 4741

--> 4742

<wsdlsoap:address 4743

location="http://localhost:6060/axis/services/EPCglobalEPCISService"/> 4744

</wsdl:port> 4745

</wsdl:service> 4746

4747

</wsdl:definitions> 4748

4749

11.3 AS2 Binding for the query control interface 4750

This section defines a binding of the EPCIS Query Control Interface to AS2 [RFC4130]. An EPCIS 4751

implementation MAY provide an AS2 binding of the EPCIS Query Control Interface; if an AS2 binding 4752

is provided it SHALL conform to the provisions of this section. For the purposes of this binding, a 4753

“query client” is an EPCIS Accessing Application that wishes to issue EPCIS query operations as 4754

defined in Section 8.2.5

, and a “query server” is an EPCIS Repository or other system that carries 4755

out such operations on behalf of the query client. 4756

A query server SHALL provide an HTTP URL through which it receives messages from a query client 4757

in accordance with [RFC4130]. A message sent by a query client to a query server SHALL be an XML 4758

document whose root element conforms to the EPCISQueryDocument element as defined by the 4759

schema in Section 11.1

. The element immediately nested within the EPCISBody element SHALL be 4760

one of the elements corresponding to an EPCIS Query Control Interface method request (i.e., one of 4761

Subscribe, Unsubscribe, Poll, etc.). The permitted elements are listed in the table below. If 4762

the message sent by the query client fails to conform to the above requirements, the query server 4763

EPC Information Services (EPCIS) Standard

SHALL respond with a ValidationException (that is, return an EPCISQueryDocument instance 4764

where the element immediately nested within the

EPCISBody is a ValidationException). 4765

The query client SHALL provide an HTTP URL that the query server will use to deliver a response 4766

message. This URL is typically exchanged out of band, as part of setting up a bilateral trading 4767

partner agreement (see [RFC4130] Section 5.1).

4768

Both the query client and query server SHALL comply with the Requirements and SHOULD comply 4769

with the Recommendations listed in the GS1 document “EDIINT AS1 and AS2 Transport 4770

Communications Guidelines” [EDICG]. For reference, the relevant portions of this document are 4771

reproduced below. 4772

The query client SHALL include the Standard Business Document Header within the

EPCISHeader 4773

element. The query client SHALL include within the Standard Business Document Header a unique 4774

identifier as the value of the

InstanceIdentifier element. The query client MAY include other 4775

elements within the Standard Business Document Header as provided by the schema. The instance 4776

identifier provided by the query client SHOULD be unique with respect to all other messages for 4777

which the query client has not yet received a corresponding response. As described below, the 4778

instance identifier is copied into the response message, to assist the client in correlating responses 4779

with requests. 4780

A query server SHALL respond to each message sent by a query client by delivering a response 4781

message to the URL provided by the query client, in accordance with [RFC4130]. A response 4782

message sent by a query server SHALL be an XML document whose root element conforms to the 4783

EPCISQueryDocument element as defined by the schema in Section 11.1. The element 4784

immediately nested within the

EPCISBody element SHALL be one of the elements shown in the 4785

following table, according to the element that was provided in the corresponding request: 4786

Request element Permitted return elements

GetQueryNames GetQueryNamesResult

SecurityException

ValidationException

ImplementationException

Subscribe SubscribeResult

NoSuchNameException

InvalidURIException

DuplicateSubscriptionException

QueryParameterException

QueryTooComplexException

SubscriptionControlsException

SubscribeNotPermittedException

SecurityException

ValidationException

ImplementationException

Unsubscribe UnsubscribeResult

NoSuchSubscriptionException

SecurityException

ValidationException

ImplementationException

GetSubscriptionIDs GetSubscriptionIDsResult

NoSuchNameException

SecurityException

ValidationException

ImplementationException

EPC Information Services (EPCIS) Standard

Request element Permitted return elements

Poll QueryResults

QueryParameterException

QueryTooLargeException

QueryTooComplexException

NoSuchNameException

SecurityException

ValidationException

ImplementationException

GetStandardVersion GetStandardVersionResult

SecurityException

ValidationException

ImplementationException

GetVendorVersion GetVendorVersionResult

SecurityException

ValidationException

ImplementationException

4787

The query server SHALL include the Standard Business Document Header within the EPCISHeader 4788

element. The query server SHALL include within the Standard Business Document Header the 4789

BusinessScope element containing a Scope element containing a CorrelationInformation 4790

element containing a

RequestingDocumentInstanceIdentifier element; the value of the 4791

latter element SHALL be the value of the

InstanceIdentifier element from the Standard 4792

Business Document Header of the corresponding request. Within the

Scope element, the Type 4793

subelement SHALL be set to

EPCISQuery, and the InstanceIdentifier element SHALL be set to 4794

EPCIS. The query server MAY include other elements within the Standard Business Document 4795

Header as provided by the schema. 4796

11.3.1 GS1 AS2 guidelines (Non-Normative) 4797

As stated above, the query client and query server SHALL comply with the Requirements and 4798

SHOULD comply with the Recommendations listed in the GS1 document “EDIINT AS1 and AS2 4799

Transport Communications Guidelines” [EDICG] For reference, the relevant portions of this 4800

document are reproduced below. This extract is marked non-normative; in the case of conflict 4801

between [EDICG] and what is written below, [EDICG] shall prevail. 4802

Digital Certificate Requirements 4803

Requirement 1 4804

Payload data SHALL be encrypted and digitally signed using the S/MIME specification (see RFC 4805

3851). 4806

Requirement 2 4807

The length of the one-time session (symmetric) key SHALL be 128 bits or greater. 4808

Requirement 3 4809

The length of the Public/Private Encryption key SHALL be 1024 bits or greater. 4810

Requirement 4 4811

The length of the Public/Private Signature key SHALL be 1024 bits or greater. 4812

Requirement 5 4813

The Signature Hash algorithm used SHALL be SHA1. 4814

Configuration Requirement 4815

Requirement 6 4816

EPC Information Services (EPCIS) Standard

Digitally signed receipts (Signed Message Disposition Notifications (MDNs)) SHALL be requested by 4817

the Sender of Message. 4818

Recommendations 4819

Recommendation 1 – MDN Request Option 4820

Either Asynchronous or Synchronous MDNs MAY be used with EDIINT AS2. There are potential 4821

issues with both synchronous and asynchronous MDNs, and Trading Partners need to jointly 4822

determine which option is best based on their operational environments and message 4823

characteristics. 4824

Recommendation 2 – MDN Delivery 4825

Recipients SHOULD transmit the MDN as soon as technically possible to ensure that the message 4826

sender recognises that the message has been received and processed by the receiving EDIINT 4827

software in a timely fashion. This applies equally to AS1 and AS2 as well as Asynchronous and 4828

Synchronous MDN requests. 4829

Recommendation 3 – Delivery Retry with Asynchronous MDNs Requested 4830

When a message has been successfully sent, but an asynchronous MDN has not been received in a 4831

timely manner, the Sender of Message SHOULD wait a configurable amount of time and then 4832

automatically resend the original message with the same content and the same Message-ID value 4833

as the initial message. The period of time to wait for a MDN and then automatically resend the 4834

original message is based on business and technical needs, but generally SHOULD be not be less 4835

than one hour. There SHOULD be no more than two automatic resends of a message before 4836

personally contacting a technical support contact at the Receiver of Message site. 4837

Recommendation 4 – Delivery Retry for AS2 4838

Delivery retry SHOULD take place when any HTTP response other than “200 OK” is received (for 4839

example, 401, 500, 502, 503, timeout, etc). This occurrence indicates that the actual transfer of 4840

data was not successful. A delivery retry of a message SHALL have the same content and the same 4841

Message-ID value as the initial message. Retries SHOULD occur on a configurable schedule. 4842

Retrying SHALL cease when a message is successfully sent (which is indicated by receiving a HTTP 4843

200 range status code), or SHOULD cease when a retry limit is exceeded. 4844

Recommendation 5 – Message Resubmission 4845

If neither automated Delivery Retry nor automated Delivery Resend are successful, the Sender of 4846

Message MAY elect to resubmit the payload data in a new message at a later time. The Receiver of 4847

Message MAY also request message resubmission if a message was lost subsequent to a successful 4848

receive. If the message is resubmitted a new Message-ID MUST be used. Resubmission is normally 4849

a manual compensation. 4850

Recommendation 6 – HTTP vs. HTTP/S (SSL) 4851

For EDIINT AS2, the transport protocol HTTP SHOULD be used. However, if there is a need to secure 4852

the AS2-To and the AS2-From addresses and other AS2 header information, HTTPS MAY be used in 4853

addition to the payload encryption provided by AS2. The encryption provided by HTTPS secures only 4854

the point to point communications channel directly between the client and the server. 4855

Recommendation 7 – AS2 Header 4856

For EDIINT AS2, the values used in the AS2-From and AS2-To fields in the header SHOULD be GS1 4857

Global Location Numbers (GLNs). 4858

Recommendation 8 - SMTP 4859

[not applicable] 4860

Recommendation 9 - Compression 4861

EDIINT compression MAY be used as an option, especially if message sizes are larger than 1MB. 4862

Although current versions of EDIINT software handle compression automatically, this SHOULD be 4863

bilaterally agreed between the sender and the receiver. 4864

Recommendation 10 – Digital Certificate Characteristics 4865

EPC Information Services (EPCIS) Standard

Digital certificates MAY either be from a trusted third party or self signed if bilaterally agreed 4866

between trading partners. If certificates from a third party are used, the trust level SHOULD be at a 4867

minimum what is termed ‘Class 2’ which ensures that validation of the individual and the 4868

organisation has been done. 4869

Recommendation 11 – Common Digital Certificate for Encryption & Signature 4870

A single digital certificate MAY be used for both encryption and signatures, however if business 4871

processes dictate, two separate certificates MAY be used. Although current versions of EDIINT 4872

software handle two certificates automatically, this SHOULD be bilaterally agreed between the 4873

sender and the receiver. 4874

Recommendation 12 – Digital Certificate Validity Period 4875

The minimum validity period for a certificate SHOULD be 1 year. The maximum validity period 4876

SHOULD be 5 years. 4877

Recommendation 13 – Digital Certificate – Automated Exchange 4878

The method for certificate exchange SHALL be bilaterally agreed upon. When the “Certificate 4879

Exchange Messaging for EDIINT” specification is widely implemented by software vendors, its use 4880

will be strongly recommended. This IETF specification will enable automated certificate exchange 4881

once the initial trust relationship is established, and will significantly reduce the operational burden 4882

of manually exchanging certificates prior to their expiration. 4883

Recommendation 14 – HTTP and HTTP/S Port Numbers for AS2 4884

Receiving AS2 messages on a single port (for each protocol) significantly minimises operational 4885

complexities such as firewall set-up for both the sending and receiving partner. Ideally, all AS2 4886

partners would receive messages using the same port number. However some AS2 partners have 4887

previously standardised to use a different port number than others and changing to a new port 4888

number would add costs without commensurate benefits. 4889

Therefore AS2 partners MAY standardise on the use of port 4080 to receive HTTP messages and the 4890

use of port 5443 to receive HTTP/S (SSL) messages. 4891

Recommendation 15 – Duplicate AS2 Messages 4892

AS2 software implementations SHOULD use the ‘AS2 Message-ID’ value to detect duplicate 4893

messages and avoid sending the payload from the duplicate message to internal business 4894

applications. The Receiver of Message SHALL return an appropriate MDN even when a message is 4895

detected as a duplicate. Note: The Internet Engineering Task Force (IETF) is developing an 4896

“Operational Reliability for EDIINT AS2” specification which defines procedures to avoid duplicates 4897

and ensure reliability. 4898

Recommendation 15 – Technical Support 4899

There SHOULD be a technical support contact for each Sender of Message and Receiver of Message. 4900

The contact information SHOULD include name, email address and phone number. For 24x7x365 4901

operation, a pager or help desk information SHOULD be also provided. 4902

11.4 Bindings for query callback interface 4903

This section specifies bindings for the Query Callback Interface. Each binding includes a specification 4904

for a URI that may be used as the

dest parameter to the subscribe method of Section 8.2.5. 4905

Each subsection below specifies the conformance requirement (MAY, SHOULD, SHALL) for each 4906

binding. 4907

Implementations MAY support additional bindings of the Query Callback Interface. Any additional 4908

binding SHALL NOT use a URI scheme already used by one of the bindings specified herein. 4909

All destination URIs, whether standardised as a part of this specification or not, SHALL conform to 4910

the general syntax for URIs as defined in [RFC2396]. Each binding of the Query Callback Interface 4911

may impose additional constraints upon syntax of URIs for use with that binding. 4912

EPC Information Services (EPCIS) Standard

11.4.1 General Considerations for all XML-based bindings 4913

The following applies to all XML-based bindings of the Query Callback Interface, including the 4914

bindings specified in Sections 11.4.2, 11.4.3, and 11.4.4. 4915

The payload delivered to the recipient SHALL be an XML document conforming to the schema 4916

specified in Section 11.1. Specifically, the payload SHALL be an EPCISQueryDocument instance 4917

whose

EPCISBody element contains one of the three elements shown in the table below, according 4918

to the method of the Query Callback Interface being invoked: 4919

Query Callback Interface Method Payload Body Contents

callbackResults

QueryResults

callbackQueryTooLargeException

QueryTooLargeException

callbackImplementationException

ImplementationException

4920

In all cases, the

queryName and subscriptionID fields of the payload body element SHALL 4921

contain the

queryName and subscriptionID values, respectively, that were supplied in the call to 4922

subscribe that created the standing query. 4923

11.4.2 HTTP binding of the query callback interface 4924

The HTTP binding provides for delivery of standing query results in XML via the HTTP protocol using 4925

the POST operation. Implementations MAY provide support for this binding. 4926

The syntax for HTTP destination URIs as used by EPCIS SHALL be as defined in [RFC2616], Section 4927

3.2.2. Informally, an HTTP URI has one of the two following forms:

4928

http://host:port/remainder-of-URL 4929

http://host/remainder-of-URL 4930

where 4931

■

host is the DNS name or IP address of the host where the receiver is listening for incoming 4932

HTTP connections. 4933

■

port is the TCP port on which the receiver is listening for incoming HTTP connections. The port 4934

and the preceding colon character may be omitted, in which case the port SHALL default to 80. 4935

■

remainder-of-URL is the URL to which an HTTP POST operation will be directed. 4936

The EPCIS implementation SHALL deliver query results by sending an HTTP POST request to 4937

receiver designated in the URI, where remainder-of-URL is included in the HTTP request-line 4938

(as defined in [RFC2616]), and where the payload is an XML document as specified in 4939

Section 11.4.1

. 4940

The interpretation by the EPCIS implementation of the response code returned by the receiver is 4941

outside the scope of this specification; however, all implementations SHALL interpret a response 4942

code 2xx (that is, any response code between 200 and 299, inclusive) as a normal response, not 4943

indicative of any error. 4944

11.4.3 HTTPS binding of the query callback interface 4945

The HTTPS binding provides for delivery of standing query results in XML via the HTTP protocol 4946

using the POST operation, secured via TLS. Implementations MAY provide support for this binding. 4947

The syntax for HTTPS destination URIs as used by EPCIS SHALL be as defined in [RFC2818], Section 4948

2.4, which in turn is identical to the syntax defined in [RFC2616], Section 3.2.2, with the

4949

substitution of

https for http. Informally, an HTTPS URI has one of the two following forms: 4950

https://host:port/remainder-of-URL 4951

https://host/remainder-of-URL 4952

where 4953

EPC Information Services (EPCIS) Standard

■ host is the DNS name or IP address of the host where the receiver is listening for incoming 4954

HTTP connections. 4955

■

port is the TCP port on which the receiver is listening for incoming HTTP connections. The port 4956

and the preceding colon character may be omitted, in which case the port SHALL default to 443. 4957

■

remainder-of-URL is the URL to which an HTTP POST operation will be directed. 4958

The EPCIS implementation SHALL deliver query results by sending an HTTP POST request to 4959

receiver designated in the URI, where

remainder-of-URL is included in the HTTP request-line 4960

(as defined in [RFC2616]), and where the payload is an XML document as specified in 4961

Section 11.4.1

. 4962

For the HTTPS binding, HTTP SHALL be used over TLS as defined in [RFC2818]. TLS for this purpose 4963

SHALL be implemented as defined in [RFC2246] except that the mandatory cipher suite is 4964

TLS_RSA_WITH_AES_128_CBC_SHA, as defined in [RFC3268] with CompressionMethod.null. 4965

Implementations MAY support additional cipher suites and compression algorithms as desired 4966

The interpretation by the EPCIS implementation of the response code returned by the receiver is 4967

outside the scope of this specification; however, all implementations SHALL interpret a response 4968

code 2xx (that is, any response code between 200 and 299, inclusive) as a normal response, not 4969

indicative of any error. 4970

11.4.4 AS2 Binding of the query callback interface 4971

The AS2 binding provides for delivery of standing query results in XML via AS2 [RFC4130]. 4972

Implementations MAY provide support for this binding. 4973

The syntax for AS2 destination URIs as used by EPCIS SHALL be as follows: 4974

as2:remainder-of-URI 4975

where 4976

■

remainder-of-URI identifies a specific AS2 communication profile to be used by the EPCIS 4977

Service to deliver information to the subscriber. The syntax of

remainder-of-URI is specific to 4978

the particular EPCIS Service to which the subscription is made, subject to the constraint that the 4979

complete URI SHALL conform to URI syntax as defined by [RFC2396]. 4980

Typically, the value of

remainder-of-URI is a string naming a particular AS2 communication 4981

profile, where the profile implies such things as the HTTP URL to which AS2 messages are to be 4982

delivered, the security certificates to use, etc. A client of the EPCIS Query Interface wishing to use 4983

AS2 for delivery of standing query results must pre-arrange with the provider of the EPCIS Service 4984

the specific value of

remainder-of-URI to use. 4985

Non-Normative: Explanation: Use of AS2 typically requires pre-arrangement between 4986

communicating parties, for purposes of certificate exchange and other out-of-band 4987

negotiation as part of a bilateral trading partner agreement (see [RFC4130] Section 5.1). The

4988

remainder-of-URI part of the AS2 URI essentially is a name referring to the outcome of a 4989

particular pre-arrangement of this kind. 4990

The EPCIS implementation SHALL deliver query results by sending an AS2 message in accordance 4991

with [RFC4130]. The AS2 message payload SHALL be an XML document as specified in 4992

Section 11.4.1

. 4993

Both the EPCIS Service and the recipient of standing query results SHALL comply with the 4994

Requirements and SHOULD comply with the Recommendations listed in the GS1 document “EDIINT 4995

AS1 and AS2 Transport Communications Guidelines” [EDICG] For reference, the relevant portions of 4996

this document are reproduced in Section 11.3

. 4997

EPC Information Services (EPCIS) Standard

12 Conformance 4998

The EPCIS standard defines both standard event data and standard interfaces between system 4999

components that communicate event data. Both the data formats and the interfaces may be 5000

implemented by a variety of software and data components in any given system. 5001

This section defines what it means to conform to the EPCIS standard. As there are many types of 5002

system components that have the potential to conform to various parts of the EPCIS standard, they 5003

are enumerated below. In the text that follows, any reference to a section of the EPCIS standard 5004

should be understood to refer to that section in its entirety, including subsections thereof. 5005

12.1 Conformance of EPCIS data 5006

An electronic document is in conformance to the EPCIS standard when all of the following are true: 5007

■ The document is a well-formed XML document conforming to [XML1.0]. 5008

■ The document conforms to the XML schema for EPCISDocument specified in Section 9.5, the 5009

XML schema for

EPCISMasterDataDocument specified in Section 9.7, or the XML schema for 5010

EPCISQueryDocument specified in Section 11.1, as well as all additional constraints specified 5011

in the respective section. 5012

■ All EPCIS event data within the document (if any) conforms to the definitions of EPCIS event 5013

data specified in Section 7 and its subsections. 5014

■ All master data within the document (if any) conforms to the constraints upon master data 5015

specified in Sections 6.1.1, 6.5, and 9.4

. 5016

■ All uses of the extension mechanism (if any) conform to the constraints specified in Section 9.1. 5017

■ If a Standard Business Document Header is present, it conforms to the constraints specified in 5018

Section 9.2

. 5019

Many applications of EPCIS will require, in addition to conformance to the EPCIS standard, that data 5020

conform to the EPCIS Core Business Vocabulary [CBV1.2] standard. The CBV standard defines two 5021

conformance levels termed “CBV Compliant” and “CBV Compatible”. See the CBV standard for 5022

details. 5023

12.2 Conformance of EPCIS capture interface clients 5024

A system is in conformance to the EPCIS standard as a capture interface client when all of the 5025

following are true: 5026

■ The system conforms to all statements appearing in either Section 10.1 or Section 10.2 that are 5027

indicated as pertaining to a “capture client.” 5028

Such a system is said to conform to a particular binding of the capture interface (or more than one 5029

binding) depending on which subsection of Section 10 it conforms to. 5030

12.3 Conformance of EPCIS capture interface servers 5031

A system is in conformance to the EPCIS standard as a capture interface server when all of the 5032

following are true: 5033

■ The system conforms to the statements appearing in Section 8.1

. 5034

■ The system conforms to all statements appearing in either Section 10.1 or Section 10.2 that are 5035

indicated as pertaining to a “capture server.” 5036

■ The system processes the recordTime field in EPCIS events as specified in the table in 5037

Section 7.4.1. 5038

Such a system is said to conform to a particular binding of the capture interface (or more than one 5039

binding) depending on which subsection of Section 10 it conforms to. 5040

EPC Information Services (EPCIS) Standard

12.4 Conformance of EPCIS query interface clients 5041

A system is in conformance to the EPCIS standard as a query interface client when either or both of 5042

the following are true: 5043

■ The system conforms to the definition of a “sender” as specified in [WSI] and sends messages in 5044

conformance to the WSDL specification in Section 11.2. 5045

■ The system conforms to all statements appearing in Section 11.3

that are indicated as 5046

pertaining to a “query client.” 5047

Such a system is said to conform to a particular binding of the query interface (or more than one 5048

binding) depending on which subsection of Section 11 it conforms to. 5049

12.5 Conformance of EPCIS query interface servers 5050

A system is in conformance to the EPCIS standard as a query interface server when all of the 5051

following are true: 5052

■ The system conforms to the statements appearing in Section 8.2. 5053

■ When the system processes a master data query, the returned master data conforms to the 5054

constraints upon master data specified in the first row of the table in Section 6.1.1. 5055

■ The system includes the recordTime field in all EPCIS events returned as query results, as 5056

specified in the table in Section 7.4.1. 5057

■ One or both of the following are true: 5058

□ The system conforms to the definition of a “receiver” as specified in [WSI], receives 5059

messages in conformance to the WSDL specification in Section 11.2, and also conforms to

5060

the additional constraints specified in Section

11.2. 5061

□ The system conforms to all statements appearing in Section 11.3 that are indicated as 5062

pertaining to a “query server.” 5063

Such a system is said to conform to a particular binding of the query interface (or more than one 5064

binding) depending on which subsection of Section 11 it conforms to. 5065

12.6 Conformance of EPCIS query callback interface implementations 5066

A system is in conformance to the EPCIS standard as a query callback interface implementation 5067

when it conforms to the statements appearing in one or more subsections of Section 11.4. Such a 5068

system is said to conform to a particular binding of the query callback interface (or more than one 5069

binding) depending on which subsection it conforms to. 5070

13 References 5071

Normative references: 5072

[ALE1.0] EPCglobal, “The Application Level Events (ALE) Specification, Version 1.0,” EPCglobal 5073

Standard Specification, September 2005, http://www.gs1.org/ale

. 5074

[CBV1.2] GS1, “GS1 Core Business Vocabulary (CBV) Version 1.2 Standard,” GS1 standard, June 5075

2016, http://www.gs1.org/epcis

. 5076

[CEFACT20] United Nations Economic Commission for Europe, “Recommendation 20: Codes for 5077

Units of Measure Used in International Trade,” September 2010, 5078

http://www.unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_Rev7e_2010.zip

. 5079

[EDICG] GS1, “EDIINT AS1 and AS2 Transport Communications Guidelines,” GS1 Technical 5080

Document, February 2006,

http://www.gs1.org/gs1-xml/guideline/ediint-as1-and-as2-transport-5081

communication-guidelines

. 5082

[ISODir2] ISO, “Rules for the structure and drafting of International Standards (ISO/IEC Directives, 5083

Part 2, 2001, 4th edition),” July 2002. 5084

EPC Information Services (EPCIS) Standard

[RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, “Uniform Resource Locators (URL),” RFC 1738, 5085

December 1994, http://www.ietf.org/rfc/rfc1738

. 5086

[RFC2141] R. Moats, “URN Syntax,” Internet Engineering Task Force Request for Comments RFC-5087

2141, May 1997, http://www.ietf.org/rfc/rfc2141.txt

. 5088

[RFC2246] T. Dierks, C. Allen, “The TLS Protocol, Version 1.0,” RFC2246, January 1999, 5089

http://www.ietf.org/rfc/rfc2246

. 5090

[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers (URI): Generic 5091

Syntax,” RFC2396, August 1998, http://www.ietf.org/rfc/rfc2396

. 5092

[RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, 5093

“Hypertext Transfer Protocol -- HTTP/1.1,” RFC2616, June 1999, http://www.ietf.org/rfc/rfc2616

. 5094

[RFC2818] E. Escorla, “HTTP Over TLS,” RFC2818, May 2000, http://www.ietf.org/rfc/rfc2818. 5095

[RFC3268] P. Chown, “Advanced Encryption Standard (AES) Cipersuites for Transport Layer Security 5096

(TLS),” RFC3268, June 2002, http://www.ietf.org/rfc/rfc3268

. 5097

[RFC4130] D. Moberg and R. Drummond, “MIME-Based Secure Peer-to-Peer Business Data 5098

Interchange Using HTTP, Applicability Statement 2 (AS2),” RFC4130, July 2005, 5099

http://www.ietf.org/rfc/rfc4130

. 5100

[SBDH] United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), 5101

“Standard Business Document Header Technical Specification, Version 1.3,” June 2004, 5102

http://www.gs1.org/services/gsmp/kc/ecom/xml/xml_sbdh.html 5103

[TDS1.9] GS1, “GS1 EPCglobal Tag Data Standards Version 1.9,” GS1 standard, June 2014, 5104

http://www.gs1.org/epc/tag-data-standard

5105

[WSDL1.1] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Web Services Description 5106

Language (WSDL) 1.1,” W3C Note, March 2001,

http://www.w3.org/TR/2001/NOTE-wsdl-5107

20010315

. 5108

[WSI] K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri, “Basic Profile Version 5109

1.0,” WS-i Final Material, April 2004,

http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-5110

16.html

. 5111

[XML1.0] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, “Extensible Markup 5112

Language (XML) 1.0 (Third Edition),” W3C Recommendation, February 2004, 5113

http://www.w3.org/TR/2004/REC-xml-20040204/

. 5114

[XMLDR] “XML Design Rules for EAN.UCC, Version 2.0,” February 2004. 5115

[XMLVersioning] D. Orchard, “Versioning XML Vocabularies,” December 2003, 5116

http://www.xml.com/pub/a/2003/12/03/versioning.html

. 5117

[XSD1] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, “XML Schema Part 1: Structures,” 5118

W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/

. 5119

[XSD2] P. Biron, A. Malhotra, “XML Schema Part 2: Datatypes,” W3C Recommendation, May 2001, 5120

http://www.w3.org/TR/xmlschema-2/

. 5121

Non-normative references: 5122

[GS1Arch] “The GS1 System Architecture,” GS1 technical document, April 2015, 5123

http://www.gs1.org/docs/gsmp/architecture/GS1_System_Architecture.pdf

5124

[EPCAF] K. R. Traub et al, “EPCglobal Architecture Framework,” EPCglobal technical document, July 5125

2005,

http://www.epcglobalinc.org/standards/architecture/architecture_1_0-standard-5126

20050701.pdf

5127

[EPCISGuideline] GS1, “EPCIS and CBV Implementation Guideline,” GS1 Guideline, October 2015, 5128

http://www.gs1.org/docs/epc/EPCIS_Guideline.pdf

. 5129

14 Contributors to earlier versions 5130

Below is a list of more active participants and contributors in the development of EPCIS 1.1. This list 5131

does not acknowledge those who only monitored the process or those who chose not to have their 5132

EPC Information Services (EPCIS) Standard

name listed here. The participants listed below generated emails, attended face-to-face meetings 5133

and conference calls that were associated with the development of this Standard.

5134

Name Company

Andrew Kennedy FoodLogiQ (Working group co-chair)

Michele Southall GS1 US (Working group co-chair)

Gena Morgan GS1 (Working group facilitator)

Ken Traub Ken Traub Consulting LLC (Editor)

Craig Alan Repec GS1 Global Office

Jean-Pierre Allard Optel Vision

Romain Arnaud Courbon

Shirley Arsenault GS1 Global Office

Koji Asano GS1 Japan

Karla Biggs-Gregory Oracle

Havard Bjastad TraceTracker AS

Stephan Bourguignon Daimler AG

Bob Bunsey SPEDE Technologies

Birgit Burmeister Daimler AG

Jonas Buskenfried GS1 Sweden

Robert Celeste GS1 US

Chris Chandler GS1 US

Lucy Deus Tracetracker

Hussam El-Leithy GS1 US

Heinz Graf GS1 Switzerland

Anders Grangard GS1 Global

Emmanuel Hadzipetros TraceLink

Mark Harrison Auto-ID Labs

Dave Harty Systech International

Douglas Hill GS1 Denmark

Robert Hotaling Supply Insight

John Howells HDMA

Tany Hui GS1 Hong Kong

Yoshihiko Iwasaki GS1 Japan

Art Kaufmann Frequentz LLC, IBM

John Keogh GS1 Global Office

Janice Kite GS1 Global Office

Steinar Kjærnsrød TraceTracker AS

Jay Kolli Abbott

Jens Kungl METRO Group

Sean Lockhead GS1 Global Office

Paul Lothian Tyson

Dale Moberg Axway

EPC Information Services (EPCIS) Standard

Name Company

Reiko Moritani GS1 Japan

Mark Morris Abbott Laboratories Inc.

Marc-Antoine Mouilleron France Telecom Orange

Alice Mukaru GS1 Sweden

Falk Nieder IBM Germany

Andrew Osbourne GS1 UK

Ted Osinski MET Laboratories

Nicolas Pauvre GS1 France

Cynthia Poetker Abbott Laboratories

Venkataramanan Rajaraman Abbott Laboratories

Craig Alan Repec GS1 Global Office

Chris Roberts GlaxoSmithKline

Ian Robertson Supply Chain RFID Consulting LLC

Dirk Rodgers Dirk Rodgers Consulting, LLC

Thomas Rumbach SAP AG

John Ryu GS1 Global Office

Aravindan Sankaramurthy Oracle

Michael Sarachman GS1 Global Office

Udo Scheffer METRO Group

Frank Schmid IBM (US)

Michael Smith Merck & Co., Inc.

Monika Solanki Aston University

Peter Spellman TraceLink

Steve Tadevich McKesson

Petter Thune-Larsen GS1 Norway

Peter Tomicki Zimmer, Inc.

Ralph Troeger GS1 Germany

Jens Vialkowitsch Robert Bosch GmbH

Geir Vevle HRAFN

Matthew Warren Zimmer, Inc.

David Weatherby GS1 UK

Joachim Wilkens C & A SCS

5135

Below is a list of more active participants and contributors in the development of EPCIS 1.0. This list 5136

does not acknowledge those who only monitored the process or those who chose not to have their 5137

name listed here. The participants listed below generated emails, attended face-to-face meetings 5138

and conference calls that were associated with the development of this Standard.

5139

Name Company

Craig Asher IBM (Co-Chair)

Greg Gibert Verisign (Co-Chair)

Richard Swan T3Ci (Co-Chair)

EPC Information Services (EPCIS) Standard

Name Company

Ken Traub BEA Systems; ConnecTerra (Specification Editor)

Gena Morgan EPCglobal, Inc. (WorkGroup Facilitator)

Chi-Hyeong Ahn Ceyon Technology Co., Ltd

Umair Akeel IBM

John Anderla Kimberly-Clark Corp

Richard Bach Globe Ranger

Scott Barvick Reva Systems

Sylvanus Bent Bent Systems, Inc.

Hersh Bhargava Rafcor

Chet Birger ConnecTerra

Bud Biswas Polaris Networks

Prabhudda Biswas Oracle Corporation

Havard Bjastad Tracetracker

Joe Bohning Nestle Purina

Al Bottner UNITED PARCEL SERVICE (UPS)

Joe Bradley Sun Microsystems

Leo Burstein Gillette; Procter & Gamble

Anit Chakraborty Oracle Corporation

Chia Chang Sun Microsystems

Ying-Hung Chang Acer Cybercenter Service Inc.

Martin Chen SAP

Nagesh Chigurupati VeriSign

Christian Clauss IBM

John Cooper Kimberly-Clark Corp

Valir-Alin Crisan IBM

Mustafa Dohadwala Shipcom Wireless, Inc.

John Duker Procter & Gamble

Igor Elbert Sensitech

Ronny Fehling Oracle Corporation

Akira Fujinami Internet Initiative Japan, Inc.

Tony Gallo Real Time Systems

Manish Gambhir

Cesar Gemayel Sensitech

Eric Gieseke BEA Systems

Greg Gilbert Manhattan Associates

Graham Gillen Verisign

John Gravitis Allumis

Yuichiro Hanawa Mitsui

Mark Harrison Auto-ID Labs - Cambridge

Jeremy Helm ACSIS

EPC Information Services (EPCIS) Standard

Name Company

Barba Hickman Intermec

Manju James BEA Systems

Paul Jatkowski

Jennifer Kahn IBM

Howard Kapustein Manhattan Associates

Sean Lockhead GS1 US

Paul Lovvik Sun Microsystems

Midori Lowe Nippon Telegraph & Telephone Corp (NTT)

Dave Marzouck SAP

Andrew McGrath Manhattan Associates

Michael Mealling Verisign; Refactored Networks

Stephen Miles Auto-ID Labs - MIT

Tim Milne Target

Dale Moberg AXWAY/formerly Cyclone

Stephen Morris Printronix

Ron Moser Wal-Mart

Don Mowery Nestle

Doug Naal Altria Group, Inc./Kraft Foods

David Nesbitt Vue Technology

Shigeki Ohtsu Internet Initiative Japan, Inc.

Ted Osinski MET Labs

Jong Park Tibco

Ju-Hyun Park Samsung SDS

Sung Gong Park Metarights

Eliot Polk Reva Systems

Mike Profit Verisign

Sridhar Ramachandran OAT Systems

Ajay Ramachandron

Karen Randall Johnson & Johnson

Steve Rehling Procter & Gamble

Nagendra Revanur T3Ci Incorporated

Thomas Rumbach SAP

Uday Sadhukhan Polaris Networks

Hares Sangani Hubspan, Inc.

Puneet Sawhney CHEP

Rick Schendel Target

Chris Shabsin BEA Systems

Bhavesh Shah Abbott Laboratories

Harshal Shah Oracle Corporation

Dong Cheul Shin Metarights

Sung-hak Song Samsung SDS

EPC Information Services (EPCIS) Standard

Name Company

Ashley Stephenson Reva Systems

Nikola Stojanovic GS1 US

Jim Sykes Savi Technology

Hiroki Tagato NEC Corporation

Diane Taillard GS1 France

Neil Tan UPS

Zach Thom Unilever

Frank Thompson Afilias Canada Corp

Frank Tittel Gedas Deutschland GmbH

Bryan Tracey Globe Ranger

Hsi-Lin Tsai Acer Cybercenter Service Inc.

Richard Ulrich Walmart

David Unge

Steve Vazzano 1Sync

Vasanth Velusamy Supply Insight, Inc.

Dan Wallace

Jie Wang True Demand Software (fka-Truth Software)

John Williams Auto-ID Labs - MIT

Michael Williams Hewlett-Packard Co. (HP)

Steve Winkler SAP

Katsuyuki Yamashita Nippon Telegraph & Telephone Corp (NTT)

Patrick Yee Hubspan, Inc.

Angela Zilmer Kimberly-Clark Corp

5140