Skip to main content

GS1 Validation Rule Specifications

This section provides the complete technical specifications for GS1 validation rules as defined in the official GS1 standard "How to Write GDSN Validation Rules" (Release 1.2, December 2019).

Official GS1 Standard

This content is based directly on the official GS1 document and provides the authoritative specifications for creating GDSN validation rules. All rules referenced here are numbered according to the GS1 standard (R01-R43).

Document Conventions​

GS1 Validation Rules are written in UK English and follow specific terminology conventions:

  • SHALL: Indicates a mandatory requirement
  • SHALL NOT: Indicates a prohibition
  • MAY/CAN: Indicates optional allowance

Rule Structure Requirements​

R01: Constraint Expressions​

Validation rules SHALL use constraint expressions with the keywords:

  • SHALL: For mandatory requirements
  • SHALL NOT: For prohibitions

R02: Required Components​

Every validation rule SHALL contain the following components:

  1. Rule identifier number: A unique sequential number
  2. Structured rule: The formal validation logic
  3. Error message: Business-friendly language for users
  4. Affected attributes: List of prerequisite and impacted attributes
  5. Business problem description: Clear explanation of the rule's purpose

R03: Rule Identifier Numbering​

  • Rule numbers SHALL be assigned sequentially
  • Rule numbers SHALL NOT be reused even if a rule is deprecated
  • New rules receive the next available sequential number

R04: Structured Rule Types​

Rules SHALL be structured as one of two types:

  1. Conditional rules: Use "If...then" format for condition-based validation
  2. Statement rules: Direct requirements without conditions

Example Conditional Rule:

If isTradeItemADespatchUnit equals 'true' and isTradeItemNonPhysical equals 'false' or is empty then grossWeight SHALL be greater than '0'.

R05: Error Message Requirements​

Error messages SHALL:

  • Use business-friendly language
  • Avoid technical jargon
  • Be clear and actionable
  • Reference specific field values where appropriate

Example Error Message:

GTIN is <value>. If dataCarrierTypeCode equals 'EAN_8', then the first six digits of the GTIN SHALL equal '000000'.

R06: Impacted Attributes​

Rules SHALL list all affected attributes using:

  • Absolute X-Path notation for each attribute
  • Clear indication of prerequisite vs. impacted attributes

R07: Multiple Instance Attributes​

When rules involve attributes with multiple instances, the rule SHALL:

  • Clearly specify which instances are affected
  • Use appropriate iteration language
  • Define the scope of validation across instances

R08: Business Problem Description​

Each rule SHALL include a description that explains:

  • The business problem being addressed
  • Why the validation is necessary
  • The expected business outcome

R09: Complex Validation Examples​

For complex validation rules, pass/fail examples SHALL be provided showing:

  • Specific data values that would pass validation
  • Specific data values that would fail validation
  • Clear explanation of why each example passes or fails

Example Pass/Fail:

FAIL: tradeItemMeasurements/height = 20 CMT because (5x3)+6 = 21 CMT, so it is SMALLER
PASS: tradeItemMeasurements/height = 21 CMT because (5x3)+6 = 21 CMT, so it is EQUAL

R10: Pseudo-code Translation​

Complex mathematical or logical validations SHALL be translatable to pseudo-code for implementation.

R11: Constrained Party​

Rules SHALL specify which party (data sender, data receiver, or data pool) is responsible for the constraint.

R12: Message Name​

For rules affecting specific message types, the applicable message name SHALL be specified.

R13: Target Market Scope​

Rules SHALL specify their geographic scope:

  • Global: Applies to all markets
  • Market-specific: Uses ISO country codes

R14: Rule Classification​

Rules SHALL be classified as either:

  • Technical Rules: Language, measurement, and currency repetition restrictions
  • Business Rules: All other validation requirements

R15: XML Schema Constraints​

Validation rules SHALL NOT duplicate constraints already enforced by XML Schema definitions.

Writing Conventions​

R16: Attribute Presence Terminology​

Use specific terms for attribute presence:

  • "used": When an attribute is present
  • "not used": When an attribute is absent
  • Avoid "populated", "filled", "provided"

R17: Attribute Naming​

  • Attributes SHALL be expressed in lowercase
  • Use technical attribute names, not business terms
  • Format: attributeName not "Attribute Name"

R18: Value Equality​

Use "equal" when expressing attribute values.

R19: Value Formatting​

All values SHALL be enclosed in single quotes: 'value'

Examples:

  • 'EAN_8'
  • 'true'
  • '000000'

R20: Bracket Usage​

Use brackets to improve readability in complex expressions:

If (isTradeItemPackedIrregularly equals 'false' or is not used) and trade item is at top level...

R21: Multiple Value Choices​

For multiple values, use comma-separated lists with 'or' before the final option:

'AMBIENT', 'CHILLED', 'FROZEN', or 'OTHER'

R22: And/Or Usage​

  • Use "and/or" when both conditions may apply simultaneously
  • Use "or" for mutually exclusive choices
  • Use "and" when all conditions must be met

R23: Language/Unit/Currency Repeatability​

For attributes that can repeat for different languages, units, or currencies, rules SHALL specify exactly which instances are affected.

R24: Paired/Grouped Attributes​

When attributes work in pairs or groups, rules SHALL clearly specify the relationship and requirements for each member of the group.

R25: Boolean Expressions​

Boolean values SHALL be expressed as:

  • 'true' for true conditions
  • 'false' for false conditions
  • Never use 1/0 or yes/no

R26: Mathematical Calculations​

Mathematical operations SHALL use standard operators:

  • x for multiplication
  • / for division
  • + for addition
  • - for subtraction

R27: Date/Time Comparisons​

For date/time validations:

  • Use "before" for temporal precedence
  • Use "in the future" for future date requirements
  • Be explicit about timezone considerations

R28: Iteration Constraints​

Use "maximum" when specifying limits on repetition or iteration.

R43: Logical Sequence​

Rules SHALL follow a logical sequence addressing:

  1. Target Market constraints first
  2. Product (GPC) constraints second
  3. Business context constraints last

Implementation Guidelines​

Structured Rule Format​

If [condition] then [requirement]

Error Message Format​

[Field] is [current_value]. [Requirement explanation].

Attribute Reference Format​

attributeName (attributeID)

Mathematical Expression Format​

If condition then attributeA SHALL [operator] ((attributeB x attributeC) + attributeD)
Implementation Note

These specifications ensure consistency across different data pools and solution providers implementing GDSN validation rules. All rules must comply with these standards to maintain interoperability within the GDSN ecosystem.