No current markup language has any formal support for barcodes, in spite of the low complexity in encoding and displaying them.

As barcodes do involve math, Math-ML would be the best candidate for adopting the tag. However, as graphic display is involved SVG would also be the best candidate. Therefore this proposal is for a joint SVG + Math-ML adoption of this tag.

Any barcode markup and display standard that becomes deployed on web browsers and HTML word processors should be revised every 2 or 3 years.

Barcodes can be difficult and expensive for websites to adopt, when the browsers that visit the website have access to all the computational machinery they need to generate barcodes rich in data in under 100ms of CPU time.

To cope with the vast number of bar codes that have been formally adopted as standards, a mechanism is needed that will accommodate most possibilities of barcode encoding. This sounds simple, but barcodes are extremely variable and this is no easy task.

It is assumed that any implementation of this machinery at the web browser level must be done with a codebase that is in the public domain and open source. Complexity reduction is vital, but it may take up to 5 years to perfect the technology.

It is assumed that the web browser should allow the user to specify some minimal parameters for barcode generation. This could be fit in with settings that apply to SVG or Math Markup Language where needed. Subpixel rendering, and anti-aliasing should not be allowed.

• "[-]" in the above syntax designates mode and encoding information, it would not show up in the normal syntax.
• CODE here specifies the actual contents of the barcode. For barcodes that permit coding of ancillary data, this data should not be placed here -- but should be in the encoding information area.
• Bar codes have the following properties, but not universally : Checkdigit, Checksum, Error Correction Mode, Error Correction Type, Ancillary Content.
• The barcode syntax, should as general principal -- not encode any more than 2 kb of data or text.
• The barcode syntax should work only with standard low complexity barcodes -- so no coding or barcodes that are in colour or proprietary.
• To cope with different screen or printer conditions, it may be permitted to add "polarity=-1" to reverse the barcode's default black on white display mode. Using the polarity tag must mean that any other colour tag must be ignored.
• It may be permitted to display the barcodes in other screen colours other than black or white. The standard xml or html oriented 24 bit colour semantics that apply to text display must be reused here with no alteration. At this point in time there is no formal support for the practice, but if it is adopted it must be the same syntax as text colour coding.

• within mode="{}"
• within ecc="{{}}"
• within ecm="*" (syntax varies with barcode type)
• within addon="+"

• Designator should not exceed 8 characters, these characters being capitalized alpha or numbers with no spaces.
• Error Correction Type, if fixed for a barcode should not be generated in the valid syntax for that barcode.
• Error Correction Mode should work in terms of percents. This syntax is only permitted for use in 2D matrix barcodes.
• For Aztec, Datamatrix, ... and similar 2D matrix bar codes but no other codes : the dimension must be specified after the 2 letter alpha designator for this class of barcodes. If the user wants automatic generation based on the size of the data "##" must proceed the 2 letter designation like this : DM##, AZ## ... etc.
• Polar based bar codes should have P as the initial letter in their type designator for clarity.
  

• For simple fixed length "digit only" or "mixed alpha numeric" bar codes simple ASCII-7 (capitalized Alpha only) text must be enforced. This rule should apply to Linear bar codes of less than 36 characters in length.
• No spaces should be permitted in "short" Linear barcodes.

• No spaces should be permitted. 
• Human readability should not be permitted, these are not Linear barcodes. The WYSIWYG editor should provide a user interface to specify the content of the barcode.
• Coding should be in Base 32. Base 64 may be widely used on the web, but not here.
• Coding should always be in binary, coded to Base 32.
• The ECC mode or ancillary content information should tell the barcode display system what is being coded.

1. "S Y N" unknown syntax error. 
2. "E C C" for Error Correction Code or Error Correction Mode errors.
3. "T Y P" type error (generally Upper or Lower case incursions), this could cover a lot of token syntax errors too.
   
4. "L L L" CODE content too long or short for barcode type.
   
5. "D A T" Data to be encoded is the wrong data type for the barcode specified.
6. "Z Z Z"  Rending system failure, all else fine.
   

• XML
• Scalable Vector Graphics
• MathML
• HTML5

• Template : Barcodes
• Template : Paper data storage media

• Check digit
• Modular arithmetic
• Luhn algorithm
• Verhoeff algorithm
• Reed–Solomon_error_correction

• Base32
• http://tools.ietf.org/html/rfc4648