Independent Submission J. Potvin Internet-Draft C. Langlois Intended status: Informational Xalgorithms Foundation Expires: 12 August 2026 8 February 2026 Data With Direction (DWD) Pipe-Separated Format draft-potvin-dwd-pipe-separated-format-00 Abstract This document specifies the Data With Direction (DWD) pipe-separated file format, a text-based format for encoding rule-based decision logic. The format represents rules as collections of metadata and truth tables that define input conditions and output assertions. The format is designed for human readability and editability, machine parsing and processing, version control system compatibility, and exchange between rule management systems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 August 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Potvin & Langlois Expires 12 August 2026 [Page 1] Internet-Draft DWD-PSF February 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Notational Conventions . . . . . . . . . . . . . . . . . 4 2. Document Structure . . . . . . . . . . . . . . . . . . . . . 4 2.1. File Encoding . . . . . . . . . . . . . . . . . . . . . . 4 3. Line Structure . . . . . . . . . . . . . . . . . . . . . . . 5 4. Field Structure . . . . . . . . . . . . . . . . . . . . . . . 5 5. Record Types . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Metadata Section . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Metadata Fields . . . . . . . . . . . . . . . . . . . . . 6 6.2. Nested Metadata . . . . . . . . . . . . . . . . . . . . . 7 6.3. Reserved Fields . . . . . . . . . . . . . . . . . . . . . 7 7. Truth Table Section . . . . . . . . . . . . . . . . . . . . . 8 7.1. Truth Table Structure Overview . . . . . . . . . . . . . 8 7.2. Row Identifiers . . . . . . . . . . . . . . . . . . . . . 9 7.3. Column Headers . . . . . . . . . . . . . . . . . . . . . 10 7.4. Data Rows . . . . . . . . . . . . . . . . . . . . . . . . 10 7.5. Expression Field Content . . . . . . . . . . . . . . . . 11 7.6. Truth Value Encoding . . . . . . . . . . . . . . . . . . 11 7.7. DWD Storage Formats . . . . . . . . . . . . . . . . . . . 12 8. Syntax Specification . . . . . . . . . . . . . . . . . . . . 14 8.1. ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 14 8.2. Field Value Constraints . . . . . . . . . . . . . . . . . 15 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Complete Example . . . . . . . . . . . . . . . . . . . . 16 9.2. Metadata Only Example . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10.1. Input Validation . . . . . . . . . . . . . . . . . . . . 17 10.2. Field Value Sanitization . . . . . . . . . . . . . . . . 17 10.3. External References . . . . . . . . . . . . . . . . . . 18 10.4. Privacy Considerations . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . 19 Potvin & Langlois Expires 12 August 2026 [Page 2] Internet-Draft DWD-PSF February 2026 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 19 Appendix B. Appendix A. Comparison with Related Formats . . . . 20 B.1. CSV (Comma-Separated Values) . . . . . . . . . . . . . . 20 B.2. TSV (Tab-Separated Values) . . . . . . . . . . . . . . . 20 B.3. JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix C. Appendix B. Implementation Guidelines . . . . . . . 20 C.1. Parsing Strategy . . . . . . . . . . . . . . . . . . . . 20 C.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 C.3. Round-Trip Preservation . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction 1.1. Purpose This document specifies the Data With Direction (DWD) pipe-separated file format. The format represents rules as collections of metadata and truth tables that define input conditions and output assertions. The format is designed for: * Human readability and editability * Machine parsing and processing * Version control system compatibility * Exchange between rule management systems 1.2. Scope This specification defines: * The syntax and structure of DWD pipe-separated files * The interpretation of metadata fields * The encoding of truth tables * Constraints on field values This specification does NOT define: * The semantics of specific rule domains * Processing algorithms for truth tables * Storage or transmission mechanisms Potvin & Langlois Expires 12 August 2026 [Page 3] Internet-Draft DWD-PSF February 2026 * User interface representations 1.3. Terminology 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. Additional terms used in this specification: DWD Document: A file conforming to this specification containing rule metadata and truth table data. Record: A single line in a DWD document representing either metadata or truth table data. Field: A data element within a record, separated by pipe characters. Truth Table: A tabular representation of input conditions mapped to output assertions. Scenario: A specific combination of input conditions identified by a column in the truth table. 1.4. Notational Conventions This specification uses ABNF [RFC5234] for formal syntax definitions. The pipe character '|' is used as both a delimiter in the format and in ABNF grammar. In ABNF examples, the pipe character as a delimiter is represented as %d124 (ASCII decimal value). 2. Document Structure 2.1. File Encoding DWD documents MUST be encoded using UTF-8 [RFC3629]. DWD documents SHOULD use Unix-style line endings (LF, %d10). Implementations MAY also accept Windows-style line endings (CRLF, %d13 %d10) for interoperability. The byte order mark (BOM) MUST NOT be present in DWD documents. Potvin & Langlois Expires 12 August 2026 [Page 4] Internet-Draft DWD-PSF February 2026 3. Line Structure A DWD document consists of a sequence of lines. Each line represents either a metadata record or a truth table record. Lines are delimited by line ending characters. The final line of a document SHOULD be terminated with a line ending. Parser implementations MAY handle a final line without a line ending for robustness against unconforming implementations or legacy or corrupted data files. Blank lines (lines containing only whitespace or empty) SHOULD be ignored by parsers and SHOULD NOT be generated. Lines SHOULD NOT exceed 1000 characters in length. Implementations MUST support lines of at least 2000 characters for robustness. 4. Field Structure Each line is composed of fields separated by the pipe character (|, ASCII 124). The pipe character serves as the field delimiter. Field Structure Rules: 1. Every line MUST begin with a pipe character. For retrocompatibility and robustness, implementations SHOULD handle a missing leading pipe character with no functional degradation. 2. Every line MUST end with a pipe character and line ending. For retrocompatibility and robustness, Implementations SHOULD handle a missing trailing pipe character with no functional degradation. 3. Fields are the text between pipe delimiters. 4. Empty fields (consecutive pipes) are valid and represent empty string values. 5. Leading and trailing whitespace within fields SHOULD be preserved but MAY be trimmed by implementations. Example field structure: |field1|field2|field3| This line contains three fields: "field1", "field2", and "field3". |field1||field3| Potvin & Langlois Expires 12 August 2026 [Page 5] Internet-Draft DWD-PSF February 2026 This line contains three fields: "field1", "" (empty), and "field3". 5. Record Types DWD documents contain two main sections: 1. Metadata Section - Contains descriptive information _about_ the rule 2. Truth Table Section - Contains the decision logic concerned by the rule as a truth table Record type is determined by the content of the first field: * Records with a first field containing a dot-separated identifier (e.g., "metadata.rule.120_title") are metadata records. (See Section 6). * Records with a first field starting with "INDEX" are truth table column header records. (See Section 7). * Records with a first field starting with a letter followed by digits and dots (e.g., "W1.1", "T_W1.1_W2.1_W3.1") are truth table data records. (See Section 7). 6. Metadata Section 6.1. Metadata Fields Metadata records use a key-value pair structure. The first field contains the metadata key (a hierarchical identifier), and the second field contains the value. Metadata Record Format: |key|value| The key uses dot notation to represent hierarchy: * Top-level categories (e.g., "rule_id", "version_standard_url") * Nested properties (e.g., "metadata.rule.120_title") * Array indices (e.g., "metadata.rule.rulemaker_manager.1.name") Required Metadata Fields: Potvin & Langlois Expires 12 August 2026 [Page 6] Internet-Draft DWD-PSF February 2026 +==================+=========================+=====================+ | Field | Description | Value type | +==================+=========================+=====================+ | rule_id | Unique rule identifier | UUID | +------------------+-------------------------+---------------------+ | ruledata_version | Format version (SemVer) | Dotted digit string | +------------------+-------------------------+---------------------+ Table 1 (See Section 8.2). Other metadata fields to expect are outside the scope of this specification, and may evolve independently. Those two required fields are considered critical for the technical considerations of this file format (a unique identifier to distinguish rules efficiently, and a format version specifier to establish which specification version was used to produce the file, and allow parser implementations to efficiently handle different versions). A separate specification should be expected to distinguish other mandatory and optional fields for semantic purpose, detail the validation rules for the values of those fields, any semantics attached to them, and constraints on user-specific metadata. 6.2. Nested Metadata Metadata supports nested structures using dot notation and numeric indices for arrays. Object Properties: |metadata.rule.rulemaker_manager.1.name|John Doe| |metadata.rule.rulemaker_manager.1.email|john@example.com| Array Representation: Arrays are represented using 1-based numeric indices. The index appears as the final component of the key path. |metadata.rule.rulemaker_manager.1.name|Manager One| |metadata.rule.rulemaker_manager.2.name|Manager Two| 6.3. Reserved Fields The following field names are reserved and have special meaning: * INDEX - Marks the beginning of the truth table column header row Potvin & Langlois Expires 12 August 2026 [Page 7] Internet-Draft DWD-PSF February 2026 * W1, W2... - Truth table row identifiers (World/Condition identifiers) * T_... - Truth table cell entries (Transaction/Truth entries) Reserved field patterns: * /^W\d+(.\d+)*$/ - World/scenario identifiers * /^T_W\d+_W\d+_W\d+/ - Truth table cell identifiers * /^INDEX/ - Column header marker 7. Truth Table Section 7.1. Truth Table Structure Overview DWD truth tables use a hierarchical organization with three main categories of rows: W1 (World/Scenario): Defines the possible scenarios or cases being considered. Each W1.x row represents a distinct scenario identifier (e.g., A, B, C, D). W2 (Function): Specifies whether a row represents an input condition or an output assertion: * W2.1: Input Condition - Conditions that must be evaluated * W2.2: Output Assertion - Results or actions to be taken W3 (Expression): Contains the actual logical expressions or values associated with the conditions. These may be: * Human-readable descriptions * Machine-readable JSON structures * References to external data For Lookup Tables, a similar structure uses K-rows: K1, K2, K3... (Key Categories): Hierarchical key dimensions for multi-dimensional lookup tables. Each Kx.y represents a specific key value within a category. The relationship between these components creates a three-dimensional logical space where: * W1 defines the scenario/case dimension * W2 defines the functional dimension (input/output) * W3 provides the semantic content Truth table entries (T-rows) connect these dimensions: T_W{x}_W{y}_W{z} indicates the truth value at the intersection of scenario W1.x, function W2.y, and expression W3.z. Potvin & Langlois Expires 12 August 2026 [Page 8] Internet-Draft DWD-PSF February 2026 7.2. Row Identifiers W-Row Identifier Format: * W{n} - Category header (e.g., W1, W2, W3) * W{n}.{m} - Specific condition within category (e.g., W1.1, W1.2) * W{n}.{m}.{o} - Further subdivision (e.g., W1.1.1, W1.1.2) W-Row Types: +======+==========+==============================+ | Type | Pattern | Purpose | +======+==========+==============================+ | W1 | W1, W1.x | Scenario/World identifiers | +------+----------+------------------------------+ | W2 | W2, W2.x | Function type (Input/Output) | +------+----------+------------------------------+ | W3 | W3, W3.x | Expression/Value definitions | +------+----------+------------------------------+ Table 2 K-Row Identifier Format (for Lookup Tables): * K{n} - Key category header (e.g., K1, K2, K3) * K{n}.{m} - Specific key value (e.g., K1.1, K1.2) K-Row Types: +===========+================+=====================================+ | Type | Pattern | Purpose | +===========+================+=====================================+ | K1, K2... | K1, K1.x, etc. | Key dimension categories | +-----------+----------------+-------------------------------------+ | V_... | V_Kx.y_Kz.w... | Value assertions at key coordinates | +-----------+----------------+-------------------------------------+ Table 3 Identifier Constraints: * Numbers are 1-indexed (start at 1, not 0) * Hierarchical depth is theoretically unlimited Potvin & Langlois Expires 12 August 2026 [Page 9] Internet-Draft DWD-PSF February 2026 * Each identifier within a category MUST be unique * Labels (second field) provide human-readable descriptions 7.3. Column Headers The truth table section begins with a column header row. This row defines the columns of the truth table and their indices. Column Header Format: |INDEX|DATA|1|2|3|4|5|...|n| Where: * "INDEX" - Identifies this as the column header row * "DATA" - Indicates data columns follow * "1" through "n" - Column numbers (positive integers) The column header row establishes the numbering for all subsequent truth table data rows. 7.4. Data Rows Truth table data rows represent either: a) Row headers (labels for conditions or assertions) b) Truth values (the actual decision logic) Row Header Format: |identifier|label|index1|index2|...|indexN| Examples: |W1|COLUMNHEADER|1|2|3|4|5|...| |W1.1|A|1|10|19|28|...| |W2|Function|1|2|3|4|5|...| Truth Value Format: |T_W{row}_W{col}_W{expr}|value|column| Examples: |T_W1.1_W2.1_W3.1|01|1| |T_W1.2_W2.1_W3.1|00|2| Potvin & Langlois Expires 12 August 2026 [Page 10] Internet-Draft DWD-PSF February 2026 7.5. Expression Field Content W3 (Expression) rows contain the semantic definitions of conditions and assertions. These fields MAY contain: Plain Text: * Human-readable descriptions of conditions * Natural language statements JSON Structures: * Machine-parseable structured data * Semantic triples or property-value pairs * References to external vocabularies Example JSON in expression field: |W3.1|{"determiner":"The","noun":"box","past_participle_verb":"measured","attribute":"type","predicate_verb":"is","description":"standard"}| JSON Escaping Rules: * Double quotes within JSON MUST be escaped as " * Backslashes MUST be escaped as \ * Newlines within JSON SHOULD be avoided; use \n if necessary * The entire JSON object MUST be valid JSON when unescaped Parsers SHOULD: * Detect JSON content by attempting to parse the field value * Fall back to treating content as plain text if JSON parsing fails * Validate JSON structure according to application- specific schemas Note: The JSON structure shown in examples uses a specific vocabulary for rule expressions. The exact schema is application-dependent and outside the scope of this specification. 7.6. Truth Value Encoding DWD uses a four-valued logic system encoded as two-character strings. This supports classical binary logic as well as reasoning under uncertainty and paraconsistent scenarios. Potvin & Langlois Expires 12 August 2026 [Page 11] Internet-Draft DWD-PSF February 2026 +=======+=======================================================+ | Value | Meaning | +=======+=======================================================+ | "00" | FALSE / Absent - Condition not met, assertion invalid | +-------+-------------------------------------------------------+ | "01" | TRUE / Present - Condition met, assertion valid | +-------+-------------------------------------------------------+ | "10" | MAYBE / UNKNOWN - Undetermined, uncertain, or | | | requires further evaluation | +-------+-------------------------------------------------------+ | "11" | BOTH / CONTRADICTION - Inconsistent state, both true | | | and false simultaneously | +-------+-------------------------------------------------------+ Table 4 The four-valued logic allows DWD to represent: * Classical binary decisions (00, 01) * Uncertainty or incomplete information (10) * Inconsistent or contradictory states (11) Processing Behavior: * When evaluating truth tables, implementations SHOULD handle all four values according to the logic semantics appropriate for the application domain. * The "10" (unknown) value indicates that the truth of the condition cannot be determined from available data, and MAY trigger additional data collection or default handling. * The "11" (contradiction) value indicates a logical inconsistency that SHOULD be flagged for review or resolution. Note: Earlier versions of DWD used "--" to indicate "don't care" conditions. This is now deprecated in favor of explicit four-valued encoding. 7.7. DWD Storage Formats DWD supports two complementary storage formats for truth table data: DWD Array Format (KVa) ~~~~~~~~~~~~~~~~~~~~~ The full matrix representation with explicit 00/01/10/11 values in every cell. This format is human-readable and suitable for direct inspection and auditing. Potvin & Langlois Expires 12 August 2026 [Page 12] Internet-Draft DWD-PSF February 2026 Characteristics: * Complete truth table matrix with all cells populated * Binary patterns clearly visible for validation * Identity matrix structure for value assertions * Suitable for visualization and debugging Example (truncated): |K1.1|Label|01|00|00|01|00|00| |K1.2|Label|00|01|00|00|01|00| |T_K1.1_K2.1_K3.1|Value|01|00|00|00|00|00| DWD Coordinates Format (KVc) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A compressed representation listing only the column indices where values are present (01). This format is optimized for storage and transmission. Characteristics: * Lists only column numbers where value is "01" * Compact representation suitable for large tables * Easily auditable via text search on index numbers * Can be expanded to full array format when needed Format: |identifier|label|column1|column2|...|columnN| Where column numbers are 1-indexed positions where the value is "01". Example: |K1.1|Label|1|4|7|10| |K1.2|Label|2|5|8|11| |V_K1.1_K2.1_K3.1|Value|1| Conversion: * Array to Coordinates: For each row, record column indices where value equals "01" * Coordinates to Array: Create matrix with "00" in all cells, then set "01" at specified coordinates Implementation Note: RuleMaker generates the Coordinates format for storage efficiency. The Array format is useful for visualization, debugging, and direct human audit. Both formats contain identical semantic information. Potvin & Langlois Expires 12 August 2026 [Page 13] Internet-Draft DWD-PSF February 2026 8. Syntax Specification 8.1. ABNF Grammar The following grammar defines the formal syntax of DWD documents using ABNF [RFC5234]. ; Basic Definitions PIPE = %d124 ; "|" character CR = %d13 ; Carriage return LF = %d10 ; Line feed CRLF = CR LF ; Internet standard newline VCHAR = %d33-126 ; Visible characters WSP = SP / HTAB ; White space SP = %d32 ; Space HTAB = %d9 ; Horizontal tab DIGIT = %d48-57 ; 0-9 ALPHA = %d65-90 / %d97-122 ; A-Z / a-z ; Document Structure dwd-document = *metadata-record truth-table-section ; Line Ending (Unix-style preferred, Windows accepted) line-ending = LF / CRLF ; Metadata Records metadata-record = PIPE metadata-key PIPE field-value PIPE line-ending metadata-key = key-segment *("." key-segment) key-segment = 1*(ALPHA / DIGIT / "_" / "-") / array-index array-index = 1*DIGIT ; 1-based indexing ; Truth Table Section truth-table-section = column-header *row-header *truth-value-row column-header = PIPE "INDEX" PIPE "DATA" *column-number PIPE line-ending column-number = PIPE 1*DIGIT row-header = PIPE row-id PIPE row-label *column-reference PIPE line-ending row-id = world-id / key-id world-id = "W" 1*DIGIT *("." 1*DIGIT) key-id = "K" 1*DIGIT *("." 1*DIGIT) row-label = 1*VCHAR column-reference = PIPE 1*DIGIT Potvin & Langlois Expires 12 August 2026 [Page 14] Internet-Draft DWD-PSF February 2026 truth-value-row = PIPE truth-id PIPE truth-value PIPE column-index PIPE line-ending truth-id = "T_" world-id "_" world-id "_" world-id truth-value = "00" / "01" / "10" / "11" column-index = 1*DIGIT ; Coordinates Format (KVc) coordinates-row = PIPE coords-id PIPE coords-label *column-number PIPE line-ending coords-id = value-id / key-id value-id = "V_" key-id *("_" key-id) ; Field Values field-value = *safe-char safe-char = VCHAR / WSP / UTF8-char UTF8-char = %x80-FF ; UTF-8 multibyte sequences ; Reserved Identifiers reserved-id = "INDEX" / "DATA" / "W" 1*DIGIT / "K" 1*DIGIT / "V_" / "T_" 8.2. Field Value Constraints Metadata Field Value Constraints: +=========================+======================================+ | Field | Constraints | +=========================+======================================+ | rule_id | UUID format [RFC4122] | +-------------------------+--------------------------------------+ | ruledata_version | Semantic Versioning (SemVer 2.0.0) | +-------------------------+--------------------------------------+ | version_standard_url | Valid URL [RFC3986] | +-------------------------+--------------------------------------+ | properties.id | UUID format | +-------------------------+--------------------------------------+ | metadata.rule.url | Valid URL | +-------------------------+--------------------------------------+ | linked_rules_or_lookups | JSON array format or empty [RFC8259] | +-------------------------+--------------------------------------+ Table 5 UUID Format: UUIDs MUST conform to RFC 4122 format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Where x is a hexadecimal digit (0-9, a-f, A-F). Potvin & Langlois Expires 12 August 2026 [Page 15] Internet-Draft DWD-PSF February 2026 Semantic Versioning: Versions MUST follow SemVer 2.0.0 format: MAJOR.MINOR.PATCH 9. Examples 9.1. Complete Example The following example demonstrates a complete DWD document with both metadata and truth table sections. |rule_id|933e80c7-72d8-4990-8445-97ea6799322d| |rulereserve_nodes|*| |version_standard_url|https://semver.org/| |ruledata_version|0.0.0| |properties.id|933e80c7-72d8-4990-8445-97ea6799322d| |metadata.rule.120_title|Test Rule| |metadata.rule.240_summary|Example summary text| |metadata.rule.960_explanation|Detailed explanation of rule logic| |metadata.rule.rule_group|test-group| |metadata.rule.rule_criticality|experimental| |metadata.rule.url|https://example.com/rule| |metadata.rule.rulemaker_manager.1.name|John Doe| |metadata.rule.rulemaker_manager.1.email|john@example.com| |linked_rules_or_lookups|[]| |in_effect.1.country|US| |in_effect.1.subcountry|US-CA| |in_effect.1.timezone|2025-07-07T11:49:51-05:00| |INDEX|DATA|1|2|3|4|5| |W1|COLUMNHEADER|1|2|3|4|5| |W1.1|A|1|2|3|4|5| |W1.2|B|6|7|8|9|10| |W2|Function|1|2|3|4|5| |W2.1|Input Condition|1|2|3|| |W2.2|Output Assertion||4|5|| |W3|Expression|1|2|3|4|5| |W3.1|{"noun":"test"}|1|2||4|5| |T_W1.1_W2.1_W3.1|01|1| |T_W1.2_W2.1_W3.1|00|2| |T_W1.1_W2.2_W3.1|01|4| 9.2. Metadata Only Example A DWD document containing only metadata: Potvin & Langlois Expires 12 August 2026 [Page 16] Internet-Draft DWD-PSF February 2026 |rule_id|a1b2c3d4-e5f6-7890-abcd-ef1234567890| |ruledata_version|1.0.0| |version_standard_url|https://semver.org/| |properties.id|a1b2c3d4-e5f6-7890-abcd-ef1234567890| |metadata.rule.120_title|Simple Rule| |metadata.rule.240_summary|A rule with only metadata| 10. Security Considerations This section discusses security considerations when processing DWD documents. 10.1. Input Validation Parsers MUST validate input to prevent: * Buffer overflow attacks via excessively long lines * Memory exhaustion via deeply nested structures * Injection attacks through field values Implementations SHOULD enforce reasonable limits on: * Maximum line length (recommended: 10,000 characters) * Maximum number of fields per line (recommended: 10,000) * Maximum file size (recommended: 100 MB) * Maximum nesting depth for metadata keys (recommended: 10 levels) 10.2. Field Value Sanitization Field values MAY contain arbitrary text including: * HTML/XML markup * JSON data structures * SQL fragments * Script code Applications processing DWD documents MUST NOT execute field values as code without proper sanitization and validation. Potvin & Langlois Expires 12 August 2026 [Page 17] Internet-Draft DWD-PSF February 2026 10.3. External References Metadata fields such as "url" and "version_standard_url" contain external references. Applications SHOULD: * Validate URL schemes (allow only http, https) * Implement timeouts for external resource fetching * Cache external resources to prevent repeated requests * Not automatically dereference URLs without user consent 10.4. Privacy Considerations DWD documents may contain personally identifiable information (PII) in metadata fields such as: * Rule maker names and email addresses * Organization-specific identifiers * Jurisdictional information Implementations SHOULD: * Allow redaction or anonymization of PII fields * Implement access controls for sensitive rule documents * Log access to documents containing PII 11. IANA Considerations This document has no IANA actions. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, . Potvin & Langlois Expires 12 August 2026 [Page 18] Internet-Draft DWD-PSF February 2026 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, . [SemVer] Preston-Werner, T., "Semantic Versioning 2.0.0", June 2013, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . Appendix A. Acknowledgments The authors would like to thank the Xalgorithms Foundation and all contributors to the Data With Direction Specification. Special thanks to Wayne Cunneyworth for pioneering Table Driven Design, and to all members of the Xalgorithms Alliance who have contributed to the development and refinement of the DWD format. Potvin & Langlois Expires 12 August 2026 [Page 19] Internet-Draft DWD-PSF February 2026 Appendix B. Appendix A. Comparison with Related Formats This appendix provides a non-normative comparison between DWD pipe- separated format and similar data formats. B.1. CSV (Comma-Separated Values) +=============+==================+=======================+ | Aspect | CSV | DWD Pipe-Separated | +=============+==================+=======================+ | Delimiter | Comma (,) | Pipe (|) | +-------------+------------------+-----------------------+ | Quoting | Double quotes | No quoting required | +-------------+------------------+-----------------------+ | Header row | Single header | Multiple header types | +-------------+------------------+-----------------------+ | Metadata | Not standardized | Native support | +-------------+------------------+-----------------------+ | Nested data | Flat structure | Dot notation support | +-------------+------------------+-----------------------+ Table 6 B.2. TSV (Tab-Separated Values) Similar to CSV but uses tab characters as delimiters. DWD format differs by using visible pipe characters and supporting structured metadata alongside tabular data. B.3. JSON JSON provides hierarchical data representation but lacks the human- editable tabular format of DWD. DWD truth tables can be converted to JSON arrays, and DWD documents often have equivalent JSON representations. Appendix C. Appendix B. Implementation Guidelines C.1. Parsing Strategy Implementations are RECOMMENDED to use a two-pass parsing approach: 1. First pass: Identify line types (metadata vs. truth table) 2. Second pass: Parse fields according to line type Potvin & Langlois Expires 12 August 2026 [Page 20] Internet-Draft DWD-PSF February 2026 C.2. Error Handling Parsers SHOULD provide detailed error information including: * Line number where error occurred * Type of error (syntax, validation, constraint violation) * Suggested correction if applicable C.3. Round-Trip Preservation Implementations SHOULD preserve the following when reading and writing DWD documents: * Field order within records * Whitespace within field values * Presence or absence of optional fields * Comment lines (if supported) Authors' Addresses Joseph Potvin Xalgorithms Foundation Email: jpotvin@xalgorithms.org Charles Langlois Xalgorithms Foundation Email: dwds@charleslanglois.dev Potvin & Langlois Expires 12 August 2026 [Page 21]