Legacy standard
You are viewing a standard that has since been updated. View the current standard.
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. Two important references for ensuring consistency to the new branding and this style guide are:
■ GS1 standards glossary of terms: www.gs1.org/glossary
■ Economist Style Guide: https://shop.economist.com/products/the-economist-style-guide-12th-edition
2 Applicable to all GS1 documentation
2.1 British English 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 Inserting 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.
Use British English spelling for all documents.
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.
Note: When using Microsoft, set the language to English (U.K.).
Table 2‑1 Examples of spelling conversions
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 (but E-commerce if starting a sentence)
■ email is one word and does not include a hyphen
■ e-tailer
■ 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 texts more difficult to read; use of lowercase gives us a more relaxed and approachable tone of voice, including headings
■ 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.
■ Rationale: Minimal use of capitals makes texts 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 a prefix:
■ GS1 Application Identifiers
■ GS1 Company Prefix
■ GS1 Data Quality
■ GS1 Data Quality Framework (DQF)
■ GS1 DataBar
■ GS1 EANCOM
■ GS1 EDI
■ GS1 EPCglobal
■ GS1 General Specifications
■ GS1 Global Data Model
■ GS1 GLN Registry
■ GS1 GLN Service
■ GS1 Global Data Dictionary (GDD)
■ GS1 Global Data Synchronisation Network (GDSN)
■ GS1 Global Electronic Party Information Registry (GEPIR)
■ GS1 Global Registry
■ GS1 Global Standards Management Process (GSMP)
■ GS1 Logistics Interoperability Model (LIM)
■ GS1 Prefix
■ 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.
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.12.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: 1-12-24, 12-1-24, Dec-1-24
Note: See section 2.12.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 symbol
□ 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 use “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”
Do not use a comma before “and” or in a series.
■ Examples
□ Correct: The new standard enables efficiency, sustainability and safety.
□ Incorrect: The new standard enables efficiency, sustainability, and safety.
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) with the GS1 Common Currency Coupon Code.
Figures
Figures enhance a document’s readability by illustrating key points, better communicating ideas and helping readers navigate through sometimes confusing interfaces.
Prior to 2020, this GS1 Style Guide recommended all figures to include a numbered titled cantered above the figure. However, the recommendation since May 2020 is for all new documents to:
■ Avoid using figure titles and numbering at all, if the figure is positioned in such a way and explained by the text, that a title would be superfluous
■ Position the figure number and title below the image, preferable with both image and title being centred
Figure 2-1 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.
Figure 2‑1 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
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.1 File types for print
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.2 File types for digital
SVG, 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.2.1 HTML
Increasingly GS1 standards and guidelines, as well as other GS1 publications, are being published as webpages (e.g., using HTML). 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.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.
subsection]. [title]
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. They do not work 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 are point to items that appear in another location within a document or website. They can also be references to external documents or websites.
When adding cross-references you could, of course, type them 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 all of your cross-references. To avoid this, all cross-references should be inserted as fields. This way, Word can update them automatically as needed.
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.
■ 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-3, 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 documents, links to the www.gs1.org website should as 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 documents location on 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 millimetre (0.250 inch) 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: 11Fluid 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.; spell out numbers if using “o’clock.”
■ Examples:
□ 1 p.m.
□ one o’clock
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
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
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®, under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in the Work Group that developed this Document title, document type to agree to grant to GS1 members a royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. Furthermore, attention is drawn to the possibility that an implementation of one or more features of this Specification may be the subject of a patent or other intellectual property right that does not involve a Necessary Claim. Any such patent or other intellectual property right is not subject to the licensing obligations of GS1. Moreover, the agreement to grant licences provided under the GS1 IP Policy does not include IP rights and any claims of third parties who were not participants in the Work Group.
Accordingly, GS1 recommends that any organisation developing an implementation designed to be in conformance with this Specification should determine whether there are any patents that may encompass a specific implementation that the organisation is developing in compliance with the Specification and whether a licence under a patent or other intellectual property right is needed. Such a determination of a need for licensing should be made in view of the details of the specific system designed by the organisation in consultation with their own patent counsel.
THIS DOCUMENT IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR PARTICULAR PURPOSE, OR ANY WARRANTY OTHER WISE ARISING OUT OF THIS SPECIFICATION. GS1 disclaims all liability for any damages arising from 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 retains the right to make changes to this document at any time, without notice. GS1 makes no warranty for the use of this document and assumes no responsibility for any errors which may appear in the document, nor does it make a commitment to update the information contained herein.
GS1 and the GS1 logo are registered trademarks of GS1 AISBL
Note: The first two 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 Manual of Style 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.12_r_2019-02-17.docx
■ Leveraging GDSN for the FDA Global Unique Device Identifier Database_Release1.3.1_d2_2015-02-27.docx
Example of file names when posted as ratified standard or guideline:
■ TDS_1_12_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 2019)
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 – Microsoft 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) 1.0 standard:
A “CBV-Compliant Document” is a document that conforms to the schema and other constraints specified in [EPCIS1.0.1], 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. (In the example below, the word “protocol” refers to the Gen2 Air Interface Standard itself.)
2.2.1 Interrogators
To conform to this protocol, an Interrogator shall:
• Meet the requirements of this protocol,
• Implement the mandatory commands defined in this protocol,
• Modulate/transmit and receive/demodulate a sufficient set of the electrical signals defined in the signalling layer of this protocol to communicate with conformant Tags, and
• Conform to all local radio regulations.
To conform to this protocol, an Interrogator may:
• Implement any subset of the optional commands defined in this protocol, and
• Implement any proprietary and/or custom commands in conformance with this protocol.
To conform to this protocol, an Interrogator shall not:
• Implement any command that conflicts with this protocol, or
• Require using an optional, proprietary, or custom command to meet the requirements of this protocol.
2.2.2 Tags
To conform to this protocol, a Tag shall:
• Meet the requirements of this protocol,
• Implement the mandatory commands defined in this protocol,
• Modulate a backscatter signal only after receiving the requisite command from an Interrogator, and
• Conform to all local radio regulations.
To conform to this protocol, a Tag may:
• Implement any subset of the optional commands defined in this protocol, and
• Implement any proprietary and/or custom commands as defined in 2.3.3 and 2.3.4, respectively.
To conform to this protocol, a Tag shall not:
• Implement any command that conflicts with this protocol,
• Require using an optional, proprietary, or custom command to meet the requirements of this protocol, or
• Modulate a backscatter signal unless commanded to do so by an Interrogator using the signalling layer defined in this protocol.
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, 2016, 7th edition [ISODir2]. These include the words SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, NEED NOT, CAN and CANNOT. 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 (or CAN) 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.
To draw the reader’s attention to Non-Normative text, use the following note format:
Non-Normative: Draws the readers’ attention to Non-Normative text.
“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/25.4 = .839 inch.
Note: Within GS1 standards & guidelines, decimal placement are indicated with a full stop.
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
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.
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 soft 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 soft drinks.
Figure 2‑1 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