DocumentWDP-2
TitleComponent Field Specification
Version0.1.0-draft
StatusDraft
CategoryStandards Track (Core)
Created2025-11-30
Updated2025-12-25

WDP Part 2: Component Field Specification

Part 2 of the Waddling Diagnostic Protocol (WDP): the Component field. The component field identifies the system module, service, or domain that produced the diagnostic code.

Abstract#

This document specifies Part 2 of the Waddling Diagnostic Protocol (WDP): the Component field. The component field identifies the system module, service, or domain that produced the diagnostic code. It represents the highest level of categorization in the diagnostic code hierarchy and MAY represent physical subsystems, logical modules, service boundaries, or architectural layers.

Specification Navigation: See STRUCTURE.md for an overview of all WDP specification parts.

Conformance

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1. Introduction#

1.1 Purpose

The component field is the second part of a WDP diagnostic code. It provides the highest level of categorization, identifying which part of the system produced the diagnostic code.

1.2 Position in Error Code

Complete WDP Structure:

Severity.Component.Primary.Sequence -> CompactID
    ^         ^        ^        ^          ^
  Part 1    Part 2   Part 3   Part 4    Part 5

This Document Focus:

Severity.Component.Primary.Sequence -> CompactID
          ^^^^^^^^^
          Part 2: System module or domain (THIS DOCUMENT)

Example: E.Auth.Token.001 - The Auth indicates the authentication/authorization component.

1.3 Design Goals

The component field design adheres to the following principles:

  • Hierarchical organization: Enable grouping of related diagnostics
  • Flexible categorization: Support different organizational approaches
  • Human-readable: PascalCase format for clarity
  • Concise: Maximum 16 characters
  • Searchable: Enable filtering by component (e.g., E.Auth.*)

2. Purpose and Role#

2.1 What is a Component?

A Component represents a domain of responsibility within a system. It serves as the top level of the diagnostic taxonomy.

Key characteristics:

  • Highest level of categorization
  • Groups related diagnostics together
  • Enables filtering and monitoring by subsystem
  • Reflects the system's architecture or organization

2.2 Component is NOT Just Physical

Components MAY represent various organizational structures:

  • Physical subsystem: Database, Network, FileSystem, Cache
  • Logical module: Auth, Validation, BusinessLogic, Parser
  • Service boundary: UserService, OrderService, PaymentGateway
  • Architectural layer: Api, Domain, Infrastructure

Implementations SHOULD choose the structure that best represents their system architecture.

2.3 Relationship to Primary

Components contain Primaries (Part 3), which provide finer-grained classification:

Component: Auth
  ├─ Primary: Token
  ├─ Primary: Session
  └─ Primary: Permission

Component: Database
  ├─ Primary: Connection
  ├─ Primary: Query
  └─ Primary: Transaction

3. Field Specification#

3.1 Format

The component field MUST conform to the following specification:

PropertyRequirement
Naming ConventionPascalCase (UpperCamelCase)
PatternStarts with uppercase letter, followed by letters and/or digits
Character SetASCII letters (a-z, A-Z) and digits (0-9) only
Maximum Length16 characters
Recommended Length8-12 characters
RequiredYES (REQUIRED field)
PositionSecond field (after Severity)

3.2 Regex Pattern

Implementations MUST use the following regular expression for validation:

Regex
^[A-Z][a-zA-Z0-9]{0,15}$

Pattern explanation:

  • ^ - Start of string
  • [A-Z] - MUST start with uppercase letter
  • [a-zA-Z0-9]{0,15} - Followed by 0-15 letters or digits
  • $ - End of string

Total length: 1-16 characters

3.3 Case Sensitivity

Display form: PascalCase (e.g., Auth, TokenValidator)
Hash form: UPPERCASE (e.g., AUTH, TOKENVALIDATOR)

See Section 8: Hash Canonical Form for normalization requirements.

4. Component Types#

