[shape-detection-api] Enum values that ignore naming conventions in Accelerated Shape Detection in Images

[dontcallmedom-bot]

While crawling Accelerated Shape Detection in Images, the following enum values were found to ignore naming conventions (lower case, hyphen separated words):

• The value "code_128" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "code_39" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "code_93" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "data_matrix" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "ean_13" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "ean_8" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "qr_code" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "upc_a" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)
• The value "upc_e" of the enum BarcodeFormat does not match the expected conventions (lower case, hyphen separated words)

See Use casing rules consistent with existing APIs in Web Platform Design Principles document for guidance.

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

[reillyeon]

That's unfortunate, but I don't think we can fix this now that the API has shipped. @dontcallmedom, how can I mark these to acknowledge the mistake and avoid the bot triggering on it again?

[dontcallmedom]

I want to push back a bit on it being too late - AFAIK, this has shipped only in one browser engine, and it remains a spec in incubation; the level of adoption doesn't look (to my perhaps naive eye) such that migrating existing users to new names would be out of question.

I understand this is perhaps a minor inconsistency in the grand scheme of things, but from my perspective, each time we break naming rules we make them less useful and relevant for the platform as a whole, not just an individual spec.

In any case, if the issue is closed without change, we have the mechanism in place in strudy to make sure it doesn't get filed again. cc @tidoust

[reillyeon]

I agree in general that since this is only shipped in one browser engine this change could be made and being the first implementer of a spec in incubation carries the risk of having to make incompatible changes later in the standards process. My concern in this particular case is that migrating existing users to new names is difficult because these enum values are not only accepted by the BarcodeDetector() constructor (where we could warn on use of the deprecated values) but are also returned by the BarcodeDetector.getSupportedFormats() method. In that case I can't think of a way of detecting code that expects one of the deprecated enums (e.g. qr_code) in order to produce such a warning.

I intend to add a note to the specification acknowledging the inconsistency with recommended patterns so we avoid adding additional inconsistent enum values in the future.

[dontcallmedom]

re BarcodeDetector.getSupportedFormats(), it could maybe return both forms during the deprecation period, and presumably developers would get the deprecation notice upon using it with the constructor?

Anyway, you're definitely better positioned than me to assess the trade-off between consistency and the cost of deprecation; we'll make sure strudy reflects whatever decision is taken.

[tomayac]

The getSupportedFormats() could return both, but after detection, the format needs to return the old value by force, it can't suddenly return both if no code breakage (during a transition period) is an objective.