1 Introduction
1.1 Purpose
GS1 is a multinational organisation with writers located all over the world. Without a unified GS1 documentation style, problems with inconsistency and poor readability can occur across documents and across departments.
A document with typographical errors, ungrammatical constructs, or inconsistent structure and format can create questions about the accuracy of the content itself and ultimately reflects poorly on GS1 as a whole. Writers who dismiss the importance of presentation (consistent style, format, word use and so on) risk dissatisfied and unhappy readers.
To address these issues, GS1 has created an authoritative GS1 Style Guide that serves several purposes:
■ To set rules and conventions for grammatical style, standardised spellings, proper word usage and correct punctuation
■ To provide guidelines for writing procedures and scenarios, as well as using graphics
■ To provide a standard, unifying document that all writers in GS1, regardless of their level or function, can or use to easily and quickly improve the quality and consistency of their documentation
The information in this GS1 Style Guide is based on the previous GSMP Style Guide developed for technical publications and updates from the 2014 GS1 global branding project. Another important reference for ensuring consistency to the new branding and this style guide is: GS1 standards glossary of terms: www.gs1.org/glossary
2 Applicable to all GS1 documentation
2.1 GS1 spelling rules
2.2 Terminology rules
2.3 Use sentence case for headings
2.4 Document title formatting in running text
2.5 Abbreviation and symbol rules
2.6 Punctuation and grammar rules
2.7 Figures, tables and flowcharts
2.8 Images and flowcharts
2.9 Bulleted lists
2.10 Footnotes
2.11 Hyperlink and cross-reference rules
2.12 Numbered lists
2.13 Units of measure
2.14 Number/digit rules
2.15 Terms to reference parenthetically
2.16 Use of the term U.P.C.
2.17 Name used for example companies
2.18 GS1 prefix 952 for examples
2.19 Avoid using manual page breaks
2.20 Citing external sources
2.21 Use of the terms 'barcode' and 'symbol'
It is essential that all GS1 documentation: press release, training, standard, website, etc. use consistent spelling and style. The chosen GS1 spelling and style is British English per the Collins online dictionary:
Note: When using MS Word, set the language to English (U.K.).
Within British English often two alternate spellings are acceptable for example organisation and organization. In such cases GS1 must make a choice. The table below summarises the GS1 preference.
Table 2‑1 Examples of spelling conversions
* in British English licence with a c is used for the noun and license with an s is used for the verb.
2.1.1 Exceptional spelling rules for GS1 machine-readable artefacts
A machine-readable artefact is defined as: Any GS1 technical file, which may be part of a GS1 standard, guideline or service, where the intended use is for direct machine-to-machine interpretation. This includes but is not limited to: GS1 Web Vocabulary; Application Programming Interfaces (APIs); Machine-readable code; Uniform Resource Identifiers (URIs).
For such items, the US spellings per the Merriam-Webster English Dictionary shall be used.
The rationale for this exception is that most machine-readable artefacts are based on 3rd party platforms, such as https://www.schema.org/ and https://www.w3.org/, which themselves are based on US English.
Use www.gs1.org/glossary to define and research terminology.
Use the registered trademark symbol,®, the first time any GS1 registered trademark appears in the document and only once. If the first occurrence is a heading, use the symbol in the next occurrence.
■ Example:
□ GS1 DataBar® is the preferred barcode symbol (first occurrence).
■ Exception:
□ Do not use ® on GS1 since the ® sign is included in the logo and the words “GS1 and the GS1 logo are registered trademarks of GS1 AISBL” are always included in the disclaimer.
List of registered terms held by GS1:
□ DataBar®
□ EANCOM®
□ EPCglobal® limited use with regard to legal entity
□ GDSN®
□ GEPIR®
□ GS1®
□ Global Trade Item Number®
□ GS1 Global Registry®
□ GTIN®
Follow these additional guidelines for terminology:
■ barcode is one word
■ business-to-business (B2B)
■ business-to-business-to-consumer (B2B2C)
■ business-to-consumer (B2C)
■ data pool is two words
■ database is one word
■ defence
■ e-commerce
■ e-tailer
■ email is one word and does not include a hyphen
■ EPC/RFID for standards and guidelines. RAIN RFID may be used in marketing and communications material ONLY.
■ EU Food Information Regulation 1169/2011 (EU 1169)
■ European Union (EU)
■ go to market
■ Industry/industries – use when referring to all industry sectors
■ internet
■ Marketplaces is one word
■ omni-channel
■ online is one word and does not include a hyphen. Use this term when referring to the media type, rather than alternatives such as “web”
■ order-to-cash
■ point-of-sale (POS)
■ Verified by GS1 never GS1 Verified or VbG
■ web
■ webpage is one word
■ website is one word
Minimising the use of capital letters in headings makes them easier to read, so use sentence case – when only the first word is capitalised:
■ Rationale: overuse of capitals can make text more difficult to read; use of lowercase gives us a more relaxed and approachable tone of voice.
■ Examples:
□ Correct: GS1 helps companies drive efficiency and safety
□ Incorrect: GS1 helps companies drive Efficiency and Safety
□ Correct: Our business benefits in retail
□ Incorrect: Our Business Benefits in Retail
2.3.1 Capitalisation of terms
For GS1 terms, follow the style shown in the www.gs1.org/glossary . Use initial capital letters for nouns that identify a particular person, place or thing, including the proper name of an entity.
Note: Do NOT capitalise initial letter of the word “standard” even when using with GS1 unless referencing the title of a specific document (e.g., GS1 Digital Link Standard)
■ Rationale: Minimal use of capitals makes text easier to read; use of lowercase gives us a more relaxed and approachable tone of voice; GS1 is an adjective describing “standards” in this case
■ Examples:
□ Correct: GS1 is a standards organisation
□ Correct: GS1 develops global standards
□ Correct: GS1 standards help companies improve supply chain efficiency
□ Incorrect: GS1 Standards help companies improve supply chain efficiency
Spelling for terms that begin with capital letters when GS1 is used as part of the name:
■ GS1 Application Identifiers
■ GS1 Architecture Principles
■ GS1 Company Prefix
■ GS1 Data Quality
■ GS1 Data Quality Framework (DQF)
■ GS1 DataBar
■ GS1 DataMatrix (note Data Matrix is the generic symbology used to encode GS1 Digital Link)
■ GS1 Digital Link
■ GS1 EANCOM
■ GS1 EDI
■ GS1 EPCglobal
■ GS1 General Specifications
■ GS1 Global Data Model
■ GS1 GLN Registry
■ GS1 GLN Service
■ GS1 Global Data Synchronisation Network (GDSN)
■ GS1 Global Electronic Party Information Registry (GEPIR)
■ GS1 Global Registry Platform (GRP)
■ GS1 Global Standards Management Process (GSMP)
■ GS1 identification key
■ GS1 Licence Registry (used to power the GDSN)
■ GS1 Logistics Interoperability Model (LIM)
■ GS1 Navigator
■ GS1 Prefix
■ GS1 QR Code (note QR Code is the generic symbology used to encode GS1 Digital Link)
■ GS1 System Architecture
■ GS1 XML
■ Verified by GS1
2.3.2 Capitalisation in abbreviations
When an abbreviation is first used in a document, spell out the term it replaces using initial capital letters:
■ Rationale: Abbreviations and acronyms are not readily understood by people who are new to GS1.
■ Examples:
□ Correct: The Global Data Synchronisation Network (GDSN) allows companies to share data
□ Incorrect: GDSN allows companies to share data
■ Exceptions:
□ The abbreviation “ID” is the conventional acronym for the word “identification”.
□ Avoid using confusing or easily mixed up acronyms in one document (e.g., GCP (Global Company Prefix) and GPC (Global Product Classification).
■ Exceptions: Terms where GS1 places the abbreviation before its explanation:
□ UHF (Ultra High Frequency)
□ HF (High Frequency)
□ RFID (Radio Frequency Identification)
□ EPC (Electronic Product Code)
□ EPC-enabled RFID (in general) or EPC/RFID (when shortened version needed)
2.3.3 Capitalisation of section, chapter, appendix, table and figure
Capitalise the first letter of the word “section”, “chapter”, “appendix”, “table”, or “figure” only when it refers to a specific section, chapter, appendix, table or figure.
■ Examples:
□ The next section will discuss the GS1 Company Prefix.
□ See Figure 3-29 for an illustration of this symbol.
□ The figure below illustrates this process.
2.3.4 Capitalisation of GS1 keys
When referring to GS1 keys, the following list of terms shall be used if the intent is to be comprehensive:
□ Global Trade Item Number (GTIN)
□ Global Location Number (GLN)
□ Serial Shipping Container Code (SSCC)
□ Global Returnable Asset Identifier (GRAI)
□ Global Individual Asset Identifier (GIAI)
□ Global Service Relation Number (GSRN)
□ Global Document Type Identifier (GDTI)
□ Global Shipment Identification Number (GSIN)
□ Global Identification Number for Consignment (GINC)
□ Global Coupon Number (GCN)
□ Component/Part Identifier (CPID)
□ Global Model Number (GMN)
Unlinked titles of documents should always be italicised in running text. However, do not italicise the words “section”, “chapter”, “appendix”, “table” or “figure” and do not italicise the titles and numbers of a section, chapter, appendix, table or figure.
■ Examples:
□ Correct: See the Microsoft Style Guide
□ Correct: See the Microsoft Style Guide
□ Incorrect: See the Microsoft Style Guide
Note: When referring to specific document titles in references or hyperlinks, avoid including the date the document was published, released, or approved, or include its issue number unless it is critical to the context.
This section describes the rules for using abbreviations and symbols.
Note: For currency abbreviation rules, see section 2.14.9.
2.5.1 Use of symbols
Some key rules are:
■ Do not abbreviate the word “and” as “&” unless the word appears in a figure or table that has limited space.
■ Do not abbreviate the word “plus” as “+” unless the word appears in a figure or table that has limited space.
■ Never abbreviate the word “degrees” as “°.”
■ Never abbreviate numbers, such as first, second, third, or fourteenth, using the conventions “st,” “nd,” “rd,” or “th.”
2.5.2 Dates
Some key rules are:
■ If not spelled out in full, use the format DD MM YYYY for expressing dates. No punctuation is used between day, month or year.
■ Examples (full format, month spelled out)
□ Correct: The new standard was released on 1 December 2024
□ Incorrect: The new standard was released on December 1, 2014
■ Examples (abbreviated format)
□ Correct: 1 Dec 2024
□ Incorrect: 01 Dec 2024
□ Incorrect: 1-12-24, 12-1-24, Dec-1-24
Note: See section 2.14.9 for punctuation of currency.
2.6.1 Hyphens in compound words
Note: See section 2.2 for guidance on hyphen use in technical terminology.
In running text, always hyphenate compound words that are hyphenated in the www.gs1.org/glossary or the dictionary. If a term is not hyphenated in the www.gs1.org/glossary, do not add a hyphen.
■ Examples:
□ ITF-14
□ X-dimension
□ self-evident
□ wall-to-wall
In running text, hyphenate compound words when they are common English expressions that might be confusing or ambiguous without the hyphens.
■ Examples:
□ ship-to address
□ end-user manuals
□ in-store sale
□ point-of-sale
Note that in most cases compound words that are NOT used directly before a noun are not hyphenated.
■ Examples:
□ Decision making is one of his responsibilities. (but) His decision-making skills were superb.
□ I’m good at problem solving. (but) Problem-solving activities are educational.
2.6.2 Prefixes and suffixes
A prefix or suffix usually combines with a word without a hyphen or space, as in dehumidify and lifelike, unless the meaning could be misconstrued.
■ Examples:
□ Untie the knot.
□ He recovered in time to attend the meeting. (but) He re-covered the illegible label with a new one.
2.6.3 Spacing
After a full stop or a colon place a single space. Do not use a double-space.
2.6.4 Use of "may" versus "can"
Can means “to be able.”
May means “to have permission.”
2.6.5 Use of "that" versus "which"
Use “that” to introduce a dependent clause (sometimes called a limiting or defining clause). These are clauses that cannot be removed from the sentence without greatly affecting the sentence’s meaning.
Use “which” to introduce an independent clause (sometimes called a non-defining or parenthetical clause). Independent clauses can be removed from the sentence without harming the basic sense of the sentence.
Note: “which” is almost always preceded by a comma and introduces an independent clause.
■ Examples:
□ The ID number, which is located on the label, should be clearly legible.
□ The digit that is in position thirteen is the check digit.
2.6.6 Using “e.g.”
To give the reader examples of something in running text, use the initials “e.g.” This stands for the Latin phrase meaning “for example” or “such as”. Do not confused with “i.e.,” which means “that is.”
Note: A comma should always follow the second full stop in “e.g.”
■ Example:
□ Products modified for seasonal reasons (e.g., holiday packs) should carry a unique GTIN-12.
2.6.7 Using several examples in running text
When presenting several examples in running text following “e.g.,” it is not necessary to include the word “and” or “or” prior to the last example unless the word helps to clarify the sentence’s meaning.
■ Examples:
□ Visually inspect the imaging tool for damage (e.g., nicks, plugs, tears).
□ GS1 barcodes require dark colours for bars (e.g., black, dark blue, dark brown or dark green).
2.6.8 Do not use comma before “and” (unless necessary)
Do not use a comma before “and” and “or” in a series.
■ Examples
□ Correct: The new standard enables efficiency, sustainability and safety.
□ Incorrect: The new standard enables efficiency, sustainability, and safety.
There are examples where a comma is necessary after the “and” or “or” for clarity. In such cases the Oxford comma should be used.
■ Examples
□ Correct: Karen went to the meeting with her sisters, Paul, and John
□ Incorrect: Karen went to the meeting with her sisters, Paul and John
2.6.9 Parentheses with GS1 Application Identifiers
Include parentheses around a GS1 Application Identifier except when it is used in a table or figure.
■ Example:
□ Use the GS1 Application Identifier (8100) for coupons.
Figures
Figures enhance a document’s readability by illustrating key points, better communicating ideas and helping readers navigate through sometimes confusing interfaces.
When using figures, it is recommended to:
■ Avoid using figure titles and numbering at all, if the figure is well positioned and explained by the text (e.g., “as shown in the figure below:”), such that a title would be superfluous.
■ Position the figure number and title below the image, preferably with both image and title being centred.
Thumbnail of the GS1 Logo
The figure numbers should be in the format [Highest level section number] - [the sequential figure number within the highest level section number]
Note: Using the GS1 Word templates will automatically create the correct figure and table caption numbering in your documents.
Tables
Tables display lengthy and complex information in a simple format and enable readers to quickly find, compare, classify, etc.
Note: When publishing as HTML, large tables often look unwieldly and other presentation formats should be considered.
If tables are used, they should use the default format provided in the GS1 Word template:
Or, for more complex tables where multiple headings are required, the GS1 blue filled title heading and 50% grey fill for secondary headings:
Note: Any notes in the table should be included the last row of the table.
The table numbers should be in the format [Highest level section number] - [the sequential table number within the highest level section number] and should appear above the table flush left
Table 2-1: An example of a GS1 table heading
Note: Using the GS1 Word templates will automatically create the correct figure and table caption numbering in your documents.
Flowcharts
Flowcharts are excellent for showing system logic or other flows. Ideally, they should be created as separate files – using an appropriate software like PowerPoint – and imported into the document as an image. When inserted they should be labelled as figures.
Example of an SVG image
2.7.1 Figure and table numbering in the GS1 General Specifications
Figure numbering in the GS1 General Specifications follows a different system. Figures are numbered sequentially based on the sequential number of the figure within its subsection (not the highest section number).
■ Examples:
Figure 16.1–1. Barcodes in Ladder Orientation
[Subsection number] – [the sequential figure number within the subsection]: [title]
Figure 16.3–3. GS1 Data Structures
[Subsection number] – [the sequential table number within the subsection]: [title]
Figure A.5–1. GS1 Identification Keys
[Subsection appendix letter and number] – [the sequential figure number within the appendix subsection]. [title]
At the time of writing (2024) there are several emerging challenges for GS1 in terms of images and flowcharts:
1. Making the text held within images searchable (for any image posted as part of an HTML page)
2. Compatibility with ISO image standards (where GS1 standards are transposed to ISO standards either as a whole or in part)
3. Having published images scale to fit the screen (the same image can appear on a mobile device or a large PC screen)
4. Sharing, storing and reusing images across GS1 (services, standards, marketing, etc.)
To meet these challenges, there are some recent changes to this section of the GS1 Style Guide and we can expect further changes as we learn and understand how best to meet the various requirements. A high-level summary of the new guide is:
■ Changes to existing images are NOT required.
■ New images are ideally created in Adobe Illustrator:
□ Saved as separate editable files in a folder associated with the text file (word document).
□ Inserted in the document in *.SVG format
□
Ø Naming convention for the image files / folder?
Ø Location for the image files associated with a standard or guideline (MOZone, Image Bank, Teams?)
Ø Consistency of images within a given standard or guideline (info-graphics, PPT extract, photos, etc.
Ø Links to other sections: GS1 prefix 952 for examples, Figures, tables and flowcharts
Ø Can/should flow-charts be created in Adobe?
■ Should avoid using colour as the only way to convey information
2.8.1 Adobe Illustrator
GS1 recommend Adobe Illustrator for the creation of new images. To be compatible with the ISO image standards the following defaults are recommended for a new image:
■ Width 170 mm, height 225 mm
■ Portrait orientation
■ 1 artboard
■ Bleed 0, 0, 0, 0
■ Color mode CMYK
2.8.2 Do not use ONLY colour to convey meaning
Due to accessibility, do not use colour as the exclusive way to convey meaning. Not all readers can distinguish between colours and, if viewed in black and white, the meaning will be unclear. Patterned shading can be used or dots and dashes, rather than colours, to differentiate between lines on a graph.
■ Example:
□ Correct:
□ Incorrect:
2.8.3 Inserting images and flowcharts
Images on screen can appear identical to the naked eye but behave quite differently in terms of load time, visual quality, background-colours, editability, etc. depending on where the image is being used. It is therefore important to keep the intended usage in mind when developing or inserting images.
While other methods are acceptable the following guidance is intended to provide consistency and highlight the issues faced.
2.8.3.1 File types for print
SVG is preferred. EPS, TIFF and JPG image formats may be used for print materials such as brochures, posters, banners, postcards, etc. These formats should always be saved in a CMYK colour space.
2.8.3.2 File types for digital
SVG is preferred. PNG, JPG and GIF image formats may be used for digital pieces such as PowerPoints, Word documents, web pages, social media posts, emails, etc. These formats should always be saved in an RGB colour space.
2.8.3.2.1 HTML
Increasingly GS1 standards and guidelines, as well as other GS1 publications, are being published as webpages (e.g., using HTML) using images that:
■ can scale with the screen
■ are quick to load
The most appropriate format in this case is normally SVG (Scalable Vector Graphic). Readability, particularly of images or flow charts containing text, will be optimised even when viewed on small screens.
2.8.3.2.2 Images in Word
MS Word enables different ways for images appear in documents.
For material that will appear in HTML:
■ See HTML section above
■ Images should be formatted as *.svg
For material that will appear in print or PDF:
■ Recommend format *.png (aligned with images available from GS1 marketing)
For all images inserted into MS Word:
■ Insert images using the MS Word Command Insert > Picture then browse to the image file and ensure that the text wrapping option for the image is In Line with Text.
□ Do NOT use the option "link to file" when you insert or embed an image. This links the Word document to the image file stored on your computer. When the file is exchanged with others, this link may cause problems. Also avoid using copy-paste of images.
■ Maintain all original artwork with Word (editable) version of documents. If you create your own, these should be part of the final files sent for posting to the website. Any graphic tool can be used to create *.png format images. PowerPoint is a simple and easy to use graphic editing tool and files can be saved using the same-file-name.pptx as the file to be posted.
■ Avoid any text in images (not translatable).
■ Avoid creating images in Word due to formatting (anchoring) issues and compatibility between the various versions of Word.
Bulleted lists are used for cases where the order of information is not important.
Follow these rules when writing bulleted lists:
■ A bulleted list should contain at least two bullets.
■ Introduce the list with at least one lead-in sentence (or sentence fragment) ending with a colon, for example, see the lead-in sentence above.
■ After the colon, capitalise the first word of each list item, even if it is a single word.
Note: Do not capitalise programming code or case-sensitive words.
■ Punctuation in bulleted lists:
□ Single words, phrases and sentence fragments do not get a full stop.
□ Items consisting of one or more sentences or two or more sentence fragments do receive full stops.
□ If one item in a list receives a full stop all other items in that list do as well, regardless of whether they are sentence fragments or full sentences.
AVOID footnotes or endnotes in any documents that will be converted into a webpage as these do not work well on webpages.
If supplemental information for the reader is necessary, include the information as a note (See section 3.6) following the applicable text. If several notes apply to a specific section, they may be numbered (e.g., Note 1, Note 2) or carry asterisks.
Hyperlinks and cross-references point to items that appear in another location within a document or website. They can also be references to external documents or websites.
Cross-references can be typed manually. As you revise your document, however, there is a good chance that the pagination, section headings, figure numbers and so on will change, requiring you to update them all. To avoid this, all cross-references should be inserted as automated fields.
The information in this section describes the wording and formation to use when inserting hyperlinks and cross-references.
2.11.1 Cross-references to a section within document
When linking to a single location within a document, references to the location should contain the section’s number. Typically the section number alone is sufficient for cross-references as it should have sufficient context in the surrounding text enabling it to be verified. Avoid using the unnecessary phrase “in this guideline” or “in this document.” The text should be formatted as underlined blue font (Hex #008DBD).
■ Example:
□ See section 2.2, for an explanation of this process.
Cross-references to multiple locations
When linking to multiple locations reference all of the locations individually so they can be individually linked.
■ Examples:
□ See Figure 3-1, Figure 3-2 and Figure 3-3, for more details.
□ For an illustration of this technique see sections 2-5 and 2-6.
Note: When referring or linking to a table or figure, do not include the table’s or figure’s section number, as this information should be obvious from the table or figure number.
2.11.2 Cross-references to an external document
For all HTML publications, links to the www.gs1.org website should be a regular link, while links to non-GS1 websites should have a symbol to indicate the page will open in a new tab or page
When referencing an external document, the complete document title must be included in the text. If you know the document’s location on the GS1 website it should be hyperlinked to its location.
When referencing a single location of an external document, the document title must precede the location.
Format the title and/or section as underlined with a blue font only if an actual hyperlink exists. If there is no hyperlink, then do not format with underline and blue font.
■ Examples:
□ See GS1 General Specifications, for an explanation of this process.
□ See GS1 XML Technical User Guide, Release 2 for further information.
Note: When referring to contact details, a web link is always preferable to including an email address:
■ Examples:
□ Correct: For more information, contact your local GS1 Member Organisation
□ Incorrect: For more information, contact JanetBarcode@gs1.org
2.11.3 Wording of hyperlinks and references
When referring the reader to a reference or a hyperlink, introduce the reference or hyperlink number with see ‘section’ or ‘figure’.
■ Example:
□ For an explanation, see section 6.4.11 Message Layer
Use the word see when introducing a cross-reference or hyperlink within parentheses.
■ Example:
□ The Technical Terminology section includes a list of terms and how they should be punctuated (see section 2.2).
Note: For long documents, such as the GS1 General Specifications, the use of DocTools is strongly recommended to manage the automated cross-references. Typically the section number alone is sufficient for cross-references within a document as it should have sufficient context in the surrounding text enabling it to be verified.
Numbered lists are used for cases where the order of information is important, such as multiple-step procedures.
2.12.1 Rules for writing multiple-step procedures
Follow these rules when writing multiple-step procedures:
1. Use clear, present-tense, imperative verbs (for example, click, select, or modify) to tell readers what to do in a step.
2. Write short and to-the-point sentences. If the text is too confusing or too long, readers will not be able to follow the instructions properly.
3. Give readers only one instruction per step. However, you can combine up to three short instructions into one step if they occur in the same location.
4. Have no more than 12 steps in a procedure. If there are more, you must review the procedure and determine if it can be split into smaller standalone procedures.
2.12.2 Using commands in multiple-step procedures
Follow these rules when presenting commands in procedures:
■ Place commands on a separate line, no matter how short they are.
■ Preface flags/switches in commands with a hyphen (-).
■ Do not add a full stop after commands.
■ Indicate user-defined parameters (variables) in commands with angle brackets.
■ If there is one user-defined parameter, write the lowercase word where (without a colon) on a separate line, state the parameter and then provide a brief description (see the example below). If there is more than one, write the lowercase word where: (with a colon) on a separate line and then provide a bulleted list of the parameters and a brief description of each one.
Correct:
The NSS of all URNs assigned by GS1 have the following hierarchical structure, reflecting the basic context categories and major version number:
urn:gs1:[BP]:[IC]:[GP]:[Major Version]
where:
■ [BP] is the Business Process
■ [IC] is the Industry Classification
■ [GP] is the Geopolitical Context
Incorrect:
The NSS of all URNs assigned by GS1 have the following hierarchical structure, reflecting the basic context categories and major version number:
urn:gs1:[BP]:[IC]:[GP]:[Major Version]
Where BP is the Business Process, IC is the Industry Classification and GP is the Geopolitical Context
Do not use an abbreviation or symbol for a unit of measure in running text unless it is part of a calculation or an expressed relation between two or more measurements. Abbreviations or symbols for units of measure may be used in figures and tables.
Measurements should always be in metric with an imperial equivalent in brackets if required.
■ Examples:
□ Correct: The case is 50 mm x 60 mm in length.
□ Correct: X-dimensions below 0.635 mm (0.250 in) should not be used.
Always include a single space between the number and the abbreviation or symbol for the measurement.
■ Examples:
□ Correct: 6 g
□ Incorrect: 11 Fluid Ounce
2.13.1 Country codes
For running text, use the three-letter ISO 3166-1 alpha country code. For storage of country codes within a barcode symbol, refer to the GS1 General Specifications.
2.14.1 Number values
Always use numerals when describing specific numeric values.
■ Example:
□ Correct: The digit 1 is in the GS1 logo.
□ Incorrect: The digit one is used in the GS1 logo.
2.14.2 Data structure numbering
Always spell out numbers when describing positions inside a data structure.
■ Example:
□ The digit 2 is placed in position one of the GTIN-13.
2.14.3 Numbers under and above 10
Except in events governed by section 3.3, numbers under 10 should be spelled out; for numbers 10 and above, use numerals.
■ Examples:
□ The three-digit number is used in positions two through five.
□ The 10-digit number 0123456789 should appear three times.
2.14.4 Group of related numbers
Except in events governed by section 3.3, if any number in a group of related numbers is 10 or above, use numerals to express all the numbers.
■ Example:
□ A 14-digit number and 5-digit number follow the first and second AIs in the data structure respectively.
■ Example of Related GTINs:
□ GTIN-8, GTIN-12, GTIN-13 and GTIN-14
□ GTIN-12, GTIN-13 or GTIN-14
□ GTIN-12, GTIN-13 and GTIN-14
2.14.5 Numbers that begin a sentence
Spell out all numbers that begin a sentence and avoid writing sentences that begin with large numbers.
2.14.6 Specific number values
Use numerals for measurements, decimals, scores, votes, temperature and exact amounts of money, as well as for chapter, section and page references.
2.14.7 Unrelated numbers that appear side by side
Except in events governed by section 3.3 Issuing and dating technical documents, if two unrelated numbers appear side by side in a sentence, spell out the first number and use a numeral to represent the second number.
■ Example:
□ The reference number includes two 3-digit numbers. (However, use a numeral for the first number if it is long when spelled out and spell out the second number.)
2.14.8 Rounding numbers
Editors and technical writers should never round numbers provided by technical staff. See section 3.11 for a detailed explanation of rounding rules for technical staff.
2.14.9 Numbers used in currency
When a number that represents money is spelled out, use the word for the type of currency along with the number. For example, use the word “euro”, “dollars,” “yen,” or “pounds” with the number. When numerals are used for the amount, include the symbol for the currency type (such as “€” or “$”). If no cents are included in the numeral, omit the “.00”.
Use euro as standard currency if needed to compare amounts as it makes figures in documents comparable.
Guidelines:
□ If quoting other currencies, always put euro first and other currency in brackets
□ If using full word keep lowercase (euro not Euro) and remember plural is euro (not euros)
□ If using “€” put before figures (not after)
■ Examples
□ Correct: Data synchronisation saves the industry 15 million euro per year
□ Correct: Data synchronisation saves the industry €15 million ($19 million)
□ Correct: The catalogue is GBR £9.95
□ Incorrect: Data synchronisation saves the industry 15 million euros per year
□ Incorrect: Data synchronisation saves the industry 15 million € per year
□ Incorrect: Data synchronisation saves the industry 15 million EUR per year
2.14.10 Numbers used to represent time
When using a 12-hour clock, use numerals for the time if including a.m. and p.m.
■ Examples:
□ 1 p.m.
□ 1 a.m.
When using a 24-hour clock, include the colon between hours and minutes.
■ Example:
□ 07:00
To help readers understand new terminology during a migration period, it is permissible to include the prior term in parentheses following the new term.
■ Examples:
□ Quiet Zone (Light Margin)
When the term "U.P.C." is used alone, it must appear with the full stops in any written form, whether it is a presentation, a letter or a publication.
If the term "UPC" is used, we are infringing upon the certification mark of the International Association of Plumbing and Mechanical Officials (IAPMO). IAPMO allows the use of the term "U.P.C." and requires in publications a footnote to define the difference.
When the letters “UPC” are used in conjunction with other characters, then the full stops are not required
■ Examples:
□ EAN/UPC symbology
□ UPC-A barcode
Many GS1 standards and guidelines need to demonstrate examples referring to companies.
Note: Images or text showing real world companies should be avoided. If used, the explicit consent of the company or organisation in question must be obtained.
The general guidance for fake companies used in examples is:
■ Avoid made-up examples that might exist (e.g., Buckley’s Beer)
■ Make consistent use of examples within the document (e.g., Retailer A, Manufacturer B, Logistic Provider C, etc.)
Examples of GS1 identification keys are required in standards, training, marketing material, etc. To avoid confusion with ‘real’ GS1 identification keys, this “dummy” GS1 prefix has been issued for use by anyone who needs to use examples of GS1 identification keys in documents, working sessions, demonstrations, or presentations.
GS1 prefix 952 is made available for demos and examples of GS1 identification keys. It is available to everyone: GS1 Global Office, Member Organisations, User companies, Solution Providers, etc.
GS1 prefix 952 is an official GS1 prefix specifically allocated to demonstrations, examples, tests or any other usage. In no case shall this prefix be used to identify items in the “real world”, even for internal applications within an organisation or by mutual agreement between different organisations.
The use of GS1 prefix 952 will not be subject to any central or decentralised governance. The usage is determined by the owner of the material where the prefix is used, be it a software application, a standard document, an e-learning asset, a marketing presentation or anything else. The owner of the artefact making use of GS1 prefix 952 is encouraged to use it consistently in the context of this artefact.
There is no need to change existing material making use of examples built on random numbers or genuine GS1 prefixes. When an update of existing material is planned, it is recommended to consider using systematically GS1 prefix 952 for the GS1 identification key examples. We expect that GS1 prefix 952 will be deployed progressively for demos and examples.
2.18.1 UPC prefix based example
When a UPC based example is required, GS1 US have made available the following, suppressible, GTIN-12: 012345000058
2.18.2 Barcode image examples which can be freely re-used
UPC-E example
UPC-A example
EAN-8 example
EAN-13 example
ITF-14 example
GS1 DataMatrix example -- GTIN & serial number
Depicted as an SGTIN URI, for use in EPCIS event data:
urn:epc:id:sgtin:9521234.054321.4X7Y1Z1
2.18.3 Convention for use in EPC URIs
Because of the special role of the length of the GS1 Company Prefix within EPC URIs, the following convention is proposed:
■ This convention is intended to ensure consistency across example values of the Company Prefix component within an EPC URI context, even when different authors prepare those examples independently.
■ This convention has been expressed within the GCP length lookup tables linked from https://www.gs1.org/standards/bc-epc-interop so that it can be used consistently within software concerned with translating from element strings or GS1 Digital Link URI to EPC URI format.
2.18.4 Convention for examples linking to the GS1 Registry Platform using prefix 950
As stated above, the use of GS1 prefix 952 is preferred for all example barcodes. However, GS1 Prefix 950 is used to construct identifiers that are uniquely assigned for demonstration purposes when there is a need to consistently and globally refer to a specific thing and its associated data. The GS1 identification keys assigned from prefix 950 are subject to all the rules pertaining to the GS1 identification key used (e.g., non-duplication, non-reuse, etc.).
GS1 QR Code example – resolving to the, demonstration, Dal Giardino brand
When using MS Word documents, it is tempting to use manual page breaks or worse, multiple carriage-returns, to improve the layout of the document. This should be avoided as:
■ It only improves the look in MS Word and PDF (not other formats)
■ Such formatting makes future versions, and editing, problematic
■ It is not best practice within MS Word
A more appropriate technique\ is the ‘Keep with next’ option:
GS1 works with, and leverages content, from many other external organisations. For example, the International Standards Organization (ISO), the World Health Organization (WHO), the United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport (UN/EDIFACT), etc. When quoting from, or referencing, such sources the citation should be verbatim (e.g., do not correct for UK English or change in any other way).
■ Example:
□ Correct: Please leverage the W3C color decimal codes
□ Incorrect: Please leverage the W3C colour decimal codes.
With the move to 2D in retail, greater clarity on the use of these two terms is required. Moving forward, the guidance is:
For marketing use and broad communication
■ Use mainly Next generation barcode in broad communication related to Ambition 2027 in retail and mention the most common type of 2D barcodes (QR Codes Powered by GS1 and GS1 DataMatrix) depending on the main benefit or use case, e.g., QR Codes powered by GS1 for consumer/shopper engagement, GS1 DataMatrix or both for operational efficiencies, etc.
■ Specify retail context when using QR Codes powered by GS1, e.g., QR Codes powered by GS1 in retail, QR Codes powered by GS1 on grocery products, QR Codes powered by GS1 at point of sale.
■ Use GS1 DataMatrix for healthcare communication, the recommended 2D barcode for healthcare.
■ Use precise terminology: 2D barcodes with GS1 standards, GS1 DataMatrix, Data Matrix, QR Code with GS1 Digital Link, etc.
For technical documents
□ When a more generic term is required, “Linear barcode” and “2D barcode” MAY be used.
■ The term “symbol” is generally restricted to either referring to an image or a characteristic of a barcode or family of barcodes (e.g., The GS1 symbol specification table 5):
□ The term “barcode symbol” can be confusing and SHOULD NOT be used.
■ If the grouping of 2D barcodes approved for use within the GS1 system needs to be described, the term “GS1 compliant 2D barcodes” SHOULD be used.
□ If a sector or application specific grouping of 2D barcodes needs to be described, for example retail POS, the term “GS1 compliant POS 2D barcodes” MAY be used.
For all GS1 documents
■ The terms GS1 barcodes, GS1 2D barcodes, and GS1 2D symbols are misleading and SHOULD NOT be used:
□ When a more generic term is required, GS1 compliant barcodes MAY be used.
3 Specifics for GS1 technical documentation
3.1 Fonts and styles defined by the templates
3.2 Document and trademark disclaimer
3.3 Issuing and dating technical documents
3.4 Conformance language in GS1 standards
3.5 Section title numbering rules
3.6 Using notes
3.7 Migration rules for ancillary document names
3.8 Open issue text
3.9 Data structure positioning rules
3.10 Appendix rules
3.11 Rounding rules for barcode measurements
3.12 Business process modelling methodology
3.13 Listing contributors
3.14 Change log
3.15 Maintaining www.gs1.org/glossary
3.16 Referenced sources
The fonts and styles of all GS1 technical documentation are automated by using the appropriate GS1 template.
Include the following disclaimer statement at the beginning of a GS1 document, prior to the Table of Contents of all GS1 standards and guidelines. This disclaimer eliminates the need to include and update registered trademarks in the document:
GS1 seeks to minimise barriers to the adoption of its standards and guidelines by making the intellectual property required to implement them available, to the greatest extent possible, on a royalty-free basis, or when necessary, under a RAND licence. Such royalty-free and RAND licences are provided pursuant to the GS1 IP Policy (available here: https://www.gs1.org/standards/ip ), which governs the work of work group participants who contribute to drafting standards and guidelines, including this document. In addition to licences, the GS1 IP Policy provides various benefits and obligations that apply to all implementers of GS1 standards and guidelines, and all implementations of GS1 standards are subject to those terms.
Nevertheless, please note the possibility that an implementation of one or more features of this standard or guideline may be the subject of a patent or other intellectual property right that is not covered by the licences granted pursuant to the IP Policy. In addition, the licences granted under the IP Policy do not include the IP rights or claims of third parties who were not participants in the corresponding standard development work group.
Accordingly, GS1 recommends that any person or organisation developing an implementation of this standard or guideline should determine whether any patents or other intellectual property may encompass such implementation, and whether a licence under a patent or other IP right is needed. The implementer should determine the potential need for licensing in view of the details of the specific implementation being designed in consultation with that party's patent counsel.
THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR PARTICULAR PURPOSE, ACCURACY OR COMPLETENESS, OR ANY WARRANTY OTHERWISE ARISING OUT OF THIS DOCUMENT. GS1 disclaims all liability for any damages arising from any use or misuse of this document, whether special, indirect, consequential, or compensatory damages, and including liability for infringement of any intellectual property rights, relating to use of information in or reliance upon this document.
GS1 makes no commitment to update the information contained herein, and retains the right to make changes to this document at any time, without notice. GS1® and the GS1 logo are registered trademarks of GS1 AISBL .
Note: The first three paragraphs are eliminated for GS1 documents, such as this GS1 Style Guide, which are not developed under IP.
All GS1’s technical documents have a release number and this will appear on the title page. The release number has the structure N.N or N.N.N and the guidance for usage is.
■ The first number indicates a MAJOR release. 1 is the first release, while 2 indicates a new release that is incompatible with release 1.
■ The second digit is used for a MINOR release. This indicates backward-compatible additions or small changes to the wording or structure
■ The ERRATA field is left blank for the first Major or Minor release but is mandatory for any subsequent change to a published standard that does not necessitate a more significate release number change and is typically for releases and bug fixes. This is optional for guidelines
Only major and minor releases are usually significant to the users with errata release being used for changes that do not materially affect the standard or those who have implemented the standard.
The first release of a document will typically be release 1.0 and the digits for major and minor changes shall increase incrementally as required. The Microsoft Writing Style Guide, can be referenced for further guidance for changing release numbers.
For a draft document, the filename includes the "to be" release number, plus a draft number and a date. It is essential that all draft documents are clearly marked Draft, and ratified standard and guidelines are clearly marked Ratified, on the cover page and in the document footers. Other document statuses, for example ‘Community Review Draft’, should appear when required.
Example of file names during drafting:
■ EPC-Tag-Data-Standard-v1.13-r-2022-02-17.docx
■ Leveraging GDSN for the FDA Global Unique Device Identifier Database Release1.3.1-d2-2023-02-27.docx
Example of file names when posted as ratified standard or guideline:
■ TDS-113-Standard.pdf
■ GS1-GDSN-GUDID-Implementation-Guideline.pdf
Published documents should be dated with the month and year of ratification. Do not add the day unless absolutely necessary. The month name should always be abbreviated and appear on the document’s title page using the date format: MMM YYYY (e.g., Aug 2024)
Note: using the GS1_Advanced Word Template (see 3.1) and the GS1 Document Properties will help ensure compliance.
3.3.1 File naming conventions
This section describes the naming conventions for files. Files types can include:
■ DOC – MS Word
■ PDF – Adobe Portable Document Format
■ ZIP – Series of compressed files
File names should not contain white spaces.
During development the following naming convention should be used for all GS1 standards & guideline documents:
<<Document-Name>-<Type>- <To Be Release> -<Status>-<yyyy>-<mm>-<dd>
Where:
Once ratified, most GS1 standards and guidelines are published as pdf files. The date appearing on the cover is the date of ratification (month and year).
The concept of “conformance” is central to GS1 standards. A GS1 standard exists to define certain characteristics of an implementation created by an end user or solution provider. An implementation is said to conform to a GS1 standard if it satisfies the conformance conditions laid out in the text of the standard. The standard is written such that when multiple implementations are in conformance to the standard, those implementations are capable of interoperating in the way envisioned by the authors of the standard. Conformance is the soul of what a GS1 standard is intended to convey. It is therefore essential that a GS1 standard be clear and unambiguous in what it says about conformance.
The text of GS1 standards should be drafted to address the following aspect of conformance:
■ The standard should clearly identify what types of implementation artefacts are subject to conformance to the standard. In other words, what are the things that can be judged as in conformance or not in conformance to the standard?
■ If there are different ways to comply with the standard, the standard should clearly identify each conformance level or conformance option, ideally giving each a name that can be used in conformance testing reports to precisely indicate to what levels or options a given implementation conforms.
■ Normative statements in the body of the standard should use the verbal forms SHALL, SHOULD and MAY as defined in the ISO Directives. Moreover, such statements should be worded so that it is clear how it applies to an implementation. Generally, this means the subject of these verbal forms should be “a conforming implementation” or a similar phrase.
Each of these points is explained and illustrated in detail in the sections that follow.
3.4.1 Identifying what may conform
A GS1 standard should identify what types of things are subject to conformance to the standard. For a data standard, a conforming implementation might be a specific piece of data or an electronic document. For a barcode print quality standard, a conforming implementation might be a specific printed barcode. For a messaging standard, a conforming implementation might be the sender or receiver of a message, or the message content itself. For a software interface standard, a conforming implementation might be a software implementation on one side of the interface or the other.
Many standards define conformance requirements for different implementation artefacts which interact according to the standard. In such cases, there are several types of implementations that conform to the standard, each conforming to different statements within the standard. For example, the Gen2 Air Interface Standard defines interactions between an RFID reader and an RFID tag. So there are two types of conforming artefacts, readers and tags and the standard includes some statements that define what it means for a reader to conform and other statements that define what it means for a tag to conform. Each normative statement in the standard should clearly indicate to which type of conforming artefact the statement applies (see section 3.4.3). The text of the standard that defines the conforming artefacts should be clearly identified and easily found in the standard document. A good way to do this is to have a section titled “Conformance.”
Here are some examples of well-written statements of what artefacts conform to a standard.
From the GS1 Core Business Vocabulary (CBV) 2.0 standard:
A “CBV-Compliant Document” is a document that conforms to the schema and other constraints specified in [EPCIS2.0], and which furthermore conforms to all the normative language in this standard that pertains to a “CBV-Compliant Document.”
The CBV standard is a data standard, so it defines a document as an artefact that may be in conformance to the standard. Note that it also identifies conformance to another standard (EPCIS) as a condition for conformance to CBV, in addition to the statements contained in CBV itself.
The CBV standard also defines applications as another type of artefact that may conform:
A “CBV-Compliant Application” is any application for which both of the following are true:
• If it operates in a mode where it claims to accept a CBV-Compliant Document as an input, the application SHALL accept any document that is a CBV-Compliant Document according to this standard and furthermore in processing that input SHALL interpret each CBV identifier according to the meaning specified herein.
• If it operates in a mode where it claims to produce a CBV-Compliant Document as an output, the application SHALL only produce a document that is a CBV-Compliant Document according to this standard and furthermore in generating that output SHALL only use CBV identifiers to denote their meaning as specified herein.
The Gen2 Air Interface Standard defines RFID Readers (called “Interrogators”) and RFID Tags as two types of artefacts that may conform. (
2.2.1 Interrogators
To conform to this protocol, an Interrogator shall:
• Meet the requirements of the Gen2 Air Interface Standard,
• Implement the mandatory commands defined in the Gen2 Air Interface Standard,
• Modulate/transmit and receive/demodulate a sufficient set of the electrical signals defined in the signalling layer of the Gen2 Air Interface Standard to communicate with conformant Tags, and
• Conform to all local radio regulations.
To conform to the Gen2 Air Interface Standard, an Interrogator may:
• Implement any subset of the optional commands defined in the Gen2 Air Interface Standard, and
• Implement any proprietary and/or custom commands in conformance with the Gen2 Air Interface Standard.
To conform to the Gen2 Air Interface Standard , an Interrogator shall not:
• Implement any command that conflicts with the Gen2 Air Interface Standard, or
• Require using an optional, proprietary, or custom command to meet the requirements of the Gen2 Air Interface Standard.
2.2.2 Tags
To conform to the Gen2 Air Interface Standard , a Tag shall:
• Meet the requirements of the Gen2 Air Interface Standard,
• Implement the mandatory commands defined in the Gen2 Air Interface Standard,
• Modulate a backscatter signal only after receiving the requisite command from an Interrogator, and
• Conform to all local radio regulations.
To conform to the Gen2 Air Interface Standard, a Tag may:
• Implement any subset of the optional commands defined in the Gen2 Air Interface Standard, and
• Implement any proprietary and/or custom commands as defined in 2.3.3 and 2.3.4, respectively.
To conform to the Gen2 Air Interface Standard, a Tag shall not:
• Implement any command that conflicts with the Gen2 Air Interface Standard,
• Require using an optional, proprietary, or custom command to meet the requirements of the Gen2 Air Interface Standard, or
• Modulate a backscatter signal unless commanded to do so by an Interrogator using the signalling layer defined in the Gen2 Air Interface Standard.
3.4.2 Conformance levels and options
Many standards, especially technical standards, are not monolithic, but instead define different modules of features that can be used for different applications. In this case, there may be implementation artefacts that do not conform to the entire standard, but which conform to selected parts of the standard. Of course, an implementation cannot pick and choose which parts it conforms to: the standard itself must define specific groups of features or options which must each be implemented in their entirety to claim conformance. When this is the case, a standard must clearly specify what are the available conformance levels and options, and what are the conformance requirements for each.
For example, the GS1 Application Level Events (ALE) 1.1 standard defines five different Application Programming Interfaces (APIs). A given implementation of ALE may implement a subset of these APIs, but each API it implements must be implemented in its entirety to claim conformance.
Another example, the GS1 EPC Information Services (EPCIS) 1.0.1 standard defines a software messaging interface to which an implementation may conform. A large number of normative statements pertain to all implementations that conform to this interface. But the EPCIS standard offers a choice of message transport, based on HTTP or AS2. A conforming implementation may implement one or both of these message transports. These constitute conformance options.
Another example, the Gen2 Air Interface Standard defines a base level of functionality that all tags and readers must implement. Many features are optional in this base level of conformance. Annex N defines additional conformance levels; to qualify for any of these conformance levels a tag or reader must conform to specified normative statements that are otherwise optional in the base conformance level. A tag or reader may be tested to be in conformance to the base level, or may additionally be tested to be in conformance to one of the higher levels.
All conformance levels should be identified clearly, and it should be absolutely apparent which normative statements apply to which level. Ideally, each level should be given a name, so that it is easy to refer to it in a conformance testing report for any particular implementation.
3.4.3 Wording of normative statements
At the heart of a GS1 standard are normative statements. A normative statement is a statement that defines the behaviour or otherwise places a constraint upon a conforming implementation. Collectively, the normative statements are what gives a standard force.
In GS1 standards, normative statements are written using the verbal forms described in section 7 of the ISO/IEC Directives, Part 2, 2021, 9th edition [ISODir2]. These include the words SHALL, SHALL NOT, SHOULD, SHOULD NOT and MAY. When these words are written in a normative statement, using the special meanings defined in [ISODir2], they are written in all capitals to distinguish them from ordinary English use of the same words.
For a precise definition of these verbal forms, see [ISODir2]. Briefly, their meanings are summarised as follows:
■ SHALL means that all conforming implementations must do what the statement says, otherwise the implementation is not conforming. No deviation is permitted.
■ SHOULD means that among several possibilities one is recommended as particularly suitable for a conforming implementation, without mentioning or excluding others. In other words, a conforming implementation is expected to do what the statement says, but might not if there is a good reason not to. It is similar to a MAY statement, but carries a stronger expectation that an implementation will usually do what the statement says.
■ MAY means that a conformation implementation is allowed to do what the statement says, but it is not required to for conformance.
The most precise way to write a normative statement is to name a type of conforming artefact as the subject and one of the special words above as the verb; e.g., “A conforming implementation of this standard SHALL do …” This makes it very clear to what artefact a given normative statement applies, and offers a precise way to assess whether the artefact is in conformance or not.
It is less effective to make some concept internal to the standard be the subject of the verb. For example, imagine a hypothetical standard that defines an interface between an RFID Reader and an RFID Tag, in which there is a Read command defined. The following sentence does not follow the above guideline:
The address field of a Read command SHALL be less than 400.
Here, the subject of the verb is “a Read command”. It is not clear whether this conformance statement applies to a conforming RFID Reader, a conforming RFID Tag, or both. It is also not clear what happens if this statement is violated. The following wording is much clearer because it makes the conforming implementation the subject of the verb:
A conforming RFID Reader SHALL NOT issue a Read command whose address field is greater than or equal to 400. A conforming RFID Tag SHALL process a Read command whose address field is less than 400, and SHALL reject with error code 62 a Read command whose address field is greater than or equal to 400.
Repetition of this style of sentence can become very tedious. Tables are a good way to avoid repetition, and with the appropriate introductory sentence can be just as precise:
All commands issued by a conforming RFID reader SHALL be as specified in the following table:
[table goes here]
A SHOULD or MAY statement indicates something that is optional; an implementation does not have to do what the sentence says in order to be in conformance. Quite often, there are optional features of a standard such that an implementation does not have to implement the feature, but if it does it has to do it a certain way to achieve interoperability. The correct way to write this in normative language is in a style similar to the following:
A conforming implementation MAY implement the XXXX feature. If a conforming implementation implements the XXXX feature, it SHALL do YYYY.
This makes it very clear what is expected of an implementation if it implements the optional feature.
Follow this numbering convention when labelling document sections:
■ 2 Highest level – use for major section headers
■ 2.1 Subsection (subhead) of the preceding section (2)
■ 2.1.1 Subsection (subhead) of the preceding section (2.1)
■ 2.1.1.1 Subsection (subhead) of the preceding section (2.1.1)
-- and so on.
Notes draw the readers’ attention to information of special importance or information that does not belong in the body text. There are two types of note icons available:
Note:
Important:
3.6.1 Using regular notes
Notes add supplemental but tangential information or emphasise a point within the text. They are not essential to the basic understanding of text. A note can also be used to provide information that applies only in certain cases.
3.6.2 Using “Important” notes
Important notes draw readers’ attention to information that is crucial to the current topic. The major difference between a regular note and an important note is that, while a note provides ancillary information, an important note provides readers with significant content to which they must pay attention. In other words, if readers cannot carry out a procedure or understand a concept without it, it must be presented as an important note; if they can, it is a regular note.
When a “dead” term (a term that has been retired and replaced) is used in the proper title of an existing document or web page, the term in the title should not be revised until the new term is officially recognised by GS1 and the document or website is revised and/or reprinted in a subsequent edition.
“Open Issues” indicate blocks of text that are placeholders for work in progress. This style is only to be used on “work-in-progress” documents and it shall not be used in published, ratified, documents.
Ø This is an example of an open issue. Basically using this distinctive bullet symbol.
3.9.1 Data structure labelling
When labelling a data structure, the numbered positions in the structure should be labelled incrementally from left to right. The leftmost position should be “position one” and positions to its right should increase by increments of one.
3.10.1 Placement
Because readers expect appendices to be at the back of a document, appendices should appear following the last section. However, in unusual circumstances, an appendix may directly follow a section or subsection if what the appendix includes is essential to the understanding of the material contained in the section or subsection.
3.10.2 Appendix numbering
Appendices should be sequentially numbered, using the convention A, B, C, …. The numbering rules in section 3.5 also apply to the appendices with the only difference being the appendix letter takes the place of the top level section number.
■ Examples:
□ Appendix A 1.2 = A.1.2
□ Appendix C 62.1.1 = C.62.1.1
To ensure a consistent set of metric and inch-based dimension equivalents, a consistent precision (significant digits), method of conversion (inches to millimetres and millimetres to inches), and method of rounding has been established.
Note: The following rules are for use by GS1 technical staff only. Writers and editors should never round numbers provided by technical staff.
3.11.1 Precision rule for X-dimensions (modules)
Because many barcode symbol widths are defined by a multiple of X-dimensions (modules), the X-dimension is to be rounded to the third decimal place (N.NNN) for X-dimensions stated in millimetres and to the fourth decimal place (N.NNNN) for X-dimension equivalents in inches.
3.11.2 Precision rule for symbol widths and heights
The overall widths (horizontal), heights (vertical) and other dimensions for barcode symbols are to be rounded to the second decimal place (N.NN) for dimensions stated in millimetres and to the third decimal place (N.NNN) for the dimension equivalents in inches.
3.11.3 Rounding rule
If the calculation of an equivalent dimension results in a value that is more digits than the precision required, and the digit following the digit to be rounded is a 5 or greater, the value is to be rounded up to the next higher value. If the digit following the digit to be rounded is less than 5, the digit to be rounded remains the same.
3.11.4 Conversion rule for inches to millimetres
The metric equivalent of the GS1 barcode inch dimensions are to be calculated using the dimensions multiplied by 25.4.
■ Example:
□ The nominal X-dimension is 0.0130 in. x 25.4 = 0.330 mm and the total width of the barcode, including Quiet Zones, is 0.330 mm x 113 = 37.29 mm.
3.11.5 Conversion rule for millimetres to inches
The inch equivalent of the GS1 barcode metric dimensions are to be calculated using the dimensions divided by 25.4.
■ Example:
□ The overall width would be 26.73 mm / 25.4 = 1.052 inch.
□ The overall height would be 21.31 mm / 25.4 = .839 inch.
Note: Within GS1 standards & guidelines, decimal placement are indicated with a full stop.
There are additional rules specific to developing Business Process Modelling documents such as the Business Message Standard (BMS). For a complete guide to these rules, see the GS1 Modelling Methodology manual.
The GSMP manual includes the requirement that each standard or guideline include a list of the individuals who contributed to the creation of the document. This list should appear after the title page and the full criteria for including contributors can be found in the GSMP manual.
Each standard and guideline should include a ‘Log of changes’ after the title page. This should contain a very concise summary made since the previous release. It is important to distinguish:
Log of changes during drafting:
■ This can include detailed editing notes
Log of changes between published versions:
■ Detailed editing notes should be deleted and replaced with a concise summary of approved changes since the last release.
All GS1 standards and guidelines shall use the definitions found in www.gs1.org/glossary and have the following statement proceeding any glossary:
Please refer to the www.gs1.org/glossary for the latest version.
Prior to final vote of any standards or guidelines, any glossary terms that contain additions or changes to the www.gs1.org/glossary must be formally evaluated against the existing glossary. If any divergence is identified, it must be clearly be identified and communicated to the group by the Standard Development Lead:
■ If the submitting group determines that the definition of an existing term needs to be adjusted, any other affected groups must be notified at latest prior to the community review to ensure that the definition changes are clear, and do not have a negative impact.
■ The changes will be discussed in the requesting working group with invitation given to the members all affected groups to ensure that consensus is reached. If consensus cannot be reached guidance will be requested from the GS1 Architecture Group.
It should be noted that www.gs1.org/glossary is not published with a version number; rather it will always show the most recent snapshot of terms and definitions along with the source of each term included.
3.15.1 Best practice for developing a GS1 glossary definition
Note: GS1 glossary terms are provided as a URL. Therefore URL unfriendly characters, like forward slash “/”, should be avoided in GS1 glossary terms.
Important: A GS1 glossary definition is only required when the term defined pertains to a GS1 specific concept used within a specific document. The GS1 glossary shall NOT contain common terms the meaning of which can be found in a dictionary.
GS1 standards and guidelines, particularly those of a technical nature, SHOULD include a citation reference to all external, non-GS1, source material used in the development.
Hyperlinks to the references SHOULD appear in the place in the document where they are cited. For example, the following text may appear in the introduction of a given GS1 standard or guideline:
Introduction
This GS1 standard should be read in conjunction with ISO/IEC 18004:2015, Information technology, Automatic identification and data capture techniques, QR Code bar code symbology specification as well as the GS1 General Specifications.
All such references SHOULD also appear as the last section of the GS1 standard or guideline with the suggested layout and wording below. Hyperlinks to online referenced sources should be used wherever possible. In line with section 2.11.2 links to www.gs1.org should default to open in the same browser window, links to non-GS1 websites should default to open in a new browser window.
Intuitive abbreviations or acronyms SHOULD be used for referenced documents. The abbreviation or acronym can be used in the main text with the full details appearing in the reference section. Abbreviation or acronym used should be consistent between all GS1 standards and guidelines and created using the following recommendations:
1. If an abbreviation or acronym exists in this style guide, see below, or an existing GS1 standard or guideline, use that.
2. Abbreviations used for referenced documents should be as short possible.
3. Abbreviations should avoid punctuation characters (e.g., period[.], hypen [-], space [ ], etc.) apart from when they appear in the name itself (e.g., ISO/IEC includes a forward slash [/]).
4. Abbreviations for documentation external to GS1 should start with the source organisation. Examples include:
□ ISO/IEC 15418 would appear as [ISO/IEC15418] and NOT [ISO 15418] or [15418]
□ European Union Regulation 2023/1234 would appear as [EU2023/1234]
5. Abbreviation for GS1 documents do not need to include the name “GS1” (e.g., the GS1 General Specifications appear as [GenSpecs] and NOT [GS1GenSpecs].
6. Abbreviations should use a leading capital (e.g., Arch for Architecture, WebVoc for Web Vocabulary).
7. Acronyms should be all CAPS (e.g., TDS for Tag Data Standard).
8. Abbreviations should be as intuitive to the (expert) audience as possible.
9. If hesitating between two abbreviations, try googling them both and seeing which one gives the most correct hits.
External references
Example of commonly referenced external documents with abbreviation and layout
GS1 references
Note: Including references to GS1 documentation in the “References” section is optional.
List of commonly referenced GS1 documents with recommended abbreviation and layout
4 User interfaces for GS1 services & solutions
4.1 Writing user-interface messaging
User Experience (UX) text appears throughout the user interface of online GS1 services and solutions. The UX sentences or text you write should have:
■ Scannable: Readability of the sentence on first glance
■ Front-loaded: The point is conveyed at the start of the sentence
■ Low Cognitive load: The reader does not use much of working memory
□ Examples:
- Correct: Describes differentiating characteristics in terms of flavour, fragrance or taste of the same brand and size. For example, `still´ or `sparkling´ for drinks.
- Incorrect: Covers the distinguishing characteristics that differentiate products with the same brand and size including such things as the flavour, fragrance or taste. ‘Still or sparkling’ is a specific example for drinks.
Example of a user interface for Activate
4.1.1 Screen element names and usage
All User interface element names must be formatted in bold, especially in procedural steps.
■ From the Order type drop-down, select Online.
■ From the Orders page, click Confirm.
■ From the Packaged orders page, select the Gift wrap checkbox, and then click Ok.
5 GS1 content author checklist
An essential part of GS1’s publications process is quality assurance. This checklist aims to assist content creators in performing a quality review before submitting final drafts. Good documentation reduces rework, ensuring the consistency demanded by GS1 stakeholders.
Presentation: checks page layout is consistent with this GS1 Style Guide & GS1 Marketing Guide
Table of Contents: check sections of the document with entries formatted properly.
Content: checks spelling, grammar, and consistent use of language and sentence structure.
Consistency: examines cross-references, image quality, internal references and hyperlinks.
Contributors & change log
Contributors
Log of Changes
Useful links:
* The PDF version of this GS1 Style Guide
* For GS1 Member Organisations, the Technical Documentation Toolkit on MO Zone