This section describes RECOMMENDED component categorization patterns. These patterns are INFORMATIVE; implementations MAY use any organizational structure appropriate to their domain.

4.1 Physical Subsystems

Physical subsystems represent actual system resources or infrastructure components.

Examples:

Database          - Database server or layer
Network           - Network communication layer
FileSystem        - File I/O subsystem
Cache             - Caching layer (Redis, Memcached, etc.)
Queue             - Message queue (RabbitMQ, Kafka, etc.)
Storage           - Object storage (S3, blob storage)
Memory            - Memory management
Disk              - Disk I/O operations

Applicable when: Diagnostics map naturally to infrastructure or system resources.

4.2 Logical Modules

Logical modules represent conceptual or functional domains within an application.

Examples:

Auth              - Authentication/authorization logic
Validation        - Input validation logic
BusinessLogic     - Core domain logic
Parser            - Parsing and syntax analysis
Serializer        - Data serialization/deserialization
Transformer       - Data transformation
Mapper            - Object mapping (ORM, DTO conversion)
Encoder           - Encoding/decoding logic

Applicable when: Diagnostics map to functional responsibilities rather than physical components.

4.3 Service Boundaries

Service boundaries represent microservices or service-oriented architecture boundaries.

Examples:

UserService       - User management service
OrderService      - Order processing service
PaymentGateway    - Payment integration service
NotificationSvc   - Notification service
AuthService       - Authentication service
InventoryService  - Inventory management
EmailService      - Email sending service

Applicable when: The system follows a service-oriented or microservices architecture.

Note: Names SHOULD be kept concise. NotificationSvc (15 chars) is preferable to NotificationService (19 chars, exceeds limit).

4.4 Architectural Layers

Architectural layers represent layers in a layered architecture pattern.

Examples:

Api               - API/presentation layer
Domain            - Domain/business logic layer
Infrastructure    - Infrastructure layer
Persistence       - Data persistence layer
Application       - Application service layer
Presentation      - UI/presentation layer

Applicable when: The system follows a strict layered architecture and diagnostics map to layers.

4.5 Mixed Approach

Implementations MAY mix component types. The organizational structure SHOULD be chosen based on what makes sense for each part of the system.

Example:

Auth              - Logical module
Database          - Physical subsystem
UserService       - Service boundary
Api               - Architectural layer
Parser            - Logical module
Network           - Physical subsystem

5. Naming Guidelines#

This section provides RECOMMENDED naming conventions. Adherence to these guidelines is NOT REQUIRED for conformance but is RECOMMENDED for consistency and readability.

Auth              - Clear purpose
Database          - Descriptive
TokenValidator    - Specific and clear
PaymentGateway    - Understandable
Parser            - Standard term

Recommended length: 8-12 characters

Auth                 (4 chars)
Database             (8 chars)
Validation           (10 chars)
TokenValidator       (14 chars)
ServiceRegistry      (15 chars)

Maximum length: 16 characters (enforced)

ConfigValidator      (15 chars)
ConnectionPool       (14 chars)
AuthenticationService (21 chars) - Too long! (Invalid)
ConfigurationManager  (20 chars) - Too long! (Invalid)

Implementations SHOULD use terms that are familiar to the team and domain:

Auth          - Widely understood in web development
Catalog       - Makes sense for e-commerce
Fulfillment   - E-commerce/logistics term
Ledger        - Financial/accounting term
Parser        - Compiler/language processing

Implementations SHOULD adopt a consistent naming style across the codebase:

Consistent (RECOMMENDED):

Auth, Database, Parser, Network, Cache

Inconsistent (NOT RECOMMENDED):

Auth, DB, parser, NetworkLayer, caching

The following names SHOULD be avoided as they do not convey specific meaning:

Module        - Too generic
System        - Too vague
Error         - Meaningless (everything is an error)
Handler       - What does it handle?
Manager       - What does it manage?
Service       - Too generic (which service?)

Exception: Generic names MAY be acceptable for small or simple systems.

Component names SHOULD NOT include version numbers:

AuthV2        - Version numbers shouldn't be in error codes
ApiV1         - Use different component name if truly different
Parser2       - Indicates poor naming

Valid examples:
Auth          - Version-agnostic
Api           - Can evolve without renaming

Rationale: Diagnostic codes SHOULD be stable. If versioning is required, implementations SHOULD create a new component name that reflects the actual difference (e.g., Auth vs OAuthProvider).

Abbreviations SHOULD only be used when widely recognized.

Widely recognized abbreviations:

HTTP          - Universally recognized
API           - Widely understood
JWT           - Standard in auth context
DB            - Commonly used (though "Database" is better)
IO            - Standard abbreviation
UI            - Widely understood

Obscure or domain-specific abbreviations (NOT RECOMMENDED):

AuthZ         - Use "Auth" or "Authorization"
PersCtx       - Use "PersistenceContext"
UsrMgmt       - Use "UserManagement" or "UserService"
TxnProc       - Use "Transaction" or "TransactionProcessor"

Guidance: When in doubt, use the full word or a clearer term.

6. Common Components#

This section provides INFORMATIVE examples of common component names organized by domain. These are suggestions; implementations MAY use any names that conform to the format specification.

6.1 Authentication & Authorization

Auth              - General authentication/authorization
AuthService       - Authentication service
Security          - Security operations
Crypto            - Cryptographic operations
Encryption        - Encryption/decryption

6.2 Data & Persistence

Database          - Database operations
DB                - Database (abbreviated)
Persistence       - Data persistence layer
Storage           - File/object storage
Cache             - Caching layer
Repository        - Repository pattern
ORM               - Object-relational mapping

6.3 Communication & Networking

Network           - Network operations
Net               - Network (abbreviated)
HTTP              - HTTP client/server
API               - API layer
Gateway           - API gateway or service gateway
Queue             - Message queue
EventBus          - Event bus
WebSocket         - WebSocket communication

6.4 Processing & Logic

Parser            - Parsing and syntax analysis
Compiler          - Compilation
Validator         - Validation logic
Validation        - Input validation
Transformer       - Data transformation
Processor         - Data processing
Engine            - Processing engine
Workflow          - Workflow execution

6.5 Business & Domain

BusinessLogic     - Core business logic
Domain            - Domain layer
Order             - Order management
Payment           - Payment processing
Inventory         - Inventory management
Fulfillment       - Order fulfillment
Catalog           - Product catalog

6.6 System & Infrastructure

Config            - Configuration management
Logger            - Logging subsystem
Monitoring        - Monitoring/metrics
Scheduler         - Task scheduling
Background        - Background job processing
Migration         - Database migration
Deployment        - Deployment operations

6.7 User Interface

UI                - User interface
Frontend          - Frontend application
Api               - API/presentation layer
Controller        - MVC controller
View              - View/rendering
Form              - Form handling

7. Validation Rules#

7.1 Format Validation

A valid component MUST satisfy the following requirements:

  1. MUST start with uppercase letter: [A-Z]
  2. MUST be followed by 0-15 letters or digits: [a-zA-Z0-9]{0,15}
  3. MUST have total length of 1-16 characters
  4. SHOULD follow PascalCase convention (RECOMMENDED but not enforced)
  5. MUST NOT contain special characters (no hyphens, underscores, spaces, etc.)

7.2 Validation Examples

Valid (conformant):

A                    // 1 char minimum - Valid
Auth                 // lowercase allowed after first - Valid
Database             // mixed case allowed - Valid
API                  // all caps after first allowed - Valid
Http2Server          // digit allowed - Valid
TokenValidator       // 14 chars - Valid
ConfigValidator      // 15 chars - Valid
ABCDEFGHIJKLMNO      // 16 chars (maximum length) - Valid

Invalid (non-conformant):

