The Application Level Events (ALE) Specification, Version 1.0 - GS1
The Application Level Events (ALE) Specification, Version 1.0 - GS1
The Application Level Events (ALE) Specification, Version 1.0 - GS1
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
1078<br />
1079<br />
1080<br />
1081<br />
1082<br />
1083<br />
1084<br />
1085<br />
1086<br />
1087<br />
1088<br />
1089<br />
1090<br />
1091<br />
1092<br />
1093<br />
1094<br />
1095<br />
1096<br />
1097<br />
1098<br />
1099<br />
1100<br />
1101<br />
1102<br />
1103<br />
1104<br />
1105<br />
1106<br />
1107<br />
1108<br />
1109<br />
1110<br />
1111<br />
1112<br />
1113<br />
1114<br />
Each distinct tag value included in the report SHALL have a distinct<br />
ECReportGroupListMember element in the ECReportGroupList, even if those<br />
ECReportGroupListMember elements would be identical due to the formats<br />
selected. In particular, it is possible for two different tags to have the same pure identity<br />
EPC representation; e.g., two SGTIN-64 tags that differ only in the filter bits. If both<br />
tags are read in the same event cycle, and ECReportOutputSpec specified<br />
includeEPC true and all other formats false, then the resulting<br />
ECReportGroupList SHALL have two ECReportGroupListMember elements,<br />
each having the same pure identity URI in the epc field. In other words, the result<br />
should be equivalent to performing all duplicate removal, additions/deletions processing,<br />
grouping, and filtering before converting the raw tag values into the selected<br />
representation(s).<br />
Explanation (non-normative): <strong>The</strong> situation in which this rule applies is expected to be<br />
extremely rare. In theory, no two tags should be programmed with the same pure<br />
identity, even if they differ in filter bits or other fields not part of the pure identity. But<br />
because the situation is possible, it is necessary to specify a definite behavior in this<br />
specification. <strong>The</strong> behavior specified above is intended to be the most easily<br />
implemented.<br />
8.3.6 ECReportGroupCount<br />
An ECReportGroupCount is included in an ECReportGroup when the<br />
includeCount field of the corresponding ECReportOutputSpec is true.<br />
count : int<br />
<br />
---<br />
<strong>The</strong> count field is the total number of distinct EPCs that are part of this group.<br />
9 Standard Notification URIs<br />
This section specifies the syntax and semantics of standard URIs that may be used in<br />
conjunction with the subscribe and unsubscribe methods of the main <strong>ALE</strong><br />
interface (Section 8.1). Each subsection below specifies the conformance requirement<br />
(MAY, SHOULD, SHALL) for each standard URI.<br />
All notification URIs, whether standardized as a part of this specification or not, must<br />
conform to the general syntax for URIs as defined in [RFC2396]. Each notification URI<br />
scheme may impose additional constraints upon syntax.<br />
9.1 HTTP Notification URI<br />
<strong>The</strong> HTTP notification URI provides for delivery of ECReports in XML via the HTTP<br />
protocol using the POST operation. Implementations SHOULD provide support for this<br />
notification URI.<br />
Copyright © 2005, 2004 EPCglobal Inc, All Rights Reserved. Page 37 of 71
Change language