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|[email protected]|

   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|[email protected]|

   |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,

              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO

              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November

              2003, <https://www.rfc-editor.org/info/rfc3629>.

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,

              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally

              Unique IDentifier (UUID) URN Namespace", RFC 4122,

              DOI 10.17487/RFC4122, July 2005,

              <https://www.rfc-editor.org/info/rfc4122>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax

              Specifications: ABNF", STD 68, RFC 5234,

              DOI 10.17487/RFC5234, January 2008,

              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,

              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

12.2.  Informative References

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,

              DOI 10.17487/RFC5322, October 2008,

              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC4287]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom

              Syndication Format", RFC 4287, DOI 10.17487/RFC4287,

              December 2005, <https://www.rfc-editor.org/info/rfc4287>.

   [SemVer]   Preston-Werner, T., "Semantic Versioning 2.0.0", June

              2013, <https://semver.org/spec/v2.0.0.html>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data

              Interchange Format", STD 90, RFC 8259,

              DOI 10.17487/RFC8259, December 2017,

              <https://www.rfc-editor.org/info/rfc8259>.

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: [email protected]

   Charles Langlois

   Xalgorithms Foundation

   Email: [email protected]

Potvin & Langlois        Expires 12 August 2026                [Page 21]