A​p​p​l​i​c​a​t​i​o​n​ ​L​e​v​e​l​ ​E​v​e​n​t​ ​A​L​E​ ​S​t​a​n​d​a​r​d​ ​V​e​r​s​i​o​n​ ​1​.​0


Copyright © 2005 EPCglobal Inc™, All Rights Reserved. Page 1 of 71 1 The Application Level Events (ALE) Specification, 2 Version 1.0 3 4 5 6 7 EPCglobal Ratified Specification 8 Version of September 15, 2005 9 10 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 2 of 71 Abstract 12 This document specifies an interface through which clients may obtain filtered, 13 consolidated Electronic Product Code™ (EPC) data from a variety of sources. The 14 design of this interface recognizes that in most EPC processing systems, there is a level 15 of processing that reduces the volume of data that comes directly from EPC data sources 16 such as RFID readers into coarser “events” of interest to applications. It also recognizes 17 that decoupling these applications from the physical layers of infrastructure offers cost 18 and flexibility advantages to technology providers and end-users alike. 19 The processing done at this layer typically involves: (1) receiving EPCs from one or more 20 data sources such as readers; (2) accumulating data over intervals of time, filtering to 21 eliminate duplicate EPCs and EPCs that are not of interest, and counting and grouping 22 EPCs to reduce the volume of data; and (3) reporting in various forms. The interface 23 described herein, and the functionality it implies, is called “Application Level Events,” or 24 ALE. 25 The role of the ALE interface within the EPCglobal Network™ Architecture is to provide 26 independence between the infrastructure components that acquire the raw EPC data, the 27 architectural component(s) that filter & count that data, and the applications that use the 28 data. This allows changes in one without requiring changes in the other, offering 29 significant benefits to both the technology provider and the end-user. The ALE interface 30 described in the present specification achieves this independence through three means: 31 • It provides a means for clients to specify, in a high-level, declarative way, what EPC 32 data they are interested in, without dictating an implementation. The interface is 33 designed to give implementations the widest possible latitude in selecting strategies 34 for carrying out client requests; such strategies may be influenced by performance 35 goals, the native abilities of readers which may carry out certain filtering or counting 36 operations at the level of firmware or RF protocol, and so forth. 37 • It provides a standardized format for reporting accumulated, filtered EPC data that is 38 largely independent of where the EPC data originated or how it was processed. 39 • It abstracts the sources of EPC data into a higher-level notion of “logical reader,” 40 often synonymous with “location,” hiding from clients the details of exactly what 41 physical devices were used to gather EPC data relevant to a particular logical 42 location. This allows changes to occur at the physical layer (for example, replacing a 43 2-port multi-antenna reader at a loading dock door with three “smart antenna” 44 readers) without affecting client applications. Similarly, it abstracts away the fine-45 grained details of how data is gathered (e.g., how many individual tag read attempts 46 were carried out). These features of abstraction are a consequence of the way the data 47 specification and reporting aspects of the interface are designed. 48 The specification includes a formal processing model, an application programming 49 interface (API) described abstractly via UML, and bindings of the API to a WS-i 50 compliant SOAP protocol with associated bindings of the key data types to XML schema. 51 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 3 of 71 Implementors may provide other bindings, as well as extensions, as provided by the 52 framework of the specification. 53 Audience for this document 54 The target audience for this specification includes: 55 • EPC Middleware vendors 56 • Reader vendors 57 • Application developers 58 • System integrators 59 Status of this document 60 This section describes the status of this document at the time of its publication. Other 61 documents may supersede this document. The latest status of this document series is 62 maintained at EPCglobal. See www.epcglobalinc.org for more information. 63 This version of the specification was ratified by the EPCglobal Board of Governors on 64 September 23, 2005. It was reviewed and approved by the EPCglobal Business Steering 65 Committee on 14 February 2005 and by the Technical Steering Committee on 2 February 66 2005. 67 Comments on this document should be sent to the EPCglobal Software Action Group 68 Filtering and Collection Working Group mailing list 69 sag_fc@epclinklist.epcglobalinc.org. 70 Table of Contents 71 1 Introduction ..................................................................................................................6 72 2 Role Within the EPCglobal Network Architecture...................................................... 7 73 3 Terminology and Typographical Conventions............................................................. 9 74 4 ALE Formal Model ...................................................................................................... 9 75 5 Group Reports............................................................................................................ 13 76 6 Read Cycle Timing..................................................................................................... 13 77 7 Logical Reader Names ............................................................................................... 14 78 8 ALE API..................................................................................................................... 16 79 8.1 ALE – Main API Class........................................................................................ 18 80 8.1.1 Error Conditions............................................................................................20 81 8.2 ECSpec ................................................................................................................ 22 82 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 4 of 71 8.2.1 ECBoundarySpec.......................................................................................... 23 83 8.2.2 ECTime......................................................................................................... 25 84 8.2.3 ECTimeUnit.................................................................................................. 25 85 8.2.4 ECTrigger ..................................................................................................... 25 86 8.2.5 ECReportSpec............................................................................................... 25 87 8.2.6 ECReportSetSpec.......................................................................................... 27 88 8.2.7 ECFilterSpec................................................................................................. 27 89 8.2.8 EPC Patterns (non-normative) ...................................................................... 27 90 8.2.9 ECGroupSpec ............................................................................................... 28 91 8.2.10 ECReportOutputSpec ................................................................................ 31 92 8.2.11 Validation of ECSpecs............................................................................... 32 93 8.3 ECReports............................................................................................................ 33 94 8.3.1 ECTerminationCondition.............................................................................. 34 95 8.3.2 ECReport....................................................................................................... 34 96 8.3.3 ECReportGroup ............................................................................................ 35 97 8.3.4 ECReportGroupList ...................................................................................... 35 98 8.3.5 ECReportGroupListMember......................................................................... 36 99 8.3.6 ECReportGroupCount................................................................................... 37 100 9 Standard Notification URIs........................................................................................ 37 101 9.1 HTTP Notification URI....................................................................................... 37 102 9.2 TCP Notification URI.......................................................................................... 38 103 9.3 FILE Notification URI......................................................................................... 38 104 10 XML Schema for Event Cycle Specs and Reports ................................................. 39 105 10.1 Extensibility Mechanism.................................................................................. 39 106 10.2 Schema ............................................................................................................. 42 107 10.3 ECSpec – Example (non-normative)................................................................ 49 108 10.4 ECReports – Example (non-normative)........................................................... 49 109 11 SOAP Binding for ALE API................................................................................... 50 110 11.1 SOAP Binding.................................................................................................. 50 111 12 Use Cases (non-normative)..................................................................................... 61 112 13 ALE Scenarios (non-normative)............................................................................. 63 113 13.1 ALE Context.................................................................................................... 63 114 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 5 of 71 13.2 Scenarios .......................................................................................................... 64 115 13.2.1 Scenario 1a: Direct Subscription ............................................................... 65 116 13.2.1.1 Assumptions........................................................................................... 65 117 13.2.1.2 Description............................................................................................. 66 118 13.2.2 Scenario 1b: Indirect Subscription ............................................................ 66 119 13.2.2.1 Assumptions........................................................................................... 67 120 13.2.2.2 Description............................................................................................. 67 121 13.2.3 Scenario 2, 3: Poll, Immediate................................................................... 68 122 13.2.3.1 Assumptions........................................................................................... 68 123 13.2.3.2 Description............................................................................................. 69 124 14 Glossary (non-normative) ....................................................................................... 69 125 15 References............................................................................................................... 70 126 127 128 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 6 of 71 1 Introduction 129 This document specifies an interface through which clients may obtain filtered, 130 consolidated EPC data from a variety of sources. The design of this interface recognizes 131 that in most EPC processing systems, there is a level of processing that reduces the 132 volume of data that comes directly from EPC data sources such as RFID readers into 133 coarser “events” of interest to applications. It also recognizes that decoupling these 134 applications from the physical layers of infrastructure offers cost and flexibility 135 advantages to technology providers and end-users alike. 136 The processing done at this layer typically involves: (1) receiving EPCs from one or more 137 data sources such as readers; (2) accumulating data over intervals of time, filtering to 138 eliminate duplicate EPCs and EPCs that are not of interest, and counting and grouping 139 EPCs to reduce the volume of data; and (3) reporting in various forms. The interface 140 described herein, and the functionality it implies, is called “Application Level Events,” or 141 ALE. 142 In early versions of the EPCglobal Network Architecture, originating at the Auto-ID 143 Center at the Massachussetts Institute of Technology (MIT), these functions were 144 understood to be part of a specific component termed “Savant.” The term “Savant” has 145 been variously used to refer generically to any software situated between RFID readers 146 and enterprise applications, or more specifically to a particular design for such software 147 as described by an MIT Auto-ID Center document “The Savant Specification Version 148 0.1” [Savant0.1] or to a later effort by the Auto-ID Center Software Action Group 149 [Savant1.0] that outlined a generalized container framework for such software. Owing to 150 the confusion surrounding the term, the word “Savant” has been deprecated by 151 EPCglobal in favor of more definite specifications of particular functionality. The 152 interface described herein is the first such definite specification. 153 The role of the ALE interface within the EPCglobal Network Architecture is to provide 154 independence between the infrastructure components that acquire the raw EPC data, the 155 architectural component(s) that filter & count that data, and the applications that use the 156 data. This allows changes in one without requiring changes in the other, offering 157 significant benefits to both the technology provider and the end-user. The ALE interface 158 described in the present specification achieves this independence through three means: 159 • It provides a means for clients to specify, in a high-level, declarative way, what EPC 160 data they are interested in, without dictating an implementation. The interface is 161 designed to give implementations the widest possible latitude in selecting strategies 162 for carrying out client requests; such strategies may be influenced by performance 163 goals, the native abilities of readers which may carry out certain filtering or counting 164 operations at the level of firmware or RF protocol, and so forth. 165 • It provides a standardized format for reporting accumulated, filtered EPC data that is 166 largely independent of where the EPC data originated or how it was processed. 167 • It abstracts the sources of EPC data into a higher-level notion of “logical reader,” 168 often synonymous with “location,” hiding from clients the details of exactly what 169 physical devices were used to gather EPC data relevant to a particular logical 170 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 7 of 71 location. This allows changes to occur at the physical layer (for example, replacing a 171 2-port multi-antenna reader at a loading dock door with three “smart antenna” 172 readers) without affecting client applications. Similarly, it abstracts away the fine-173 grained details of how data is gathered (e.g., how many individual tag read attempts 174 were carried out). These features of abstraction are a consequence of the way the data 175 specification and reporting aspects of the interface are designed. 176 Unlike the earlier MIT “Savant Version 0.1” effort, the present specification does not 177 specify a particular implementation strategy, or internal interfaces within a specific body 178 of software. Instead, this specification focuses exclusively on one external interface, 179 admitting a wide variety of possible implementations so long as they fulfill the contract 180 of the interface. For example, it is possible to envision an implementation of this 181 interface as an independent piece of software that speaks to RFID readers using their 182 network wireline protocols. It is equally possible, however, to envision another 183 implementation in which the software implementing the interface is part of the reader 184 device itself. 185 2 Role Within the EPCglobal Network Architecture 186 EPC technology, especially when implemented using RFID, generates a very large 187 number of object reads throughout the supply chain and eventually into consumer usage. 188 Many of those reads represent non-actionable “noise.” To balance the cost and 189 performance of this with the need for clear accountability and interoperability of the 190 various parts, the design of the EPCglobal Network Architecture seeks to: 191 1. Drive as much filtering and counting of reads as low in the architecture as possible 192 (i.e., in first preference to readers, then to “middleware”, and as a last resort to 193 “applications”), while meeting application and cost needs; 194 2. At the same time, minimize the amount of “business logic” embedded in the Tags, 195 Readers and middleware, where business logic is either data or processing logic that 196 is particular to an individual product, product category, industry or business process. 197 The Application Level Events (ALE) interface specified herein is intended to facilitate 198 these objectives by providing a flexible interface to a standard set of accumulation, 199 filtering, and counting operations that produce “reports” in response to client “requests.” 200 The client will be responsible for interpreting and acting on the meaning of the report 201 (i.e., the “business logic”). The client of the ALE interface may be a traditional 202 “enterprise application,” or it may be new software designed expressly to carry out an 203 EPC-enabled business process but which operates at a higher level than the “middleware” 204 that implements the ALE interface. Hence, the term “Application Level Events” should 205 not be misconstrued to mean that the client of the ALE interface is necessarily a 206 traditional “enterprise application.” 207 The ALE interface revolves around client requests and the corresponding reports that are 208 produced. Requests can either be: (1) immediate, in which information is reported on a 209 one-time basis at the time of the request; or (2) recurring, in which information is 210 reported repeatedly whenever an event is detected or at a specified time interval. The 211 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 8 of 71 results reported in response to a request can be directed back to the requesting client or to 212 a “third party” specified by the requestor. 213 This reporting API can be viewed as the interface to a 214 layer of functionality that sits between raw EPC 215 detection events (RFID tag reads or otherwise) and 216 application business logic. We refer to this layer as 217 the Application Level Event (ALE) layer. Note that 218 this document does not specify where ALE-level 219 processing takes place: it could take place within 220 independent software “middleware,” within a suitably 221 capable reader, or some combination, though always 222 with the ALE interface serving as a point of interface 223 to the client. Even when implemented as software 224 middleware, the filtering, counting, and other 225 processing requested by a client may be carried out within the software, or pushed into 226 the readers or other devices. This aspect of the ALE specification is intended explicitly 227 to give freedom to implementers, and to provide a way to take full advantage of a range 228 of reader capabilities (while at the same time avoiding clients from needing to understand 229 the details of those capabilities). 230 In many cases, the client of ALE will be software that incorporates the EPC Information 231 Service (EPCIS), or other business processing software. Since EPCIS is another 232 component of the EPCglobal Network Architecture that deals with higher-level EPC 233 events, it is helpful to understand how ALE differs from EPCIS and other software at 234 higher levels of the architecture. The principal differences are: 235 • The ALE interface is exclusively oriented towards real-time processing of EPC data, 236 with no persistent storage of EPC data required by the interface (though 237 implementations may employ persistent storage to provide resilience to failures). 238 Business applications, in contrast, typically deal explicitly with historical data and 239 hence are inherently persistent in nature. 240 • The events communicated through the ALE interface are pure statements of “what, 241 where, and when,” with no business semantics expressed. Business applications, and 242 typically EPCIS-level data, does embed business semantics at some level. For 243 example, at the ALE level, there might be an event that says “at location L, in the 244 time interval T1–T2, the following 100 case-level EPCs and one pallet-level EPC 245 were read.” Within a business application, the corresponding statement might be “at 246 location L, at time T2, it was confirmed that the following 100 cases were aggregated 247 onto the following pallet.” The business-level event, while containing essentially the 248 same EPC data as the ALE event, is at a semantically higher level because it 249 incorporates an understanding of the business process in which the EPC data were 250 obtained. 251 The distinction between the ALE and EPCIS/business layers is useful because it separates 252 concerns. The ALE layer is concerned with dealing with the mechanics of data 253 gathering, and of filtering down to meaningful events that are a suitable starting point for 254 interpretation by business logic. Business layers are concerned with business process, 255 Application Business Logic Application Level Event (ALE) Layer Raw Tag Read Layer Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 9 of 71 and recording events that can serve as the basis for a wide variety of enterprise-level 256 information processing tasks. Within this general framework, there is room for many 257 different approaches to designing systems to meet particular business goals, and it is 258 expected that there will not necessarily be one “right” way to construct systems. Thus, 259 the focus in this specification is not on a particular system architecture, but on creating a 260 very well defined interface that will be useful within a variety of designs. 261 ¾ A reference to the EPCglobal Network Architecture document should be inserted 262 when EPCglobal publishes such a document. 263 3 Terminology and Typographical Conventions 264 Within this specification, the terms SHALL, SHALL NOT, SHOULD, SHOULD NOT, 265 MAY, NEED NOT, CAN, and CANNOT are to be interpreted as specified in Annex G of 266 the ISO/IEC Directives, Part 2, 2001, 4th edition [ISODir2]. When used in this way, 267 these terms will always be shown in ALL CAPS; when these words appear in ordinary 268 typeface they are intended to have their ordinary English meaning. 269 All sections of this document, with the exception of Section 1 and Section 2, are 270 normative, except where explicitly noted as non-normative. 271 The following typographical conventions are used throughout the document: 272 • ALL CAPS type is used for the special terms from [ISODir2] enumerated above. 273 • Monospace type is used to denote programming language, UML, and XML 274 identifiers, as well as for the text of XML documents. 275 ¾ Placeholders for changes that need to be made to this document prior to its reaching 276 the final stage of approved EPCglobal specification are prefixed by a rightward-277 facing arrowhead, as this paragraph is. 278 4 ALE Formal Model 279 Within this specification, the term “Reader” is used to refer to a source of raw EPC data 280 events. An extremely common type of source, of course, is an actual RFID reader, which 281 generates EPC data by using an RF protocol to read EPC codes from RFID tags. But a 282 Reader could just as easily be an EPC-compatible bar code reader, or even a person 283 typing on a keyboard. Moreover, Readers as used in this specification may not 284 necessarily be in one-to-one correspondence with hardware devices; this is explored in 285 more depth in Section 7. Hence, the term “Reader” is just a convenient shorthand for 286 “raw EPC data event source.” When used in this special sense, the word Reader will 287 always be capitalized. For purposes of discussion, it will sometimes be necessary to 288 speak of tags moving within the detection zone of a Reader; while this terminology is 289 directly germane to RFID readers, it should be obvious what the corresponding meaning 290 would be for other types of Readers. 291 A read cycle is the smallest unit of interaction with a Reader. The result of a read cycle 292 is a set of EPCs. In the case of an RFID reader antenna, the EPCs in a read cycle are 293 sometimes those obtained in a single operation of the reader’s RF protocol, though this is 294 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 10 of 71 not necessarily the case. The output of a read cycle is the input to the ALE layer; i.e., it is 295 the interface between the Raw Tag Read Layer and the ALE Layer in the diagram of 296 Section 2. As was noted earlier, this interface could be an actual software or network 297 interface between a reader device and a middleware implementation, but this is not 298 necessarily the case. From the ALE perspective, a read cycle is a single event containing 299 a set of EPCs, with nothing more implied. 300 An event cycle is one or more read cycles, from one or more Readers that are to be 301 treated as a unit from a client perspective. It is the smallest unit of interaction between 302 the ALE interface and a client. Referring to the diagram of Section 2, clients in the 303 Application Business Logic Layer specify the boundaries of event cycles to the ALE 304 layer as part of a request for a report. 305 A report is data about an event cycle communicated from the ALE implementation to a 306 client. The report is the output of the ALE layer, communicated to the Application 307 Business Logic Layer. 308 As tags or other carriers of EPC data move in and out of the detection zone of a Reader, 309 the EPCs reported in each read cycle change. Within an event cycle, the same tag may be 310 read several times (if the tag remains within the detection zone of any of the Readers 311 specified for that event cycle). Section 8.2.1 specifies how event cycle boundaries may: 312 • Extend for a specified duration (interval of real time); e.g., accumulate reads into 313 five-second intervals. 314 • Occur periodically; e.g., report only every 30 minutes, regardless of the read cycle. 315 • Be triggered by external events; e.g., an event cycle starts when a pallet on a conveyer 316 triggers an electric eye upstream of a portal, and ends when it crosses a second 317 electric eye downstream of a portal. 318 • Be delimited when no new EPCs are detected by any Reader specified for that event 319 cycle for a specified interval of time. 320 • Simply be every read cycle. (This possibility is not provided for in Section 8.2, but 321 may be available through vendor extensions.) 322 A client must specify one of these methods when requesting a report. (The complete set 323 of available options is described normatively in Section 8.2.1.) 324 The net picture looks something like this: 325 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 11 of 71 326 While the diagram shows read cycles arising from a single Reader, in practice a given 327 event cycle may collect read cycles from more than one Reader. As the diagram 328 suggests, there may be more than one active event cycle at any point in time. Multiple 329 active event cycles may start and end with different read cycles, and may overlap in 330 arbitrary ways. They may gather data from the same Readers, from different Readers, or 331 from arbitrarily overlapping sets of Readers. Multiple active event cycles could arise 332 from one client making several simultaneous requests, or from independent clients. In all 333 cases, however, the same read cycles are shared by all active event cycles that request 334 data from a given Reader. 335 The set of EPCs in a given read cycle from a given Reader is denoted by S. In the picture 336 above, S1 = {EPC1, EPC2, EPC3} and S2 = {EPC1, EPC2, EPC4}. 337 An event cycle is treated as a unit by clients, so clients do not see any of the internal 338 structure of the event cycle. All that is relevant, therefore, is the complete set of EPCs 339 occurring in any of the read cycles that make up the event cycle, from any of the Readers 340 in the set specified for the event cycle, with duplicates removed. This is simply the union 341 of the read cycle sets: E = S1 U S2 U …. In the example above for Client 1 Event 342 Cycle 1 we have E1.1 = {EPC1, EPC2, EPC3, EPC4, EPC5}. 343 Clients get information about event cycles through reports. A report is specified by a 344 combination of these three parameters: 345 • What set R to report, which may be 346 • The complete set from the current event cycle R = Ecur; or 347 Read Cycle 2 Read Cycle 3 EPC1 EPC2 EPC3 EPC1 EPC2 EPC4 EPC3 EPC5 Read Cycle 1 Client 1 Event Cycle 1 Report Report Read Cycle 5 Read Cycle 6 EPC3 EPC4 EPC3 EPC5 Read Cycle 4 Report Report EPC5 EPC3 EPC5 Read Cycle 7 EPC3 EPC5 Client 2 Event Cycle 1 Client 3 Event Cycle 1 Client 2 Event Cycle 2 Report Report Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 12 of 71 • The differential set that only includes differences of the current event cycle 348 relative to the previous one (assuming the same event cycle boundaries). This can 349 be the set of additions R = (Ecur – Eprev) or the set of deletions R = (Eprev – 350 Ecur), where ‘–’ denotes the set difference operator. 351 • An optional filter F(R) to apply, including as part of the standard ALE interface: 352 • One or more object types derived from the “filter bits” of the EPC Tag Data 353 Standard [TDS1.1], including “product” objects (e.g., pallet, case, etc.) as well as 354 “location” objects (e.g., warehouse slots, trucks, retail shelves, etc., that contain 355 embedded EPC tags) 356 • A specific list of EPCs 357 • A range of EPCs 358 • Whether to report 359 • The members of the set, F(R) (i.e., the EPCs themselves), possibly grouped as 360 described in Section 5, and in what format (e.g., pure identity URI, tag URI, raw 361 binary, etc); 362 • The quantity, or cardinality, of the set |F(R)|, or of the groups making up the set as 363 described in Section 5. 364 The available options are described normatively in Section 8.2. 365 A client may require more than one report from a given event cycle; e.g., a smart shelf 366 application may require both an additions report and a deletions report. 367 This all adds up to an ALE Layer API in which the primary interaction involves: (1) a 368 client specifying: (a) one or more Readers (this is done indirectly, as explained in 369 Section 7) (b) event cycle boundaries as enumerated above, and (c) a set of reports as 370 defined above; and (2) the ALE Layer responding by returning the information implied 371 by that report specification for one or more event cycles. This may be done in a “pull” 372 mode, where the client asks for a report or reports (also specifying how the event cycle is 373 to be delimited) and the ALE Layer in turn initiates or waits for read events, filters/counts 374 the data, and returns the report(s). It may also be done in a “push” mode, where the client 375 registers a subscription with a report set and event cycle boundary specification, and 376 thereafter the ALE Layer asynchronously sends reports to the client when event cycles 377 complete. The complete details of the API, the information required to specify an event 378 cycle, and the information returned to the client when an event cycle completes are 379 spelled out in Sections 8.1, 8.2, and 8.3, respectively. Examples of an event cycle 380 specification and event cycle reports in XML are given in Section 10. 381 Note that because the filtering operations commute with the set union and difference 382 operations, there is a great deal of freedom in how an ALE implementation actually 383 carries out the task of fulfilling a report request. For example, in one implementation, 384 there may be a Reader that is capable of doing filtering directly within the Reader, while 385 in a second implementation the Reader may not be capable of filtering and so software 386 implementing the ALE API must do it. But the ALE API itself need not change – the 387 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 13 of 71 client specifies the reports, and the implementation of the API decides where best to carry 388 out the requested filtering. 389 5 Group Reports 390 Sometimes it is useful to group EPCs read during an event cycle based on portions of the 391 EPC or attributes of the objects identified by the EPCs. For example, in a shipment 392 receipt verification application, it is useful to know the quantity of each type of case (i.e., 393 each distinct case GTIN), but not necessarily the serial number of each case. This 394 requires slightly more complex processing, based on the notion of a grouping operator. 395 A grouping operator is a function G that maps an EPC code into some sort of group 396 code g. For example, a grouping operator might map an EPC code into a GTIN group, or 397 simply into the upper bits (manufacturer and product) of the EPC. Other grouping 398 operators might be based on other information available on an EPC tag, such as the filter 399 code that implies the type of object (i.e., pallet, case, item, etc.). 400 The notation S↓g means the subset of EPCs s1, s2, … in the set S that belong to group g. 401 That is, S↓g ≡ { s in S | G(s) = g }. 402 A group membership report for grouping operator G is a set of pairs, where the first 403 element in each pair is a group name g, and the second element is the list of EPCs that 404 fall into that group, i.e., S↓g. 405 A group cardinality report is similar, but instead of enumerating the EPCs in each group, 406 the group cardinality report just reports how many of each there are. That is, the group 407 cardinality report for grouping operator G is a set of pairs, where the first element in each 408 pair is a group name g, and the second element is the number of EPCs that fall into that 409 group, i.e., |S↓g|. 410 Formally, then, the reporting options from the last section are: 411 • Whether to report 412 • A group membership (group list) report for one or more specified grouping 413 operators Gi, which may include, and may possibly be limited to, the default 414 (unnamed) group. In mathematical notation: { (g, F(R)↓g) | F(R)↓g is non-empty 415 }. 416 • A group cardinality (group count) report for one or more specified grouping 417 operators Gi, which may include, and may possibly be limited to, the default 418 (unnamed) group. In mathematical notation: { (g, |F(R)↓g|) | F(R)↓g is non-419 empty }. 420 6 Read Cycle Timing 421 The ALE API is intentionally silent about the timing of read cycles. Clients may specify 422 the boundaries of event cycles, which accumulate data from one or more underlying read 423 cycles, but the API does not provide a client with explicit control over the frequency at 424 which read cycles are completed. There are several reasons for this: 425 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 14 of 71 • A client or clients may make simultaneous requests for event cycle reports that may 426 have differing event cycle boundaries and different report specifications. In this case, 427 clients must necessarily share a common view of when and how frequently read 428 cycles take place. Specifying the read cycle frequency outside of any event cycle 429 request insures that clients cannot make contradictory demands on read cycles. 430 • In cases where there are many readers in physical proximity (perhaps communicating 431 to different ALE implementations), the read cycle frequency must be carefully tuned 432 and coordinated to avoid reader interference. This coordination generally requires 433 physical-level information that generally would be (and should be) unknown to a 434 client operating at the ALE level. 435 • The ALE API is designed to provide access to data from a wide variety of “Reader” 436 sources, which may have very divergent operating principles. If the ALE API were to 437 provide explicit control over read cycle timing, it would necessarily make 438 assumptions about the source of read cycle data that would limit its applicability. For 439 example, if the ALE API were to provide a parameter to clients to set the frequency 440 of read cycles, it would assume that every Reader provides data on a fixed, regular 441 schedule. 442 In light of these considerations, there is no standard way provided by ALE for clients to 443 control read cycle timing. Implementations of ALE may provide different means for this, 444 e.g., configuration files, administrative interfaces, and so forth. 445 Regardless of how a given ALE implementation provides for the configuration of read 446 cycle timing, the ALE implementation always has the freedom to suspend Reader activity 447 during periods when no event cycles requiring data from a given Reader are active. 448 7 Logical Reader Names 449 In specifying an event cycle, an ALE client names one or more Readers of interest. This 450 is usually necessary, as an ALE implementation may manage many readers that are used 451 for unrelated purposes. For example, in a large warehouse, there may be ten loading 452 dock doors each having three RFID readers; in such a case, a typical ALE request may be 453 directed at the three readers for a particular door, but it is unlikely that an application 454 tracking the flow of goods into trucks would want the reads from all 30 readers to be 455 combined into a single event cycle. 456 This raises the question of how ALE clients specify which reader devices are to be used 457 for a given event cycle. One possibility is to use identities associated with the reader 458 devices themselves, e.g., a unique name, serial number, EPC, IP address, etc. This is 459 undesirable for several reasons: 460 • The exact identities of reader devices deployed in the field are likely to be unknown 461 at the time an application is authored and configured. 462 • If a reader device is replaced, this unique reader device identity will change, forcing 463 the application configuration to be changed. 464 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 15 of 71 • If the number of reader devices must change – e.g., because it is discovered that four 465 reader devices are required instead of three to obtain adequate coverage of a 466 particular loading dock door – then the application must be changed. 467 To avoid these problems, ALE introduces the notion of a “logical reader.” Logical 468 readers are abstract names that a client uses to refer to one or more Readers that have a 469 single logical purpose; e.g., DockDoor42. Within the implementation of ALE, an 470 association is maintained between logical names such as DockDoor42 and the physical 471 reader devices assigned to fulfill that purpose. Any ALE event cycle specification that 472 refers to DockDoor42 is understood by the ALE implementation to refer to the physical 473 reader (or readers) associated with that name. 474 Logical names may also be used to refer to sources of raw EPC events that are 475 synthesized from various sources. For example, one vendor may have a technology for 476 discriminating the physical location of tags by triangulating the results from several 477 reader devices. This could be exposed in ALE by assigning a synthetic logical reader 478 name for each discernable location. 479 Different ALE implementations may provide different ways of mapping logical names to 480 physical reader devices, synthetic readers, and other sources of EPC events. This is a key 481 extensibility point. At a minimum, however, all ALE implementations SHOULD provide 482 a straightforward way to map a logical name to a list of read event sources, and where 483 physical readers allow for independent control over multiple antennas and multiple tag 484 protocols, each combination of (reader, antenna, protocol) should be treated as a separate 485 read event source for this purpose. To illustrate, an ALE implementation may maintain a 486 table like this: 487 Physical Reader Devices Logical Reader Name Reader Name Antenna Protocol Acme42926 0 UHF Acme42926 1 UHF DockDoor42 Acme43629 0 UHF Acme44926 0 UHF Acme44926 1 UHF DockDoor43 Acme49256 0 UHF 488 (It must be emphasized that the table above is meant to be illustrative of the kind of 489 configuration data an ALE implementation might maintain, not a normative specification 490 of what configuration data an ALE implementation must maintain.) 491 More elaborate implementations of ALE, such as those that provide synthesized logical 492 readers such as the triangulation example above, will require more elaborate 493 configuration data. Tables of this kind may be established through static configuration, 494 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 16 of 71 or through more dynamic discovery mechanisms. The method for establishing and 495 maintaining configuration of this kind is outside the scope of this specification. 496 To summarize, the definition of ALE relies upon several related concepts: 497 • A logical reader is a name that an ALE client uses to refer to one or more, raw EPC 498 data event sources (“Readers”). In terms of the formal model of Section 3, an event 499 cycle aggregates read cycle data from all of the Readers that are associated with the 500 set of logical readers the ALE client specifies in its request. 501 • A Reader is a raw EPC data event source. A Reader provides EPC data to an ALE 502 implementation in a series of read cycles, each containing a list of EPCs. A Reader 503 may map into physical devices in a variety of ways, including: 504 • A Reader may map directly to a single physical device; e.g., a one-antenna RFID 505 reader, a bar code scanner, or a multi-antenna RFID reader where data from all 506 antennas is always combined. 507 • Several Readers may map to the same physical device; e.g., a multi-antenna RFID 508 reader where each antenna is treated as an independent source (in which case 509 there would be a separate Reader for each antenna). 510 • A Reader may map to more than one physical device; e.g., several RFID devices 511 are used to triangulate location information to create synthesized read cycles for 512 virtual “Readers” associated with different spatial zones. 513 8 ALE API 514 This section defines normatively the programmatic interface to ALE. The external 515 interface is defined by the ALE class (Section 8.1). This interface makes use of a number 516 of complex data types that are documented in the sections following Section 8.1. 517 Implementations may expose the ALE interface via a wire protocol, or via a direct API in 518 which clients call directly into code that implements ALE. This section of the document 519 does not define the concrete wire protocol or programming language-specific API, but 520 instead defines only the abstract syntax. Section 11 of the document specifies the 521 required binding of the API to a WS-i compliant SOAP protocol. Section 10 specifies the 522 standard way in which the two major data types in this API, the Event Cycle 523 Specification and the Event Cycle Report, are rendered in XML. Implementations may 524 provide additional bindings of the API, including bindings to particular programming 525 languages, and of the data types. 526 The general interaction model is that there are one or more clients that make method calls 527 to the ALE interface defined in Section 8.1. Each method call is a request, which causes 528 the ALE implementation to take some action and return results. Thus, methods of the 529 ALE interface are synchronous. 530 The ALE interface also provides a way for clients to subscribe to events that are delivered 531 asynchronously. This is done through methods that take a notificationURI as an 532 argument. Such methods return immediately, but subsequently the ALE implementation 533 may asynchronously deliver information to the consumer denoted by the 534 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 17 of 71 notificationURI. Different ALE implementations MAY provide a variety of 535 available notification means (e.g., JMS, MQ-Series, TIBCO, e-mail, SOAP, etc.); this is 536 intended to be a point of extensibility. Section 9 specifies notification means that are 537 standardized, and specifies the conformance requirement (MAY, SHOULD, SHALL) for 538 each. 539 In the sections below, the API is described using UML class diagram notation, like so: 540 dataMember1 : Type1 541 dataMember2 : Type2 542 --- 543 method1(ArgName:ArgType, ArgName:ArgType, …) : ReturnType 544 method2(ArgName:ArgType, ArgName:ArgType, …) : ReturnType 545 Within the UML descriptions, the notation <> identifies a place 546 where implementations SHALL provide for extensibility through the addition of new 547 data members and/or methods. Extensibility mechanisms SHALL provide for both 548 proprietary extensions by vendors of ALE-compliant products, and for extensions defined 549 by EPCglobal through future versions of this specification or through new specifications. 550 In the case of the standard XML bindings for ECSpec and ECReports, the extension 551 points are implemented within the XML schema following the methodology described in 552 Section 10.1. In the case of the standard SOAP binding for the ALE interface, the 553 extension point is implemented simply by adding new operations to the WSDL. 554 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 18 of 71 8.1 ALE – Main API Class 555 --- 556 define(specName:string, spec:ECSpec) : void 557 undefine(specName:string) : void 558 getECSpec(specName:string) : ECSpec 559 getECSpecNames() : List // returns a list of specNames as 560 strings 561 subscribe(specName:string, notificationURI:string) : void 562 unsubscribe(specName:string, notificationURI:string) : void 563 poll(specName:string) : ECReports 564 immediate(spec:ECSpec) : ECReports 565 getSubscribers(specName:String) : List // of notification 566 URIs 567 getStandardVersion() : string 568 getVendorVersion() : string 569 <> 570 An ECSpec is a complex type that defines how an event cycle is to be calculated. There 571 are two ways to cause event cycles to occur. A standing ECSpec may be posted using 572 the define method. Subsequently, one or more clients may subscribe to that ECSpec 573 using the subscribe method. The ECSpec will generate event cycles as long as there 574 is at least one subscriber. A poll call is like subscribing then unsubscribing 575 immediately after one event cycle is generated (except that the results are returned from 576 poll instead of being sent to a notificationURI). The second way is that an 577 ECSpec can be posted for immediate execution using the immediate method. This is 578 equivalent to defining an ECSpec, performing a single poll operation, and then 579 undefining it. 580 The execution of ECSpecs is defined formally as follows. An ECSpec is said to be 581 requested if any of the following is true: 582 • It has previously been defined using define, it has not yet been undefined, and 583 there has been at least one subscribe call for which there has not yet been a 584 corresponding unsubscribe call. 585 • It has previously been defined using define, it has not yet been undefined, a 586 poll call has been made, and the first event cycle since the poll was received has 587 not yet been completed. 588 • It was defined using the immediate method, and the first event cycle has not yet 589 been completed. 590 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 19 of 71 Once requested, an ECSpec is said to be active if reads are currently being accumulated 591 into an event cycle based on the ECSpec. Standing ECSpecs that are requested using 592 subscribe may transition between active and inactive multiple times. ECSpecs that 593 are requested using poll or created using immediate will transition between active 594 and inactive just once (though in the case of poll, the ECSpec remains defined 595 afterward so that it could be subsequently polled again or subscribed to). 596 This description is summarized in the state diagram below. 597 598 The primary data types associated with the ALE API are the ECSpec, which specifies 599 how an event cycle is to be calculated, and the ECReports, which contains one or more 600 reports generated from one activation of an ECSpec. ECReports instances are both 601 returned from the poll and immediate methods, and also sent to notificationURIs 602 when ECSpecs are subscribed to using the subscribe method. The next two sections, 603 Section 8.2 and Section 8.3, specify the ECSpec and ECReports data types in full 604 detail. 605 The two methods getStandardVersion and getVendorVersion may be used 606 by ALE clients to ascertain with what version of the ALE specification an 607 implementation complies. The method getStandardVersion returns a string that 608 identifies what version of the specification this implementation complies with. The 609 possible values for this string are defined by EPCglobal. An implementation SHALL 610 Unre- quested Re- quested Active define subscribe or poll unsubscribe of last subscriber undefine Start trigger received or repeatPeriod elapsed Stop trigger received, duration elapsed, or field stable for stableFieldInterval subscribe or poll, when no startTrigger specified immediate immediate, when no startTrigger specified Stop condition reached, and only requester was poll Stop condition reached, and only requester was immediate Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 20 of 71 return a string corresponding to a version of this specification to which the 611 implementation fully complies, and SHOULD return the string corresponding to the latest 612 version to which it complies. To indicate compliance with this Version 1.0 of the ALE 613 specification, the implementation SHALL return the string 1.0. The method 614 getVendorVersion returns a string that identifies what vendor extensions this 615 implementation provides. The possible values of this string and their meanings are 616 vendor-defined, except that the empty string SHALL indicate that the implementation 617 implements only standard functionality with no vendor extensions. When an 618 implementation chooses to return a non-empty string, the value returned SHALL be a 619 URI where the vendor is the owning authority. For example, this may be an HTTP URL 620 whose authority portion is a domain name owned by the vendor, a URN having a URN 621 namespace identifier issued to the vendor by IANA, an OID URN whose initial path is a 622 Private Enterprise Number assigned to the vendor, etc. 623 8.1.1 Error Conditions 624 Methods of the ALE API signal error conditions to the client by means of exceptions. 625 The following exceptions are defined. All the exception types in the following table are 626 extensions of a common ALEException base type, which contains one string element 627 giving the reason for the exception. 628 Exception Name Meaning SecurityException The operation was not permitted due to an access control violation or other security concern. The specific circumstances that may cause this exception are implementation-specific, and outside the scope of this specification. DuplicateNameException The specified ECSpec name already exists. ECSpecValidationException The specified ECSpec is invalid; e.g., it specifies both a start trigger and a repeat period. The complete list of rules for generating this exception are specified in Section 8.2.11. InvalidURIException The URI specified for a subscriber cannot be parsed, does not name a scheme recognized by the implementation, or violates rules imposed by a particular scheme. NoSuchNameException The specified ECSpec name does not exist. NoSuchSubscriberException The specified subscriber does not exist. Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 21 of 71 Exception Name Meaning DuplicateSubscriptionException The specified ECSpec name and subscriber URI is identical to a previous subscription that was created and not yet unsubscribed. 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 ALE implementation is left in the same state it had before the operation was attempted. SEVERE indicates that the ALE implementation is left in an indeterminate state. 629 The exceptions that may be thrown by each ALE method are indicated in the table below: 630 ALE Method Exceptions define DuplicateNameException ECSpecValidationException SecurityException ImplementationException undefine NoSuchNameException SecurityException ImplementationException getECSpec NoSuchNameException SecurityException ImplementationException getECSpecNames SecurityException ImplementationException subscribe NoSuchNameException InvalidURIException DuplicateSubscriptionException SecurityException ImplementationException unsubscribe NoSuchNameException NoSuchSubscriberException InvalidURIException SecurityException ImplementationException Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 22 of 71 ALE Method Exceptions poll NoSuchNameException SecurityException ImplementationException immediate ECSpecValidationException SecurityException ImplementationException getSubscribers NoSuchNameException SecurityException ImplementationException 631 8.2 ECSpec 632 An ECSpec describes an event cycle and one or more reports that are to be generated 633 from it. It contains a list of logical Readers whose read cycles are to be included in the 634 event cycle, a specification of how the boundaries of event cycles are to be determined, 635 and a list of specifications each of which describes a report to be generated from this 636 event cycle. 637 readers : List // List of logical reader names 638 boundaries : ECBoundarySpec 639 reportSpecs : List // List of one or more ECReportSpec 640 // instances 641 includeSpecInReports : boolean 642 <> 643 --- 644 If the readers parameter is null, omitted, is an empty list, or contains any logical 645 reader names that are not known to the implementation, then the define and 646 immediate methods SHALL raise an ECSpecValidationException. 647 If the boundaries parameter is null or omitted, then the define and immediate 648 methods SHALL raise an ECSpecValidationException. 649 If the reportSpecs parameter is null or omitted or contains an empty list, or if the list 650 contains two ECReportSpec instances with the same reportName, then the 651 define and immediate methods SHALL raise an 652 ECSpecValidationException. 653 If an ECSpec has includeSpecInReports set to true, then the ALE 654 implementation SHALL include the complete ECSpec as part of every ECReports 655 instance generated by this ECSpec. 656 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 23 of 71 8.2.1 ECBoundarySpec 657 An ECBoundarySpec specifies how the beginning and end of event cycles are to be 658 determined. 659 startTrigger : ECTrigger 660 repeatPeriod : ECTime 661 stopTrigger : ECTrigger 662 duration : ECTime 663 stableSetInterval : ECTime 664 <> 665 --- 666 The ECTime values duration, repeatPeriod, and stableSetInterval must 667 be non-negative; otherwise, the define and immediate methods SHALL raise an 668 ECSpecValidationException. Zero means “unspecified.” 669 The startTrigger and stopTrigger parameters are optional. For each of these 670 two parameters, if the parameter is null, omitted, or is an empty string it is considered 671 “unspecified.” 672 The startTrigger and repeatPeriod parameters are mutually exclusive. If 673 startTrigger and repeatPeriod are both specified, then the define and 674 immediate methods SHALL raise an ECSpecValidationException. 675 The conditions under which an event cycle is started depends on the settings for 676 startTrigger and repeatPeriod: 677 • If startTrigger is specified and repeatPeriod is not specified, an event 678 cycle is started when: 679 • The ECSpec is in the requested state and the specified start trigger is received. 680 • If startTrigger is not specified and repeatPeriod is specified, an event 681 cycle is started when: 682 • The ECSpec transitions from the unrequested state to the requested state; or 683 • The repeatPeriod has elapsed from the start of the last event cycle, and in 684 that interval the ECSpec has never transitioned to the unrequested state. 685 • If neither startTrigger nor repeatPeriod are specified, an event cycle is 686 started when: 687 • The ECSpec transitions from the unrequested state to the requested state; or 688 • Immediately after the previous event cycle, if the ECSpec is in the requested 689 state. 690 An event cycle, once started, extends until one of the following is true: 691 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 24 of 71 • The duration, when specified, expires. 692 • When the stableSetInterval is specified, no new EPCs are reported by any 693 Reader for the specified interval (i.e., the set of EPCs being accumulated by the event 694 cycle is stable for the specified interval). In this context, “new” is to be interpreted 695 collectively among Readers contributing to this event cycle. For example, suppose a 696 given event cycle is accumulating data from Readers A and B. If Reader A completes 697 a read cycle containing EPC X, then subsequently Reader B completes a different 698 read cycle containing the same EPC X, then the occurrence of EPC X in B’s read 699 cycle is not considered “new” for the purposes of evaluating the 700 stableSetInterval. Note that in the context of the stableSetInterval, 701 the term “stable” only implies that no new EPCs are detected; it does not imply that 702 previously detected EPCs must continue to be detected. That is, only additions, and 703 not deletions, are considered in determining that the EPC set is “stable.” 704 • The stopTrigger, when specified, is received. 705 • The ECSpec transitions to the unrequested state. 706 Note that the first of these conditions to become true terminates the event cycle. For 707 example, if both duration and stableSetInterval are specified, then the event 708 cycle terminates when the duration expires, even if the reader field has not been stable 709 for the stableSetInterval. But if the set of EPCs is stable for 710 stableSetInterval, the event cycle terminates even if the total time is shorter than 711 the specified duration. 712 Note that if the repeatPeriod expires while an event cycle is in progress, it does not 713 terminate the event cycle. The event cycle terminates only when one of the four 714 conditions specified above becomes true. If, by that time, the ECSpec has not 715 transitioned to the unrequested state, then a new event cycle will start immediately, 716 following the second rule for repeatPeriod (because the repeatPeriod has 717 expired, the start condition is immediately fulfilled). 718 If no event cycle termination condition is specified in the ECBoundarySpec – that is, 719 stopTrigger, duration, and stableSetInterval are all unspecified, and 720 there is no vendor extension termination condition specified – then the define and 721 immediate methods SHALL raise an ECSpecValidationException. 722 In all the descriptions above, note that an ECSpec presented via the immediate method 723 means that the ECSpec transitions from unrequested to requested immediately upon 724 calling immediate, and transitions from requested to unrequested immediately after 725 completion of the event cycle. 726 The ECTrigger values startTrigger and stopTrigger, if specified, must 727 conform to URI syntax as defined by [RFC2396], and must be supported by the ALE 728 implementation; otherwise, the define and immediate methods SHALL raise an 729 ECSpecValidationException. 730 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 25 of 71 8.2.2 ECTime 731 ECTime denotes a span of time measured in physical time units. 732 duration : long 733 unit : ECTimeUnit 734 --- 735 8.2.3 ECTimeUnit 736 ECTimeUnit is an enumerated type denoting different units of physical time that may 737 be used in an ECBoundarySpec. 738 <> 739 MS // Milliseconds 740 8.2.4 ECTrigger 741 ECTrigger denotes a URI that is used to specify a start or stop trigger for an event 742 cycle (see Section 8.2.1 for explanation of start and stop triggers). The interpretation of 743 this URI is determined by the ALE implementation; the kinds and means of triggers 744 supported is intended to be a point of extensibility. 745 8.2.5 ECReportSpec 746 An ECReportSpec specifies one report to be returned from executing an event cycle. 747 An ECSpec contains a list of one or more ECReportSpec instances. 748 reportName : string 749 reportSet : ECReportSetSpec 750 filter : ECFilterSpec 751 group : ECGroupSpec 752 output : ECReportOutputSpec 753 reportIfEmpty : boolean 754 reportOnlyOnChange : boolean 755 <> 756 --- 757 The ECReportSetSpec specifies what set of EPCs is considered for reporting: all 758 currently read, additions from the previous event cycle, or deletions from the previous 759 event cycle. 760 The filter parameter (of type ECFilterSpec) specifies how the raw EPCs are 761 filtered before inclusion in the report. If any of the specified filters does not conform to 762 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 26 of 71 the EPC URI pattern syntax specified in [TDS1.1], then the define and immediate 763 methods SHALL raise an ECSpecValidationException. 764 The group parameter (of type ECGroupSpec) specifies how the filtered EPCs are 765 grouped together for reporting. If any of the grouping patterns does not conform to the 766 syntax for grouping patterns specified in Section 8.2.9, or if any two grouping patterns 767 are determined to be non-disjoint as defined in Section 8.2.9, then the define and 768 immediate methods SHALL raise an ECSpecValidationException. 769 The output parameter (of type ECReportOutputSpec) specifies whether to return 770 the EPC groups themselves or a count of each group, or both. These parameter types are 771 discussed at length in Sections 4 and 5. 772 If an ECReportSpec has reportIfEmpty set to false, then the corresponding 773 ECReport instance SHALL be omitted from the ECReports for this event cycle if the 774 final, filtered set of EPCs is empty (i.e., if the final EPC list would be empty, or if the 775 final count would be zero). 776 If an ECReportSpec has reportOnlyOnChange set to true, then the corresponding 777 ECReport instance SHALL be omitted from the ECReports for this event cycle if the 778 filtered set of EPCs is identical to the previously filtered set of EPCs. This comparison 779 takes place before the filtered set has been modified based on reportSet or output 780 parameters. The comparison also disregards whether the previous ECReports was 781 actually sent due to the effect of this boolean, or the reportIfEmpty boolean. 782 When the processing of reportIfEmpty and reportOnlyOnChange results in all 783 ECReport instances being omitted from an ECReports for an event cycle, then the 784 notification of subscribers SHALL be suppressed altogether. That is, a notification 785 consisting of an ECReports having zero contained ECReport instances SHALL NOT 786 be sent to a subscriber. (Because an ECSpec must contain at least one 787 ECReportSpec, this can only arise as a result of reportIfEmpty or 788 reportOnlyOnChange processing.) This rule only applies to subscribers (event cycle 789 requestors that were registered by use of the subscribe method); an ECReports 790 instance SHALL always be returned to the caller of immediate or poll at the end of 791 an event cycle, even if that ECReports instance contains zero ECReport instances. 792 The reportName parameter is an arbitrary string that is copied to the ECReport 793 instance created when this event cycle completes. The purpose of the reportName 794 parameter is so that clients can distinguish which of the ECReport instances that it 795 receives corresponds to which ECReportSpec instance contained in the original 796 ECSpec. This is especially useful in cases where fewer reports are delivered than there 797 were ECReportSpec instances in the ECSpec, because reportIfEmpty=false 798 or reportOnlyOnChange=true settings suppressed the generation of some reports. 799 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 27 of 71 8.2.6 ECReportSetSpec 800 ECReportSetSpec is an enumerated type denoting what set of EPCs is to be 801 considered for filtering and output: all EPCs read in the current event cycle, additions 802 from the previous event cycle, or deletions from the previous event cycle. 803 <> 804 CURRENT 805 ADDITIONS 806 DELETIONS 807 8.2.7 ECFilterSpec 808 An ECFilterSpec specifies what EPCs are to be included in the final report. 809 includePatterns : List // List of EPC patterns 810 excludePatterns : List // List of EPC patterns 811 <> 812 --- 813 The ECFilterSpec implements a flexible filtering scheme based on two pattern lists. 814 Each list contains zero or more EPC patterns. Each EPC pattern denotes a single EPC, a 815 range of EPCs, or some other set of EPCs. (Patterns are described in detail below in 816 Section 8.2.8.) An EPC is included in the final report if (a) the EPC does not match any 817 pattern in the excludePatterns list, and (b) the EPC does match at least one pattern 818 in the includePatterns list. The (b) test is omitted if the includePatterns list 819 is empty. 820 This can be expressed using the notation of Section 4 as follows, where R is the set of 821 EPCs to be reported from a given event cycle, prior to filtering: 822 F(R) = { epc | epc ∈ R 823 & (epc ∈ I1 | … | epc i∈ In) 824 & epc ∉ E1 & … & epc ∉ En } 825 where Ii denotes the set of EPCs matched by the ith pattern in the includePatterns 826 list, and Ei denotes the set of EPCs matched by the ith pattern in the 827 excludePatterns list. 828 8.2.8 EPC Patterns (non-normative) 829 EPC Patterns are used to specify filters within an ECFilterSpec. The normative 830 specification of EPC Patterns may be found in the EPCglobal Tag Data Specification 831 Version 1.1 [TDS1.1]. The remainder of this section provides a non-normative summary 832 of some of the features of that specification, to aid the reader who has not read the 833 EPCglobal Tag Data Specification in understanding the filtering aspects of the ALE API. 834 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 28 of 71 An EPC pattern is a URI-formatted string that denotes a single EPC or set of EPCs. The 835 general format is: 836 urn:epc:pat:TagFormat:Filter.Company.Item.Serial 837 where TagFormat denotes one of the tag formats defined by the Tag Data 838 Specification, and the four fields Filter, Company, Item, and SerialNumber 839 correspond to data fields of the EPC. The meaning and number of these fields, as well as 840 their formal names, varies according to what TagFormat is named. In an EPC pattern, 841 each of the data fields may be (a) a decimal integer, meaning that a matching EPC must 842 have that specific value in the corresponding field; (b) an asterisk (*), meaning that a 843 matching EPC may have any value in that field; or (c) a range denoted like [lo-hi], 844 meaning that a matching EPC must have a value between the decimal integers lo and 845 hi, inclusive. Depending on the tag format, there may be other restrictions; see the 846 EPCglobal Tag Data Specification for full details. 847 Here are some examples. In these examples, assume that all tags are of the GID-96 848 format (which lacks the Filter data field), and that 20 is the Domain Manager 849 (Company field) for XYZ Corporation, and 300 is the Object Class (Item field) for its 850 UltraWidget product. 851 urn:epc:pat:gid-96:20.300.4000 Matches the EPC for UltraWidget serial number 4000. urn:epc:pat:gid-96:20.300.* Matches any UltraWidget’s EPC, regardless of serial number. urn:epc:pat:gid-96:20.*.[5000-9999] Matches any XYZ Corporation product whose serial number is between 5000 and 9999, inclusive. urn:epc:pat:gid-96:*.*.* Matches any GID-96 tag 852 8.2.9 ECGroupSpec 853 ECGroupSpec defines how filtered EPCs are grouped together for reporting. 854 patternList : List // of pattern URIs 855 --- 856 Each element of the pattern list is an EPC Pattern URI as defined by the EPCglobal Tag 857 Data Specification Version 1.1 [TDS1.1] (see Section 8.2.8 for an informal description of 858 this syntax), extended by allowing the character X in each position where a * character is 859 allowed. All restrictions on the use of the * character as defined in the Tag Data 860 Specification apply equally to the use of the X character. For example, the following are 861 legal URIs for use in the pattern list: 862 urn:epc:pat:sgtin-64:3.*.*.* 863 urn:epc:pat:sgtin-64:3.*.X.* 864 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 29 of 71 urn:epc:pat:sgtin-64:3.X.*.* 865 urn:epc:pat:sgtin-64:3.X.X.* 866 But the following are not: 867 urn:epc:pat:sgtin-64:3.*.12345.* 868 urn:epc:pat:sgtin-64:3.X.12345.* 869 Pattern URIs used in an ECGroupSpec are interpreted as follows: 870 Pattern URI Field Meaning X Create a different group for each distinct value of this field. * All values of this field belong to the same group. Number Only EPCs having Number in this field will belong to this group. [Lo-Hi] Only EPCs whose value for this field falls within the specified range will belong to this group. 871 Here are examples of pattern URIs used as group operators: 872 Pattern URI Meaning urn:epc:pat:sgtin-64:X.*.*.* groups by filter value (e.g., case/pallet) urn:epc:pat:sgtin-64:*.X.*.* groups by company prefix urn:epc:pat:sgtin-64:*.X.X.* groups by company prefix and item reference (i.e., groups by specific product) urn:epc:pat:sgtin-64:X.X.X.* groups by company prefix, item reference, and filter urn:epc:pat:sgtin-64:3.X.*.[0-100] create a different group for each company prefix, including in each such group only EPCs having a filter value of 3 and serial numbers in the range 0 through 100, inclusive 873 In the corresponding ECReport, each group is named by another EPC Pattern URI that 874 is identical to the group operator URI, except that the group name URI has an actual 875 value in every position where the group operator URI had an X character. 876 For example, if these are the filtered EPCs read for the current event cycle: 877 urn:epc:tag:sgtin-64:3.0036000.123456.400 878 urn:epc:tag:sgtin-64:3.0036000.123456.500 879 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 30 of 71 urn:epc:tag:sgtin-64:3.0029000.111111.100 880 urn:epc:tag:sscc-64:3.0012345.31415926 881 Then a pattern list consisting of just one element, like this: 882 urn:epc:pat:sgtin-64:*.X.*.* 883 would generate the following groups in the report: 884 Group Name EPCs in Group urn:epc:pat:sgtin-64:*.0036000.*.* urn:epc:tag:sgtin-64:3.0036000.123456.400 urn:epc:tag:sgtin-64:3.0036000.123456.500 urn:epc:pat:sgtin-64:*.0029000.*.* urn:epc:tag:sgtin-64:3.0029000.111111.100 [default group] urn:epc:tag:sscc-64:3.0012345.31415926 885 Every filtered EPC that is part of the event cycle is part of exactly one group. If an EPC 886 does not match any of the EPC Pattern URIs in the pattern list, it is included in a special 887 “default group.” The name of the default group is null. In the above example, the SSCC 888 EPC did not match any pattern in the pattern list, and so was included in the default 889 group. 890 As a special case of the above rule, if the pattern list is empty (or if the group parameter 891 of the ECReportSpec is null or omitted), then all EPCs are part of the default group. 892 In order to insure that each EPC is part of only one group, there is an additional 893 restriction that all patterns in the pattern list must be pairwise disjoint. Disjointedness of 894 two patterns is defined as follows. Let Pat_i and Pat_j be two pattern URIs, written as a 895 series of fields as follows: 896 Pat_i = urn:epc:pat:type_i:field_i_1.field_i_2.field_i_3... 897 Pat_j = urn:epc:pat:type_j:field_j_1.field_j_2.field_j_3... 898 Then Pat_i and Pat_j are disjoint if: 899 • type_i is not equal to type_j 900 • type_i = type_j but there is at least one field k for which field_i_k and 901 field_j_k are disjoint, as defined by the table below: 902 X * Number [Lo-Hi] X Not disjoint Not disjoint Not disjoint Not disjoint * Not disjoint Not disjoint Not disjoint Not disjoint Number Not disjoint Not disjoint Disjoint if the numbers are different Disjoint if the number is not included in the range [Lo-Hi] Not disjoint Not disjoint Disjoint if the number is not Disjoint if the ranges do not Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 31 of 71 included in the range overlap 903 The relationship of the ECGroupSpec to the group operator introduced in Section 5 is 904 defined as follows. Formally, a group operator G is specified by a list of pattern URIs: 905 G = (Pat_1, Pat_2, ..., Pat_N) 906 Let each pattern be written as a series of fields: 907 Pat_i = urn:epc:pat:type_i:field_i_1.field_i_2.field_i_3... 908 where each field_i_j is either X, *, Number, or [Lo-Hi]. 909 Then the definition of G(epc) is as follows. Let epc be written like this: 910 urn:epc:tag:type_epc:field_epc_1.field_epc_2.field_epc_3... 911 The epc is said to match Pat_i if 912 • type_epc = type_i; and 913 • For each field k, one of the following is true: 914 • field_i_k = X 915 • field_i_k = * 916 • field_i_k is a number, equal to field_epc_k 917 • field_i_k is a range [Lo-Hi], and Lo ≤ field_epc_k ≤ Hi 918 Because of the disjointedness constraint specified above, the epc is guaranteed to match 919 at most one of the patterns in G. 920 G(epc) is then defined as follows: 921 • If epc matches Pat_i for some i, then 922 G(epc) = urn:epc:pat:type_epc:field_g_1.field_g_2.field_g_3... 923 where for each k, field_g_k = *, if field_i_k = *; or field_g_k = 924 field_epc_j, otherwise 925 • If epc does not match Pat_i for any i, then G(epc) = the default group. 926 8.2.10 ECReportOutputSpec 927 ECReportOutputSpec specifies how the final set of EPCs is to be reported. 928 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 32 of 71 includeEPC : boolean 929 includeTag : boolean 930 includeRawHex : boolean 931 includeRawDecimal : boolean 932 includeCount : boolean 933 <> 934 --- 935 If any of the four booleans includeEPC, includeTag, includeRawHex, or 936 includeRawDecimal are true, the report SHALL include a list of the EPCs in the 937 final set for each group. Each element of this list, when included, SHALL include the 938 formats specified by these four Booleans. If includeCount is true, the report SHALL 939 include a count of the EPCs in the final set for each group. Both may be true, in which 940 case each group includes both a list and a count. If all five booleans includeEPC, 941 includeTag, includeRawHex, includeRawDecimal, and includeCount are 942 false, in the absence of any vendor extension to ECReportOutputSpec, then the 943 define and immediate methods SHALL raise an 944 ECSpecValidationException. 945 8.2.11 Validation of ECSpecs 946 The define and immediate methods of the ALE API (Section 8.1) SHALL raise an 947 ECSpecValidationException if any of the following are true: 948 • Any logical reader name in the readers field of ECSpec is not known to the 949 implementation. 950 • The startTrigger or stopTrigger field of ECBoundarySpec, when 951 specified, does not conform to URI syntax as defined by [RFC2396], or is not 952 supported by the ALE implementation. 953 • The duration, stableSetInterval, or repeatPeriod field of 954 ECBoundarySpec is negative. 955 • The startTrigger field of ECBoundarySpec is non-empty and the 956 repeatPeriod field of ECBoundarySpec is non-zero. 957 • No stopping condition is specified in ECBoundarySpec; i.e., neither 958 stopTrigger nor duration nor stableSetInterval nor any vendor 959 extension stopping condition is specified. 960 • The list of ECReportSpec instances is empty. 961 • Two ECReportSpec instances have identical values for their name field. 962 • The boundaries parameter of ECSpec is null or omitted. 963 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 33 of 71 • Any filter within ECFilterSpec does not conform to the EPC URI pattern syntax 964 specified in [TDS1.1]. 965 • Any grouping pattern within ECGroupSpec does not conform to the syntax for 966 grouping patterns specified in Section 8.2.9. 967 • Any two grouping patterns within ECGroupSpec are determined to be non-disjoint 968 as that term is defined in Section 8.2.9. 969 • Within any ECReportSpec of an ECSpec, the ECReportOutputSpec has no 970 output type specified; i.e., none of includeEPC, includeTag, 971 includeRawHex, includeRawDecimal, includeCount, nor any vendor 972 extension output type is specified as true. 973 8.3 ECReports 974 ECReports is the output from an event cycle. 975 specName : string 976 date : dateTime 977 ALEID : string 978 totalMilliseconds : long 979 terminationCondition : ECTerminationCondition 980 spec : ECSpec 981 reports : List // List of ECReport 982 <> 983 --- 984 The “meat” of an ECReports instance is the list of ECReport instances, each 985 corresponding to an ECReportSpec instance in the event cycle’s ECSpec. In addition 986 to the reports themselves, ECReports contains a number of “header” fields that provide 987 useful information about the event cycle: 988 Field Description specName The name of the ECSpec that controlled this event cycle. In the case of an ECSpec that was requested using the immediate method (Section 8.1), this name is one chosen by the ALE implementation. date A representation of the date and time when the event cycle ended. For bindings in which this field is represented textually, an ISO-8601 compliant representation SHOULD be used. ALEID An identifier for the deployed instance of the ALE implementation. The meaning of this identifier is Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 34 of 71 Field Description outside the scope of this specification. totalMilliseconds The total time, in milliseconds, from the start of the event cycle to the end of the event cycle. terminationCondition Indicates what kind of event caused the event cycle to terminate: the receipt of an explicit stop trigger, the expiration of the event cycle duration, or the read field being stable for the prescribed amount of time. These correspond to the possible ways of specifying the end of an event cycle as defined in Section 8.2.1. spec A copy of the ECSpec that generated this ECReports instance. Only included if the ECSpec has includeSpecInReports set to true. 989 8.3.1 ECTerminationCondition 990 ECTerminationCondition is an enumerated type that describes how an event cycle 991 was ended. 992 <> 993 TRIGGER 994 DURATION 995 STABLE_SET 996 UNREQUEST 997 The first three values, TRIGGER, DURATION, and STABLE_SET, correspond to the 998 receipt of an explicit stop trigger, the expiration of the event cycle duration, or the set 999 of EPCs being stable for the event cycle stableSetInterval, respectively. These 1000 are the possible stop conditions described in Section 8.2.1. The last value, UNREQUEST, 1001 corresponds to an event cycle being terminated because there were no longer any clients 1002 requesting it. By definition, this value cannot actually appear in an ECReports 1003 instance sent to any client. 1004 8.3.2 ECReport 1005 ECReport represents a single report within an event cycle. 1006 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 35 of 71 reportName : string 1007 groups : List // List of ECReportGroup instances 1008 <> 1009 --- 1010 The reportName field is a copy of the reportName field from the corresponding 1011 ECReportSpec within the ECSpec that controlled this event cycle. The groups 1012 field is a list containing one element for each group in the report as controlled by the 1013 group field of the corresponding ECReportSpec. When no grouping is specified, the 1014 groups list just consists of the single default group. 1015 8.3.3 ECReportGroup 1016 ECReportGroup represents one group within an ECReport. 1017 groupName : string 1018 groupList : ECReportGroupList 1019 groupCount : ECReportGroupCount 1020 <> 1021 --- 1022 The groupName SHALL be null for the default group. The groupList field SHALL 1023 be null if the includeEPC, includeTag, includeRawHex, and 1024 includeRawDecimal fields of the corresponding ECReportOutputSpec are all 1025 false (unless ECReportOutputSpec has vendor extensions that cause groupList 1026 to be included). The groupCount field SHALL be null if the includeCount field 1027 of the corresponding ECReportOutputSpec is false (unless 1028 ECReportOutputSpec has vendor extensions that cause groupCount to be 1029 included). 1030 8.3.4 ECReportGroupList 1031 An ECReportGroupList SHALL be included in an ECReportGroup when any of 1032 the four boolean fields includeEPC, includeTag, includeRawHex, and 1033 includeRawDecimal of the corresponding ECReportOutputSpec are true. 1034 members : List //List of ECReportGroupListMember instances 1035 <> 1036 --- 1037 The order in which EPCs are enumerated within the list is unspecified. 1038 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 36 of 71 8.3.5 ECReportGroupListMember 1039 Each member of the ECReportGroupList is an ECReportGroupListMember as 1040 defined below. The reason for having ECReportGroupListMember is to allow 1041 multiple EPC formats to be included, and to provide an extension point for adding per-1042 EPC information to the list report. 1043 epc : URI 1044 tag : URI 1045 rawHex : URI 1046 rawDecimal : URI 1047 < 1048 --- 1049 Each of these fields SHALL contain a URI as described below or be null, depending on 1050 the value of a boolean in the corresponding ECReportOutputSpec. Specifically, the 1051 epc field SHALL be non-null if and only if the includeEPC field of 1052 ECReportOutputSpec is true, the tag field SHALL be non-null according to 1053 includeTag, the rawHex field SHALL be non-null according to includeRawHex, 1054 and the rawDecimal field SHALL be non-null according to includeDecimal. 1055 When non-null, the epc field SHALL contain an EPC represented as a pure identity URI 1056 according to the EPCglobal Tag Data Specification (urn:epc:id:…). This URI 1057 SHALL be determined using the first procedure given in Section 5 of [TDS1.1]. If that 1058 procedure fails in any step, the epc field SHALL instead contain a raw decimal URI 1059 determined using Step 20 of the second procedure given in Section 5 of [TDS1.1]. 1060 When non-null, the tag field SHALL contain an EPC represented as a tag URI 1061 according to the EPCglobal Tag Data Specification (urn:epc:tag:…). This URI 1062 SHALL be determined using the second procedure given in Section 5 of [TDS1.1]. 1063 When non-null, the rawDecimal field SHALL contain a raw tag value represented as a 1064 raw decimal URI according to the EPCglobal Tag Data Specification 1065 (urn:epc:raw:…). This URI SHALL be determined using Step 20 of the second 1066 procedure given in Section 5 of [TDS1.1]. 1067 When non-null, the rawHex field SHALL contain a raw tag value represented as a raw 1068 hexadecimal URI according to the following extension to the EPCglobal Tag Data 1069 Specification. The URI SHALL be determined by concatenating the following: the 1070 string urn:epc:raw:, the length of the tag value in bits, a dot (.) character, a 1071 lowercase x character, and the tag value considered as a single hexadecimal integer. The 1072 length value preceding the dot character SHALL have no leading zeros. The 1073 hexadecimal tag value following the dot SHALL have a number of characters equal to the 1074 length of the tag value in bits divided by four and rounded up to the nearest whole 1075 number, and SHALL only use uppercase letters for the hexadecimal digits A, B, C, D, E, 1076 and F. 1077 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 37 of 71 Each distinct tag value included in the report SHALL have a distinct 1078 ECReportGroupListMember element in the ECReportGroupList, even if those 1079 ECReportGroupListMember elements would be identical due to the formats 1080 selected. In particular, it is possible for two different tags to have the same pure identity 1081 EPC representation; e.g., two SGTIN-64 tags that differ only in the filter bits. If both 1082 tags are read in the same event cycle, and ECReportOutputSpec specified 1083 includeEPC true and all other formats false, then the resulting 1084 ECReportGroupList SHALL have two ECReportGroupListMember elements, 1085 each having the same pure identity URI in the epc field. In other words, the result 1086 should be equivalent to performing all duplicate removal, additions/deletions processing, 1087 grouping, and filtering before converting the raw tag values into the selected 1088 representation(s). 1089 Explanation (non-normative): The situation in which this rule applies is expected to be 1090 extremely rare. In theory, no two tags should be programmed with the same pure 1091 identity, even if they differ in filter bits or other fields not part of the pure identity. But 1092 because the situation is possible, it is necessary to specify a definite behavior in this 1093 specification. The behavior specified above is intended to be the most easily 1094 implemented. 1095 8.3.6 ECReportGroupCount 1096 An ECReportGroupCount is included in an ECReportGroup when the 1097 includeCount field of the corresponding ECReportOutputSpec is true. 1098 count : int 1099 <> 1100 --- 1101 The count field is the total number of distinct EPCs that are part of this group. 1102 9 Standard Notification URIs 1103 This section specifies the syntax and semantics of standard URIs that may be used in 1104 conjunction with the subscribe and unsubscribe methods of the main ALE 1105 interface (Section 8.1). Each subsection below specifies the conformance requirement 1106 (MAY, SHOULD, SHALL) for each standard URI. 1107 All notification URIs, whether standardized as a part of this specification or not, must 1108 conform to the general syntax for URIs as defined in [RFC2396]. Each notification URI 1109 scheme may impose additional constraints upon syntax. 1110 9.1 HTTP Notification URI 1111 The HTTP notification URI provides for delivery of ECReports in XML via the HTTP 1112 protocol using the POST operation. Implementations SHOULD provide support for this 1113 notification URI. 1114 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 38 of 71 The syntax for HTTP notification URIs as used by ALE is defined in [RFC2616], 1115 Section 3.2.2. Informally, an HTTP URI has one of the two following forms: 1116 http://host:port/remainder-of-URL 1117 http://host/remainder-of-URL 1118 where 1119 • host is the DNS name or IP address of the host where the receiver is listening for 1120 incoming HTTP connections. 1121 • port is the TCP port on which the receiver is listening for incoming HTTP 1122 connections. The port and the preceding colon character may be omitted, in which 1123 case the port defaults to 80. 1124 • remainder-of-URL is the URL to which an HTTP POST operation will be 1125 directed. 1126 The ALE implementation delivers event cycle reports by sending an HTTP POST request 1127 to receiver designated in the URI, where remainder-of-URL is included in the HTTP 1128 request-line (as defined in [RFC2616]), and where the payload is the ECReports 1129 instance encoded in XML according to the schema specified in Section 10.2. 1130 The interpretation by the ALE implementation of the response code returned by the 1131 receiver is outside the scope of this specification; however, all implementations SHALL 1132 interpret a response code 2xx (that is, any response code between 200 and 299, inclusive) 1133 as a normal response, not indicative of any error. 1134 9.2 TCP Notification URI 1135 The TCP notification URI provides for delivery of ECReports in XML via a raw TCP 1136 connection. Implementations SHOULD provide support for this notification URI. 1137 The syntax for TCP notification URIs as used by ALE is as follows: 1138 tcp_URL = "tcp:" "//" host ":" port 1139 where the syntax definition for host and port is specified in [RFC2396]. 1140 Informally, a TCP URI has the following form: 1141 tcp://host:port 1142 The ALE implementation delivers an event cycle report by opening a new TCP 1143 connection to the specified host and port, writing to the connection the ECReports 1144 instance encoded in XML according to the schema specified in Section 10.2, and then 1145 closing the connection. No reply or acknowledgement is expected by the ALE 1146 implementation. 1147 9.3 FILE Notification URI 1148 The FILE notification URI provides for writing of ECReports in XML to a file. 1149 Implementations MAY provide support for this notification URI. 1150 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 39 of 71 The syntax for FILE notification URIs as used by ALE is defined in [RFC1738], 1151 Section 3.10. Informally, an FILE URI has one of the two following forms: 1152 file://host/path 1153 file:///path 1154 where 1155 • host is the DNS name or IP address of a remote host whose filesystem is accessible 1156 to the ALE implementation. 1157 • path is the pathname of a file within the remote filesystem, or the local filesystem if 1158 host is omitted. 1159 The ALE implementation delivers an event cycle report by appending to the specified file 1160 the ECReports instance encoded in XML according to the schema specified in 1161 Section 10.2. Note that if more than one event cycle completes, the file will contain a 1162 concatenation of XML documents, rather than a single XML document. 1163 Implementations of ALE may impose additional constraints on the use of the FILE URI. 1164 For example, some implementations of ALE may support only a local filesystem while 1165 others may support only a remote filesystem, some implementations of ALE may impose 1166 further restrictions on the syntax of the path component, and so forth. This 1167 specification also does not define the behavior when path names a directory; the 1168 behavior in that case is implementation dependent. 1169 Rationale (non-normative): The intended use for the FILE notification URI is for 1170 debugging, and hence the specification is intentionally lax in order to give freedom to 1171 implementations to provide the most appropriate and useful facility given the unique 1172 circumstances of that implementation. 1173 10 XML Schema for Event Cycle Specs and Reports 1174 This section defines the standard XML representation for ECSpec instances 1175 (Section 8.2) and ECReports instances (Section 8.3), using the W3C XML Schema 1176 language [XSD1, XSD2]. Samples are also shown. 1177 The schema below conforms to EPCglobal standard schema design rules. The schema 1178 below imports the EPCglobal standard base schema, as mandated by the design rules. 1179 10.1 Extensibility Mechanism 1180 The XML schema in this section implements the <> given in 1181 the UML of Section 8 using a methodology described in [XMLVersioning]. This 1182 methodology provides for both vendor extension, and for extension by EPCglobal in 1183 future versions of this specification or in supplemental specifications. Extensions 1184 introduced through this mechanism will be backward compatible, in that documents 1185 conforming to older versions of the schema will also conform to newer versions of the 1186 standard schema and to schema containing vendor-specific extensions. Extensions will 1187 also be forward compatible, in that documents that contain vendor extensions or that 1188 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 40 of 71 conform to newer versions of the standard schema will also conform to older versions of 1189 the schema. 1190 When a document contains extensions (vendor-specific or standardized in newer versions 1191 of schema), it may conform to more than one schema. For example, a document 1192 containing vendor extensions to the EPCglobal Version 1.0 schema will conform both to 1193 the EPCglobal Version 1.0 schema and to a vendor-specific schema that includes the 1194 vendor extensions. In this example, when the document is parsed using the standard 1195 schema there will be no type-checking of the extension elements and attributes, but when 1196 the document is parsed using the vendor-specific schema the extensions will be type-1197 checked. Similarly, a document containing new features introduced in a hypothetical 1198 EPCglobal Version 1.1 schema will conform both to the EPCglobal Version 1.0 schema 1199 and to the EPCglobal Version 1.1 schema, but type checking of the new features will 1200 only be available using the Version 1.1 schema. 1201 The design rules for this extensibility pattern are given in [XMLVersioning]. In 1202 summary, it amounts to the following rules: 1203 • For each type in which <> occurs, include an 1204 xsd:anyAttribute declaration. This declaration provides for the addition of 1205 new attributes, either in subsequent versions of the standard schema or in vendor-1206 specific schema. 1207 • For each type in which <> occurs, include an optional 1208 (minOccurs = 0) element named extension. The type declared for the 1209 extension element will always be as follows: 1210 1211 1213 1214 1215 This declaration provides for forward-compatibility with new elements introduced 1216 into subsequent versions of the standard schema. 1217 • For each type in which <> occurs, include at the end of the 1218 element list a declaration 1219 1221 This declaration provides for forward-compatibility with new elements introduced in 1222 vendor-specific schema. 1223 The rules for adding vendor-specific extensions to the schema are as follows: 1224 • Vendor-specific attributes may be added to any type in which <> occurs. Vendor-specific attributes SHALL NOT be in the EPCglobal ALE 1226 namespace (urn:epcglobal:ale:xsd:1). Vendor-specific attributes SHALL 1227 be in a namespace whose namespace URI has the vendor as the owning authority. (In 1228 schema parlance, this means that all vendor-specific attributes must have 1229 qualified as their form.) For example, the namespace URI may be an HTTP 1230 URL whose authority portion is a domain name owned by the vendor, a URN having 1231 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 41 of 71 a URN namespace identifier issued to the vendor by IANA, an OID URN whose 1232 initial path is a Private Enterprise Number assigned to the vendor, etc. Declarations 1233 of vendor-specific attributes SHALL specify use="optional". 1234 • Vendor-specific elements may be added to any type in which <> occurs. Vendor-specific elements SHALL NOT be in the EPCglobal ALE 1236 namespace (urn:epcglobal:ale:xsd:1). Vendor-specific attributes SHALL 1237 be in a namespace whose namespace URI has the vendor as the owning authority (as 1238 described above). (In schema parlance, this means that all vendor-specific elements 1239 must have qualified as their form.) 1240 To create a schema that contains vendor extensions, replace the declaration with a content group reference to a group 1242 defined in the vendor namespace; e.g., . In the schema file defining elements for 1244 the vendor namespace, define a content group using a declaration of the following 1245 form: 1246 1247 1248 1252 1255 1256 1257 (In the foregoing illustrations, vendor and VendorExtension may be any 1258 strings the vendor chooses.) 1259 Explanation (non-normative): Because vendor-specific elements must be optional, 1260 including references to their definitions directly into the ALE schema would violate the 1261 XML Schema Unique Particle Attribution constraint, because the 1262 element in the ALE schema can also match vendor-specific elements. Moving the 1263 into the vendor’s schema avoids this problem, because ##other in 1264 that schema means “match an element that has a namespace other than the vendor’s 1265 namespace.” This does not conflict with standard elements, because the element form 1266 default for the standard ALE schema is unqualified, and hence the ##other in the 1267 vendor’s schema does not match standard ALE elements, either. 1268 The rules for adding attributes or elements to future versions of the EPCglobal standard 1269 schema are as follows: 1270 • Standard attributes may be added to any type in which <> 1271 occurs. Standard attributes SHALL NOT be in any namespace, and SHALL NOT 1272 conflict with any existing standard attribute name. 1273 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 42 of 71 • Standard elements may be added to any type in which <> 1274 occurs. New elements are added using the following rules: 1275 • Find the innermost extension element type. 1276 • Replace the declaration with (a) 1277 new elements (which SHALL NOT be in any namespace); followed by (b) a new 1278 extension element whose type is constructed as described before. In 1279 subsequent revisions of the standard schema, new standard elements will be added 1280 within this new extension element rather than within this one. 1281 Explanation (non-normative): the reason that new standard attributes and elements are 1282 specified above not to be in any namespace is to be consistent with the ALE schema’s 1283 attribute and element form default of unqualified. 1284 10.2 Schema 1285 The following is an XML Schema (XSD) defining both ECSpec and ECReports. 1286 1287 1294 1295 1296 1297 1298 Copyright (C) 2005, 2004 Epcglobal Inc., All Rights Reserved. 1299 1300 1301 EPCglobal Inc., its members, officers, directors, employees, or 1302 agents shall not be liable for any injury, loss, damages, financial 1303 or otherwise, arising from, related to, or caused by the use of 1304 this document. The use of said document shall constitute your 1305 express consent to the foregoing exculpation. 1306 1307 1308 Application Level Events (ALE) version 1.0 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1339 1340 1341 1342 1343 1344 A ECBoundarySpec specifies how the beginning and end of event cycles 1345 are to be determined. The startTrigger and repeatPeriod elements 1346 are mutually exclusive. One may, however, specify a ECBoundarySpec 1347 with neither event cycle start condition (i.e., startTrigger nor 1348 repeatPeriod) present. At least one event cycle stopping condition 1349 (stopTrigger, duration, and/or stableSetInterval) must be present. 1350 1351 1352 1353 1354 1355 1356 1357 1358 1360 1362 1363 1364 1365 1366 1367 1368 1370 1371 1372 1373 1374 1375 1376 1377 1379 1380 1381 1382 1383 1384 1385 A ECFilterSpec specifies what EPCs are to be included in the final 1386 report. The ECFilterSpec implements a flexible filtering scheme based on 1387 pattern lists for inclusion and exclusion. 1388 1389 1390 1391 1393 1395 1397 1399 1400 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 44 of 71 1401 1402 1403 1404 1405 1407 1408 1409 1410 1411 1412 1413 1415 1416 1417 1418 1419 1420 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1435 1437 1439 1440 1441 1442 1443 1444 1445 1446 1448 1449 1450 1451 1452 1453 1454 1456 1457 1458 1459 1460 1461 1462 1463 1465 1467 1468 1469 1470 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 45 of 71 1471 1472 1473 1474 1475 1477 1478 1479 1480 1481 1482 1483 1485 1487 1489 1490 1491 1492 1493 1494 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1509 1511 1512 1513 1514 1515 1516 1517 1519 1520 1521 1522 1523 1524 1525 1526 1528 1530 1531 1532 1533 1534 1535 1536 1538 1539 1540 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 46 of 71 1541 1542 1543 1544 1545 ECReportOutputSpec specifies how the final set of EPCs is to be reported 1546 with respect to type. 1547 1548 1549 1550 1552 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1566 1567 1568 1569 1570 1571 1572 1573 1574 ECReports is the output from an event cycle. The "meat" of an ECReports 1575 instance is the lists of count report instances and list report 1576 instances, each corresponding to an ECReportSpec instance in the event 1577 cycle's ECSpec. In addition to the reports themselves, ECReports contains 1578 a number of "header" fields that provide useful information about the 1579 event cycle. 1580 1581 1582 1583 1584 1585 1586 1588 1589 1591 1592 1593 1594 1595 1596 1598 1599 1600 1601 1602 1603 1604 1605 1606 1608 1609 1610 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 47 of 71 1611 1612 1613 1614 1615 1616 ECReportSetSpec specifies which set of EPCs is to be considered for 1617 filtering and output. 1618 1619 1620 1621 1622 1623 1624 1625 1626 ECReportSetEnum is an enumerated type denoting what set of EPCs is to be 1627 considered for filtering and output: all EPCs read in the current event 1628 cycle, additions from the previous event cycle, or deletions from the 1629 previous event cycle. 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 A ReportSpec specifies one report to be returned from executing an event 1643 cycle. An ECSpec may contain one or more ECReportSpec instances. 1644 1645 1646 1647 1648 1649 1650 1651 1653 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1666 1667 1668 1669 1670 1671 1672 1673 1675 1676 1677 1678 1679 1680 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 48 of 71 1681 An ECSpec describes an event cycle and one or more reports that are to 1682 be generated from it. It contains a list of logical readers whose reader 1683 cycles are to be included in the event cycle, a specification of read 1684 cycle timing, a specification of how the boundaries of event cycles are 1685 to be determined, and list of specifications each of which describes a 1686 report to be generated from this event cycle. 1687 1688 1689 1690 1691 1692 1693 1694 1695 1697 1699 1700 1702 1703 1704 1705 1706 1707 1708 1709 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 An ECTime specifies a time duration in physical units. 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 ECTimeUnit represents the supported physical time unit: millisecond 1742 1743 1744 1745 1746 1747 1748 1749 1750 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 49 of 71 1751 1752 A trigger is a URI that is used to specify a start or stop trigger for 1753 an event cycle. 1754 1755 1756 1757 1758 1759 1760 1761 10.3 ECSpec – Example (non-normative) 1762 Here is an example ECSpec rendered into XML [XML1.0]: 1763 1764 1770 1771 dock_1a 1772 dock_1b 1773 1774 1775 http://sample.com/trigger1 1776 20000 1777 http://sample.com/trigger2 1778 3000 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 urn:epc:pat:sgtin-64:X.X.X.* 1793 1794 1795 1796 1797 1798 10.4 ECReports – Example (non-normative) 1799 Here is an example ECReports rendered into XML [XML1.0]: 1800 1801 1812 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 50 of 71 1813 1814 1815 1816 urn:epc:tag:gid-96:10.50.1000 1817 urn:epc:tag:gid-96:10.50.1001 1818 1819 1820 1821 1822 6847 1823 1824 1825 1826 2 1827 1828 1829 3 1830 1831 1832 6842 1833 1834 1835 1836 1837 11 SOAP Binding for ALE API 1838 11.1 SOAP Binding 1839 The following is a Web Service Definition Language (WSDL) 1.1 [WSDL1.1] 1840 specification defining the standard SOAP binding of the ALE API. This SOAP binding is 1841 compliant with the WS-i Basic Profile Version 1.0 [WSI]. 1842 1843 1844 1845 1855 1856 1857 Copyright (C) 2005, 2004 EPCglobal Inc., All Rights 1858 Reserved. 1859 EPCglobal Inc., its members, officers, directors, employees, 1860 or agents shall not be liable for any injury, loss, damages, financial or otherwise, 1861 arising from, related to, or caused by the use of this document. The use of said 1862 document shall constitute your express consent to the foregoing 1863 exculpation. 1864 1865 1866 This WSDL document describes the types, messages, operations, and 1867 bindings for the ALEService. 1868 1869 1870 1871 1872 1875 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 52 of 71 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1976 1977 1978 1979 1980 1981 1982 1983 1984 1986 1987 1988 1989 1990 1991 1992 1993 1994 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 53 of 71 2015 2016 2017 2018 2019 2020 2021 2022 2024 2025 2026 2027 2028 2029 2030 2031 2032 2034 2035 2036 2037 2038 2039 2040 2041 2042 2044 2045 2046 2047 2048 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 54 of 71 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 55 of 71 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2178 2180 2182 2184 2185 2186 2187 2188 2189 2191 2193 2195 2196 2197 2198 2199 2200 2202 2204 2206 2207 2208 2209 2211 2213 2215 2217 2218 2219 2220 2221 2222 2224 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 56 of 71 2226 2228 2230 2232 2233 2234 2235 2236 2237 2239 2241 2243 2245 2247 2248 2249 2250 2251 2252 2254 2256 2258 2259 2260 2261 2262 2263 2265 2267 2269 2270 2271 2272 2274 2276 2278 2280 2282 2283 2284 2285 2287 2289 2291 2292 2293 2294 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 57 of 71 2296 2298 2300 2301 2302 2303 2304 2306 2307 2308 2309 2311 2312 2313 2315 2316 2317 2320 2321 2322 2325 2326 2327 2330 2331 2332 2335 2336 2337 2338 2339 2340 2341 2343 2344 2345 2347 2348 2349 2352 2353 2354 2357 2358 2359 2362 2363 2364 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 58 of 71 2365 2366 2367 2368 2370 2371 2372 2374 2375 2376 2379 2380 2381 2384 2385 2386 2389 2390 2391 2392 2393 2394 2395 2397 2398 2399 2401 2402 2403 2406 2407 2408 2411 2412 2413 2414 2415 2416 2417 2419 2420 2421 2423 2424 2425 2428 2429 2430 2433 2434 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 59 of 71 2435 2438 2439 2440 2443 2444 2445 2448 2449 2450 2451 2452 2453 2454 2456 2457 2458 2460 2461 2462 2465 2466 2467 2470 2471 2472 2475 2476 2477 2480 2481 2482 2485 2486 2487 2488 2489 2490 2491 2493 2494 2495 2497 2498 2499 2502 2503 2504 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 60 of 71 2507 2508 2509 2512 2513 2514 2515 2516 2517 2518 2520 2521 2522 2524 2525 2526 2529 2530 2531 2534 2535 2536 2539 2540 2541 2542 2543 2544 2545 2547 2548 2549 2551 2552 2553 2556 2557 2558 2561 2562 2563 2566 2567 2568 2569 2570 2571 2572 2574 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 61 of 71 2575 2576 2578 2579 2580 2583 2584 2585 2586 2587 2588 2589 2591 2592 2593 2595 2596 2597 2600 2601 2602 2603 2604 2605 2606 2607 2609 2611 2612 2613 2614 2615 12 Use Cases (non-normative) 2616 This section provides a non-normative illustration of how the ALE interface is used in 2617 various application scenarios. 2618 1. For shipment and receipt verification, applications will request the number of 2619 Logistic Units such as Pallets and Cases moving through a portal, totaled by Pallet 2620 and Case GTIN across all serial numbers. Object types other than Pallet and Case 2621 should be filtered out of the reading. 2622 2. For retail OOS management, applications will request one of 2 things: 2623 a. The number of Items that were added to or removed from the shelf since the 2624 last read cycle, totaled by Item GTIN across all serial numbers. Object types 2625 other than Item should be filtered out of the reading; or 2626 b. The total number of Items on the shelf during the current read cycle, totaled 2627 by GTIN across all serial numbers. Object types other than Item should be 2628 filtered out of the reading. 2629 3. For retail checkout, applications will request the full EPC of Items that move 2630 through the checkout zone. Object types other than Item should be filtered out. In 2631 order to prevent charging for Items that aren’t for sale (e.g., Items the consumer or 2632 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 62 of 71 checkout clerk brought into the store that inadvertently happen to be read), something 2633 in the architecture needs to make sure such Items are not read or filter them out. 2634 Prevention might be achievable with proper portal design and the ability for the 2635 checkout clerk to override errant reads. Alternatively, the ALE implementation could 2636 filter errant reads via access to a list of Items (down to the serial number) that are 2637 qualified for sale in that store (this could be hundreds of thousands to millions of 2638 items), or the POS application itself could do it. With the list options, the requesting 2639 application would be responsible for maintaining the list. 2640 4. For retail front door theft detection, applications will request the full EPC of any 2641 Item that passes through the security point portal and that has not be marked as sold 2642 by the store and perhaps that meet certain theft detection criteria established by the 2643 store, such as item value. Like the retail checkout use case, the assumption is that the 2644 ALE implementation will have access to a list of store Items (to the serial number 2645 level) that have not been sold and that meet the stores theft alert conditions. The 2646 requesting application will be responsible for maintaining the list, and will decide 2647 what action, if any, should be taken based on variables such as the value and quantity 2648 of Items reported. 2649 5. For retail shelf theft detection, applications will request the number of Items that 2650 were removed from the shelf since the last read cycle, totaled by Item GTIN across all 2651 serial numbers. Object types other than Item should be filtered out. 2652 6. For warehouse management, a relatively complex range of operations and thus 2653 requirements will exist. For illustration at this stage, one of the requirements is that 2654 the application will request the EPC of the slot location into which a forklift operator 2655 has placed a Pallet of products. Object types other than “slot” should be filtered out 2656 of the reading. 2657 2658 The table below summarizes the ALE API settings used in each of these use cases. 2659 Report Settings Use Case Event Cycle Boundaries Result Set R Filter F(R) Report Type 1 (ship/rcpt) Triggered by pallet entering and leaving portal Complete Pallet & Case Group cardinality, G = pallet/case GTIN 2a (retail OOS) Periodic Additions & Deletions Item Group cardinality, G = item GTIN 2b (retail OOS) Periodic Complete Item Group cardinality, G = item GTIN 3 (retail ckout) Single Complete Item Membership (EPC) Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 63 of 71 Report Settings Use Case Event Cycle Boundaries Result Set R Filter F(R) Report Type 4 (door theft) Triggered by object(s) entering and leaving portal Complete None Membership (EPC) 5 (shelf theft) Periodic Deletions Item Group cardinality, G = item GTIN 6 (forklift) Single Complete Slot Membership (EPC) 2660 13 ALE Scenarios (non-normative) 2661 This section provides a non-normative illustration of the API-level interactions between 2662 the ALE interface and the ALE client and other actors. 2663 13.1 ALE Context 2664 The ALE layer exists in a context including RFID readers, Users (administrative) and 2665 Client applications as shown below. Initially the administrators are responsible for 2666 installing and configuring the RFID environment. Once the environment is configured, 2667 EPC data (tag reads) are sent from the Readers to the ALE layer. In some cases the ALE 2668 layer may be implemented on the Reader or elsewhere, but in these scenarios we assume 2669 that the ALE layer is implemented as a distinct software component and is configured to 2670 support more than one Reader. 2671 2672 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 64 of 71 2673 The ALE clients are applications or services that process EPC tag information. Several 2674 methods are defined within the ALE interface which allow clients to specify the data they 2675 wish to receive and the conditions for the production of the reports containing the data. 2676 These methods are: 2677 • define, undefine 2678 • subscribe, unsubscribe 2679 • poll 2680 • immediate 2681 • getECSpecNames, getECSpec 2682 These methods are defined normatively in Section 8.1. 2683 13.2 Scenarios 2684 A few sample scenarios are illustrated below to demonstrate the use of the ALE interface 2685 messages. Below is a representative list of the kinds of scenarios ALE supports. 2686 1. Defining Subscribe ECName, ECSpec 2687 a. Direct Subscription. Defined by A, Report to: A 2688 b. Indirect Subscription Defined by A, Report to: B 2689 2. Poll(ECName) 2690 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 65 of 71 3. Immediate(ECSpec) 2691 4. Operation Errors 2692 5. System Errors 2693 13.2.1 Scenario 1a: Direct Subscription 2694 The scenario shown below involves a client application specifying the EPC data it is 2695 interested in collecting. After specifying the ECSpec, it then subscribes to receive the 2696 resulting ECReports. The ECSpec shown in this scenario specifies that event cycles 2697 should repeat periodically. The ECReportSpec requests reports for additions and 2698 deletions, and reportIfEmpty is set to false. This is a normal scenario involving no 2699 errors. 2700 2701 13.2.1.1 Assumptions 2702 1. All discovery, configuration, and initialization required has already been 2703 performed. 2704 2. The ALE layer is implemented as a distinct software component. 2705 3. ECSpec boundary condition specified using: repeatPeriod 2706 4. ECFilterSpec includePatterns includes the EPC(s) illustrated in 2707 this scenario 2708 5. Client 1 is the only client of ALE and the only subscriber of the ECSpec 2709 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 66 of 71 13.2.1.2 Description 2710 1. The client calls the define method of the ALE interface. The ECSpec 2711 specifies that the event cycle is to begin using repeatPeriod as the 2712 boundary specification and to end using duration as the boundary 2713 specification (but any valid boundary conditions could be specified). The 2714 ECReportSpec and ECFilterSpec contained within the ECSpec are 2715 defined to include the EPC data sent later in step 3. 2716 2. The client calls the subscribe method of the ALE interface, including a 2717 URI that identifies the client itself as the destination for the ECReports. At 2718 this point the ECSpec is considered “Requested.” Since the start condition is 2719 given by repeatPeriod, the ECSpec immediately transitions to the 2720 “Active” state. 2721 3. During period1 no new tags (additions) were reported by the Reader, and no 2722 deletions were noted, thus no ECReports is generated. 2723 4. In period2, an EPC that does meet the filter conditions specified in the 2724 ECSpec is reported to the ALE layer by one of the Readers indicated in the 2725 ECSpec. 2726 5. At the end of period2, the requested ECReports is generated and sent to the 2727 client. 2728 6. In period3, no EPCs are reported, and no ECReports are generated. 2729 7. In period4 the client calls the unsubscribe method of the ALE interface. 2730 As this client is the only subscriber, the ECSpec transitions to the 2731 “Unrequested” state, and no further ECReports are generated. 2732 8. Because the ECSpec is Unrequested, the client can undefine the ECSpec 2733 without any error. 2734 13.2.2 Scenario 1b: Indirect Subscription 2735 The scenario shown below involves a client application specifying the EPC data that is of 2736 interest to another observer. After specifying the ECSpec, the client subscribes a third 2737 party observer to receive the resulting ECReports. The ECSpec shown in this 2738 scenario specifies the event cycle to start and stop using a trigger mechanism. This is a 2739 normal scenario involving no errors. 2740 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 67 of 71 2741 13.2.2.1 Assumptions 2742 1. All discovery, configuration, and initialization required has already been 2743 performed. 2744 2. The ALE layer is implemented as a distinct software component. 2745 3. ECSpec boundary conditions specified using startTrigger, stopTrigger 2746 4. ECFilterSpec includePatterns includes the EPC(s) illustrated in 2747 this scenario 2748 13.2.2.2 Description 2749 1. The ALE client calls the define methods of the ALE interface. The 2750 ECSpec contains a valid startTrigger and stopTrigger as boundary 2751 specifications – though any valid boundary conditions could be specified. The 2752 ECReportSpec and ECFilterSpec contained within the ECSpec is 2753 defined to include the EPC data sent later in step 4. 2754 2. The ALE client calls the subscribe method of the ALE interface which 2755 includes the URI of the intended observer. At this point the ECSpec is 2756 considered “Requested.” 2757 3. After the start trigger is received, the ECSpec is considered “Active.” 2758 Subsequent EPCs that meet the filter conditions in the ECSpec will be 2759 collected by the ALE layer. 2760 4. An EPC that does meet the filter conditions in the ECSpec is reported to the 2761 ALE layer. 2762 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 68 of 71 5. The stop trigger is received. The ECSpec transitions to the “Requested” 2763 state. 2764 6. The ECReports is generated and sent asynchronously to the observer. 2765 13.2.3 Scenario 2, 3: Poll, Immediate 2766 The scenario shown illustrates an ALE client using the poll method of the ALE 2767 interface to synchronously obtain the EPC data it is interested in collecting. The 2768 ECSpec shown in this scenario specifies the event cycle boundary to be a duration of 2769 time. Later in the scenario the ALE client uses the immediate method of the ALE 2770 interface, again synchronously obtaining EPC data. The combination of poll and 2771 immediate is not required, and only serves to illustrate a possibility. This is a normal 2772 scenario involving no errors. 2773 2774 13.2.3.1 Assumptions 2775 1. All discovery, configuration, and initialization required has already been 2776 performed. 2777 2. The ALE layer is implemented as a distinct software component. 2778 3. ECSpec boundary condition is specified as duration. 2779 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 69 of 71 4. ECFilterSpec includePatterns includes the EPC(s) illustrated in 2780 this scenario. 2781 13.2.3.2 Description 2782 1. The ALE client calls the define method of the ALE interface. The 2783 ECSpec contains a valid duration as the boundary specification – though 2784 any valid boundary conditions could be specified. The ECReportSpec and 2785 ECFilterSpec contained within the ECSpec are defined to include the 2786 EPC data sent later in steps 3 and 4. At this point the ECSpec is considered 2787 “Unrequested.” 2788 2. The ALE client calls the poll method of the ALE interface, naming the 2789 ECSpec previously defined in Step 1. At this point the ECSpec is 2790 transitioned to the “Active” state, and the event cycle begins for the duration 2791 specified in the ECSpec. During the duration of the event cycle the ALE 2792 client is blocked waiting for a response to the poll method. 2793 3. An EPC which meets the filter conditions of the ECSpec is received during 2794 the event cycle. At the end of the event cycle, the ECReports is generated 2795 and returned to the ALE client as the response to the poll method. At this 2796 point the ECSpec transitions to the “Unrequested” state. 2797 4. An EPC that meets the filter conditions of the ECSpec is reported to the ALE 2798 layer, but since there is no “Active” ECSpec, this EPC will not be reported. 2799 5. The ALE client invokes the poll method of the ALE interface a second time. 2800 This is similar to the process described above in Steps 2 and 3, but since no 2801 EPC is received, no EPC data is returned in the ECReports. 2802 6. Later, the ALE client calls the immediate method of the ALE interface. 2803 This is very similar to the use of poll, except that when the client calls 2804 immediate it provides the ECSpec as part of the method call, as opposed 2805 to referring to a previously defined ECSpec. Since a new ECSpec is 2806 provided with the immediate method, it can contain any valid combination 2807 of parameters and report options. 2808 2809 14 Glossary (non-normative) 2810 This section provides a non-normative summary of terms used within this specification. 2811 For normative definitions of these terms, please consult the relevant sections of the 2812 document. 2813 Term Section Meaning ALE (Application Level Events) Interface 1 Software interface through which ALE Clients may obtain filtered, consolidated EPC data from a variety of sources. Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 70 of 71 Term Section Meaning ALE (Application Level Events) Layer 2 Functionality that sits between raw EPC detection events (RFID tag reads or otherwise) and application business logic (an ALE Client). The ALE Interface is the interface between this layer and the ALE Client. ALE Client 2 Software, typically application business logic, which obtains EPC data through the ALE Interface. Event Cycle 3 One or more Read Cycles, from one or more Readers, that are to be treated as a unit from a client perspective. It is the smallest unit of interaction between the ALE Interface and an ALE Client. Read Cycle 3 The smallest unit of interaction of the ALE Layer with a Reader. Reader 3 A source of raw EPC data events. Often an RFID reader, but may also be EPC-compatible bar code reader, or even a person typing on a keyboard. Report 3 Data about event cycle communicated from the ALE interface to an ALE Client. Immediate Request 2 A request in which information is reported on a one-time basis at the time of request. Immediate requests are made using the immediate or poll methods of the ALE Interface. Recurring Request 2 A request in which information is reported repeatedly whenever an event is detected or at a specified time interval. Recurring requests are made using the subscribe method of the ALE Interface. Grouping Operator 5 A function that maps an EPC code into a group code. Specifies how EPCs read within an Event Cycle are to be partitioned into groups for reporting purposes. Physical Reader 7 A physical device, such as an RFID reader or bar code scanner, that acts as one or more Readers for the purposes of the ALE Layer. Logical Reader Name 7 An abstract name that an ALE Client uses to refer to one or more Readers that have a single logical purpose; e.g., DockDoor42. 2814 15 References 2815 [ISODir2] ISO, “Rules for the structure and drafting of International Standards 2816 (ISO/IEC Directives, Part 2, 2001, 4th edition),” July 2002. 2817 Copyright © 2005, 2004 EPCglobal Inc™, All Rights Reserved. Page 71 of 71 [RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, “Uniform Resource Locators 2818 (URL),” RFC 1738, December 1994, http://www.ietf.org/rfc/rfc1738. 2819 [RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers 2820 (URI): Generic Syntax,” RFC2396, August 1998, http://www.ietf.org/rfc/rfc2396. 2821 [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. 2822 Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC2616, June 1999, 2823 http://www.ietf.org/rfc/rfc2616. 2824 [Savant0.1] Oat Systems and MIT Auto-ID Center, “The Savant Version 0.1 (Alpha),” 2825 MIT Auto-ID Center Technical Manual MIT-AUTO-AUTOID-TM-003, February 2002, 2826 http://www.autoidlabs.org/whitepapers/MIT-AUTOID-TM-003.pdf. 2827 [Savant1.0] S. Clark, K. Traub, D. Anarkat, T. Osinski, E. Shek, S. Ramachandran, R. 2828 Kerth, J. Weng, B. Tracey, “Auto-ID Savant Specification 1.0,” Auto-ID Center Software 2829 Action Group Working Draft WD-savant-1_0-20031014, October 2003. 2830 [TDS1.1] EPCglobal, “EPC Tag Data Standards Version 1.1 Rev.1.24,” EPCglobal 2831 Standard Specification, April 2004, 2832 http://www.epcglobalinc.org/standards_technology/EPCTagDataSpecification11rev124.p2833 df. 2834 [WSDL1.1] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, “Web Services 2835 Description Language (WSDL) 1.1,” W3C Note, March 2001, 2836 http://www.w3.org/TR/2001/NOTE-wsdl-20010315. 2837 [WSI] K. Ballinger, D. Ehnebuske, M. Gudgin, M. Nottingham, P. Yendluri, “Basic 2838 Profile Version 1.0,” WS-i Final Material, April 2004, http://www.ws-2839 i.org/Profiles/BasicProfile-1.0-2004-04-16.html. 2840 [XML1.0] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau, 2841 “Extensible Markup Language (XML) 1.0 (Third Edition),” W3C Recommendation, 2842 February 2004, http://www.w3.org/TR/2004/REC-xml-20040204/. 2843 [XSD1] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, “XML Schema Part 1: 2844 Structures,” W3C Recommendation, May 2001, http://www.w3.org/TR/xmlschema-1/. 2845 [XSD2] P. Biron, A. Malhotra, “XML Schema Part 2: Datatypes,” W3C 2846 Recommendation, May 2001, http://www.w3.org/TR/xmlschema-2/. 2847 [XMLVersioning] D. Orchard, “Versioning XML Vocabularies,” December 2003, 2848 http://www.xml.com/pub/a/2003/12/03/versioning.html. 2849 2850
还剩70页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 6 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf