Sashité for Developers
  1. Sashité for Developers
  2. Specifications
  3. SNN
  4. 1.0.0

Style Name Notation (SNN) Specification

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 are not redefined here.

2. Overview

Style Name Notation (SNN) provides a human-readable naming system for Styles (values of Piece Style or Player Style) used in abstract strategy board Games.

SNN uses PascalCase names with optional numeric suffixes to identify movement traditions or Game variants.

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

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

3. Dependencies

SNN is self-contained and has no dependencies on other Sashité specifications.

4. Relationship with SIN

SNN and SIN both identify Styles, but serve different purposes:

Aspect SNN SIN
Format PascalCase name Single letter
Readability Human-readable Machine-compact
Side encoding None Yes (via case)
Use case Documentation, catalogs, UI Notation tokens (QPI, FEEN)

SNN is for contexts where human readability matters (documentation, user interfaces, catalogs).

SIN is for contexts where compactness matters (embedded in QPI tokens, Position notations).

A Rule System or application typically defines a mapping between SNN names and SIN letters:

SNN SIN
Chess C / c
Shogi S / s
Xiangqi X / x
Makruk M / m

5. Scope

5.1 What SNN defines

SNN defines:

5.2 What SNN does not define

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

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

6. Format specification

6.1 Structure

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

<uppercase-letter><letters><digits>

6.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"

6.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.

7. Validation rules

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

  1. 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.

  2. Starts with uppercase — The first character MUST be an uppercase letter (A–Z).

  3. Letter body — All characters following the initial uppercase and before any digits MUST be letters (A–Z, a–z).

  4. Numeric suffix — Digits (0–9) MAY only appear at the end of the name, after all letters.

  5. No special characters — Only ASCII letters and digits are allowed. No hyphens, underscores, spaces, or other characters.

  6. Non-empty — The name MUST contain at least one character (the initial uppercase letter).

8. Valid and invalid examples

8.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

8.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)

9. Design principles

As a foundational primitive, SNN follows these principles:

  1. Human-readable format — Names are easy to read and communicate.

  2. Self-contained — SNN can be validated syntactically without external tables; semantics are supplied by the context.

  3. Direct association — Each name is associated directly with a Style in a given context.

  4. Universal applicability — SNN is suitable for any abstract strategy Game that uses the notion of Style.

  5. Deterministic usage — Within a given context, a given SNN name SHOULD consistently refer to the same Style.

10. Style assignment

Within a specific Game, Rule System, or application:

11. Design properties

SNN is intended to be:

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:

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

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)”.