auth                 // MUST start with uppercase - Invalid
Auth-Service         // hyphens NOT permitted - Invalid
Auth_Service         // underscores NOT permitted - Invalid
Auth Service         // spaces NOT permitted - Invalid
Auth!                // special characters NOT permitted - Invalid
2Auth                // MUST NOT start with digit - Invalid
AuthenticationService // exceeds 16-char maximum (21 chars) - Invalid

7.3 Validation Regex

Implementations MUST use the following regular expression:

Regex
^[A-Z][a-zA-Z0-9]{0,15}$

7.4 PascalCase Enforcement

Note: The regex permits any mix of uppercase/lowercase after the first character. However, PascalCase is RECOMMENDED for readability:

RECOMMENDED:  Auth, Database, TokenValidator
Permitted:    AUTH, auth, database, TOKENVALIDATOR

Implementations SHOULD enforce PascalCase via linters or code review.

8. Hash Canonical Form#

8.1 Purpose

To enable case-insensitive lookups and prevent typographical errors from creating phantom diagnostic codes, WDP REQUIRES uppercase normalization before hashing.

8.2 Display Form vs Hash Form

Display form (PascalCase): Used for human-readable output

E.Auth.Token.001
E.Database.Connection.021
E.TokenValidator.Parse.003

Hash form (UPPERCASE): Used for compact ID computation

E.AUTH.TOKEN.001
E.DATABASE.CONNECTION.021
E.TOKENVALIDATOR.PARSE.003

8.3 Normalization Process

Implementations MUST normalize diagnostic codes to uppercase before computing the compact ID hash:

  1. Display: E.Auth.Token.001
  2. Normalize: E.AUTH.TOKEN.001 (convert to uppercase)
  3. Hash: Compute hash from normalized form
  4. Compact ID: Xy8Qz

8.4 Benefits

Case-insensitive lookups:

All of the following MUST produce the same hash:

E.Auth.Token.001    → E.AUTH.TOKEN.001 → Xy8Qz
E.AUTH.TOKEN.001    → E.AUTH.TOKEN.001 → Xy8Qz
e.auth.token.001    → E.AUTH.TOKEN.001 → Xy8Qz
E.auth.Token.001    → E.AUTH.TOKEN.001 → Xy8Qz

Typographical error resilience: Users MAY search for diagnostics without concern for exact case.

Cross-implementation safety: Even if implementations format slightly differently, hashes MUST match.

8.5 Implementation Requirements

Implementations:

  • SHOULD display diagnostic codes in PascalCase
  • SHOULD enforce PascalCase via validation/linters
  • MUST convert to uppercase only when computing hash
  • SHOULD NOT store or transmit the uppercase form (use display form)

9. Implementation Guide#

This section provides RECOMMENDED implementation patterns. Implementations MAY use alternative approaches provided they satisfy the normative requirements in Sections 3, 7, and 8.

9.1 Rust Implementation

Rust
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct Component {
    name: String,
}

impl Component {
    /// Create a new component with validation
    pub fn new(name: impl Into<String>) -> Result<Self, ValidationError> {
        let name = name.into();
        
        // Validate format
        if !Self::is_valid(&name) {
            return Err(ValidationError::InvalidComponent(name));
        }
        
        Ok(Self { name })
    }
    
    /// Validate component format
    pub fn is_valid(name: &str) -> bool {
        // Regex: ^[A-Z][a-zA-Z0-9]{0,15}$
        if name.is_empty() || name.len() > 16 {
            return false;
        }
        
        let mut chars = name.chars();
        
        // First character must be uppercase letter
        if !matches!(chars.next(), Some('A'..='Z')) {
            return false;
        }
        
        // Remaining characters must be letters or digits
        chars.all(|c| c.is_ascii_alphanumeric())
    }
    
    /// Get display form (PascalCase)
    pub fn as_str(&self) -> &str {
        &self.name
    }
    
    /// Get hash canonical form (UPPERCASE)
    pub fn canonical(&self) -> String {
        self.name.to_uppercase()
    }
}

