Skip to main content

Rule Definitions vs. Error Messages

In GDSN, it's crucial to distinguish between rule definitions and error messages. While they are related, they serve different purposes and have distinct audiences.

Rule Definitions​

A rule definition is the formal logic that a piece of data must adhere to. It is a precise, technical statement that outlines a specific condition or set of conditions that must be met for the data to be considered valid. Rule definitions are the source of truth for validation engines and developers who implement the validation logic.

Key Characteristics of Rule Definitions:

  • Technical and Precise: Uses formal language and references specific attributes, including their technical IDs.
  • Unambiguous: Leaves no room for interpretation. The logic should be clear and exact.
  • Audience: Primarily for developers, technical analysts, and validation systems.
  • Format: Often uses logical operators like AND and OR to connect conditions, and avoids natural language prose where possible.

Example of a Rule Definition:

If 'tradeItemUnitDescriptorCode' (3074) equals 'BASE_UNIT_OR_EACH' AND 'isTradeItemAConsumerUnit' (3066) equals 'true', then 'consumerFirstAvailabilityDateTime' (3096) must be indicated.

Error Messages​

An error message is a user-facing notification that is displayed when a rule is violated. Its primary purpose is to inform the user what went wrong and guide them on how to fix it. Unlike rule definitions, error messages should be easy to understand for a non-technical audience.

Key Characteristics of Error Messages:

  • User-Friendly: Written in plain language, avoiding jargon and technical IDs unless necessary for clarity.
  • Actionable: Clearly explains the problem and provides a solution or guidance on how to correct the data.
  • Contextual: Should provide enough context for the user to understand the error without needing to reference the original rule definition.
  • Audience: Primarily for data providers, business users, and anyone who needs to correct data entry errors.

Example of an Error Message:

✅ The 'Consumer First Availability Date' must be provided for a base unit that is also a consumer unit.

Why the Distinction Matters​

Separating rule definitions from error messages allows for:

  • Clarity: Developers get the precise technical details they need, while users get clear, actionable feedback.
  • Maintainability: Rule logic can be updated without affecting the user-facing error messages, and vice-versa.
  • Localization: Error messages can be translated into different languages without altering the underlying rule definition.