search

WICG / shape-detection-api

Detection of shapes (faces, QR codes) in images
https://wicg.github.io/shape-detection-api
Other
306 stars 36 forks source link

Optional interpretation of GS1 barcode #45

Closed philarcher closed 6 years ago

philarcher commented 6 years ago

GS1, the standards organization behind the identifiers encoded as barcodes throughout the global supply chain, most famously the barcodes that go beep at the checkout, is (perhaps belatedly) working to bring its system to the Web. In August, we published a new standard (PDF, sorry) encoding any valid combination of GS1 identifiers in an HTTP URI and we're now working on a bunch of issues around defining resolver services, semantics and a compression algorithm. The latter is important as if you encode a GTIN (the high level product identifier that goes beep at the checkout) and the batch/lot number, a serial number and an expiry date into a URI it ends up being way too long to fit reliably in a QR code. So we need to reduce the number of characters but can't require an online look up in a critical system. So bit.ly and friends are not an answer.

One of the aims of the GS1 work is to (over time) make it possible for a URL in a QR code to be used in the same way the familiar 1D barcode is used today. The one code therefore does the job of providing a consumer-facing link and a supply chain ID. Another aim is to enable all GS1 barcodes, whatever the symbology, to act as a gateway to the Web. The new standard - which just defines a syntax that at its most basic is just https://example.com/gtin/{gtin} - is getting a lot of attention from major brands and retailers and I am hopeful of substantial adoption.

Anyway... lots more to say about this if people want me to but the essence of the issue here is whether is not the developer community would see value in augmenting the API to work directly with the dominant global product identification system by including:

  1. the compression/decompression algorithm (currently being defined and expected around Q1 2019);
  2. a simple syntax for sending a GTIN to a GS1 conformant resolver service, i.e. if the barcode reader returns 614141123452 and a consumer product variant of '2A' (think of a Coke bottle with the name 'Tim' on it as opposed to 'Martha'), the API would automatically generate the correctly formatted URL of {givenStub}/gtin/614141123452/cpv/2A.

If I may push a little further, we might even have a default resolver service of id.gs1.org, see - you guessed it - https://id.gs1.org/gtin/614141123452/cpv/2A.

Of course, all this can be done by including the separate code library we're working on, and not making it part of the standard API, but it's a lot simpler if things like this work out of the box.

reillyeon commented 6 years ago

This seems like something that should be implemented in a separate library. The scope of this API is limited to providing access to hardware accelerated/OS provided barcode decoding capabilities. Post-processing of the barcode contents (such as interpreting a QR code as a GTIN) could be included in a library which also provides software fallbacks when this API is not available.