impl std::fmt::Display for Component {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "{}", self.name)
    }
}

9.2 Python Implementation

Python
import re

class Component:
    """Represents a WDP component field."""
    
    # Validation regex
    PATTERN = re.compile(r'^[A-Z][a-zA-Z0-9]{0,15}$')
    
    def __init__(self, name: str):
        """Create a new component with validation."""
        if not self.is_valid(name):
            raise ValueError(f"Invalid component: {name}")
        self.name = name
    
    @staticmethod
    def is_valid(name: str) -> bool:
        """Validate component format."""
        return bool(Component.PATTERN.match(name))
    
    def __str__(self) -> str:
        """Get display form (PascalCase)."""
        return self.name
    
    def canonical(self) -> str:
        """Get hash canonical form (UPPERCASE)."""
        return self.name.upper()
    
    def __eq__(self, other) -> bool:
        return isinstance(other, Component) and self.name == other.name
    
    def __hash__(self) -> int:
        return hash(self.name)

9.3 TypeScript Implementation

Typescript
class Component {
  private static readonly PATTERN = /^[A-Z][a-zA-Z0-9]{0,15}$/;
  
  constructor(private readonly name: string) {
    if (!Component.isValid(name)) {
      throw new Error(`Invalid component: ${name}`);
    }
  }
  
  static isValid(name: string): boolean {
    return Component.PATTERN.test(name);
  }
  
  toString(): string {
    return this.name;
  }
  
  canonical(): string {
    return this.name.toUpperCase();
  }
  
  equals(other: Component): boolean {
    return this.name === other.name;
  }
}

10. Examples#

This section provides INFORMATIVE examples demonstrating component usage patterns.

10.1 Complete Diagnostic Codes by Component Type

Physical Components:

E.Database.Connection.021     - Database connection failed
E.Network.Connection.028      - Network host unreachable
E.FileSystem.File.021         - File not found
E.Cache.Connection.027        - Cache server unavailable
E.Queue.Connection.029        - Message queue disconnected

Logical Components:

E.Auth.Token.001              - Authentication token missing
E.Validation.Input.003        - Input validation failed
E.Parser.Syntax.003           - Syntax error in input
E.BusinessLogic.Rule.008      - Business rule violation
E.Crypto.Key.001              - Encryption key missing

Service Components:

E.UserService.Query.021       - User not found
E.OrderService.Create.008     - Order creation denied
E.PaymentGateway.Process.017  - Payment timeout
E.EmailService.Send.027       - Email service unavailable

Layer Components:

E.Api.Request.003             - Invalid API request
E.Domain.Validation.003       - Domain validation failed
E.Persistence.Save.027        - Persistence layer unavailable

10.2 Real-World Examples

Web Application:

E.Auth.Login.008              - Login denied
E.Api.RateLimit.008           - Rate limit exceeded
E.Database.Query.017          - Query timeout
E.Cache.Get.021               - Cache key not found
E.Session.Expired.018         - Session expired

Compiler/Parser:

E.Lexer.Token.001             - Unexpected token
E.Parser.Syntax.003           - Syntax error
E.Semantic.Type.002           - Type mismatch
E.Codegen.Output.027          - Code generation failed

Microservices:

E.UserService.Auth.008        - User authentication failed
E.OrderService.Create.003     - Invalid order data
E.InventoryService.Stock.026  - Out of stock
E.PaymentGateway.Charge.017   - Payment processing timeout
E.NotificationSvc.Send.027    - Notification service down

Appendix A. Quick Reference#

Component Format

Format:   PascalCase
Regex:    ^[A-Z][a-zA-Z0-9]{0,15}$
Length:   1-16 characters (recommended: 8-12)
Position: Second field
Required: YES

Component Types

Physical:      Database, Network, FileSystem, Cache
Logical:       Auth, Validation, Parser, BusinessLogic
Service:       UserService, OrderService, PaymentGateway

Appendix B. Normative References#

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

End of Component Field Specification