Style Name Notation (SNN) Specification

Version: 1.0.0
Author: Cyril Kato
Published: July 11, 2025
License: Open Web Foundation Agreement 1.0

1. Status of this document

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as normative requirements.

Capitalized terms (Game, Rule System, Piece Style, Player Style, Match) are defined in the Glossary and the Game Protocol. This document does not redefine those terms.

2. Overview

Style Name Notation (SNN) provides a human-readable naming system for game styles (values of Piece Style in the Sashité Game Protocol) used in abstract strategy board games.

SNN serves as a primitive building block in the Sashité ecosystem, using PascalCase names with optional numeric suffixes to identify movement traditions or game variants.

As a foundational primitive, SNN is self-contained and rule-agnostic:

it does not encode movement rules or victory conditions,
it does not encode player sides or ownership,
it does not depend on any particular Game or Rule System.

Core concept: Each SNN name is a PascalCase identifier that represents a Piece Style.

3. Dependencies

None. SNN is a foundational notation and does not depend on other Sashité specifications.

4. Scope

4.1 What SNN defines

SNN defines:

a set of valid strings usable as Piece Style identifiers,
a structural format (PascalCase with optional numeric suffix),
validation rules for those strings.

4.2 What SNN does not define

SNN is deliberately syntax-only. It does not define:

which style names are canonical or reserved,
any mapping between style names and movement rules,
any relationship between Piece Style and Player Style,
any game-specific semantics.

All semantic meaning belongs to Rule Systems, not to SNN.

5. Format specification

5.1 Structure

An SNN token is a PascalCase name with optional numeric suffix:

begins with exactly one uppercase letter (A–Z),
followed by zero or more letters (A–Z, a–z),
followed by zero or more digits (0–9).

<uppercase-letter><letters><digits>

5.2 Grammar (BNF)

<snn> ::= <uppercase-letter> <letter>* <digit>*

<uppercase-letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I"
                     | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R"
                     | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

<letter> ::= <uppercase-letter> | <lowercase-letter>

<lowercase-letter> ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i"
                     | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r"
                     | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

5.3 Regular expression

^[A-Z][A-Za-z]*[0-9]*$

Anchoring requirement (normative): Implementations MUST validate SNN tokens using a full-string match (not a substring search). No leading or trailing characters (including whitespace) may be ignored or trimmed. Implementations MUST reject any input containing line breaks (\r or \n) and MUST NOT enable multiline anchoring modes that change the meaning of ^ and $.

Case requirement (normative): Implementations MUST use case-sensitive matching and MUST NOT enable any case-folding or case-insensitive mode.

6. Validation rules

A string is a valid SNN token if and only if:

ASCII-only and case-sensitive — The token MUST use only ASCII characters from the sets A–Z, a–z, and 0–9. Implementations MUST treat lowercase and uppercase as distinct and MUST NOT apply Unicode normalization or case folding.
Starts with uppercase — The first character MUST be an uppercase letter (A–Z).
Letter body — All characters following the initial uppercase and before any digits MUST be letters (A–Z, a–z).
Numeric suffix — Digits (0–9) MAY only appear at the end of the name, after all letters.
No special characters — Only ASCII letters and digits are allowed. No hyphens, underscores, spaces, or other characters.
Non-empty — The name MUST contain at least one character (the initial uppercase letter).

7. Valid and invalid examples

7.1 Valid SNN tokens

Token	Description
`Chess`	Standard style name
`Shogi`	Standard style name
`Xiangqi`	Standard style name
`Makruk`	Standard style name
`Chess960`	Style name with numeric suffix
`Shogi2`	Style name with numeric suffix
`A`	Minimal valid token (single uppercase letter)
`XY123`	Two letters followed by digits

7.2 Invalid SNN tokens

String	Reason
`""`	Empty string
`chess`	Starts with lowercase instead of uppercase
`1Chess`	Starts with digit instead of uppercase letter
`Chess-960`	Contains hyphen (special character not allowed)
`Chess_Variant`	Contains underscore (special character not allowed)
`Chess 960`	Contains space (special character not allowed)
`Chess960A`	Letter after digits (digits must be at the end)
`CHESS`	Valid but unconventional (all uppercase)

8. Design principles

As a foundational primitive, SNN follows these principles:

Human-readable format — Names are easy to read and communicate.
Self-contained — SNN can be validated syntactically without external tables; semantics are supplied by the context.
Direct association — Each name is associated directly with a Piece Style in a given context.
Universal applicability — SNN is suitable for any abstract strategy game that uses the Sashité notion of Piece Style.
Deterministic usage — Within a given context, a given SNN name SHOULD consistently refer to the same Piece Style.

9. Style assignment

Within a specific Game, Rule System, or engine:

Direct assignment — Each SNN name is assigned to a Piece Style.
Contextual meaning — The exact meaning of each style (board geometry, movement rules, etc.) is defined by the Rule System, not by SNN.
Canonical usage — In a given context, each SNN name SHOULD be used consistently for the same Piece Style.

10. Usage within the Game Protocol

Within the Game Protocol:

An SNN token typically identifies a Piece Style or Player Style.
The protocol treats Style as a mutable Piece attribute and a fixed Player attribute.
SNN provides the naming convention; the Rule System defines the semantic interpretation.

The Game Protocol may stipulate that Style values are identified by SNN tokens. Rule Systems define:

which SNN tokens are valid for a given Game,
what movement patterns each Style implies,
whether Piece Style must match Player Style,
how Style affects game mechanics.

11. Design properties

SNN is intended to be:

Human-readable — PascalCase names that are easy to display and understand.
Rule-agnostic — Independent of concrete movement rules or victory conditions.
Side-agnostic — Does not encode player sides or ownership.
Minimal — Simple structural rules with alphanumeric identifiers.
Foundational — Suitable as a naming layer for Piece Styles across the ecosystem.
Context-flexible — Adaptable to many games and style families.

12. Reference implementations

The following reference libraries are maintained by Sashité and are intended to be idiomatic, fully tested, and spec-accurate implementations of SNN v1.0.0.

They generally provide:

strict parsing and validation (valid?, parse, and a raising/bang variant),
clear error reporting for invalid inputs.

If a library behavior appears to conflict with this document, this specification is normative. Please report issues (or propose clarifications) on the relevant repository.

Elixir — snn.ex
Ruby — snn.rb

13. License

This specification is made available under the terms of the Open Web Foundation Agreement 1.0 (OWFa 1.0).

The authoritative legal text is the OWF “Final Specification Agreement (OWFa 1.0)”.