Style Identifier Notation (SIN) 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, Match, Side, Style, Player, Player Style, Player Side, etc.) are defined in the Glossary and are not redefined here.

2. Overview

Style Identifier Notation (SIN) is a compact, ASCII-only token format used to encode a Player Identity: the tuple (Player Side, Player Style).

A SIN token encodes exactly two attributes:

Player Style → a single-letter abbreviation chosen by the Game or Rule System,
Player Side → the case of that letter (uppercase / lowercase).

Since both Player Style and Player Side are fixed for the duration of a Match, a SIN token provides a stable, unambiguous Player identifier.

SIN is designed as a minimal building block that can be embedded in higher-level notations.

2.1 Scope

SIN defines only:

the syntax of a token,
and how its characters map to the two Player attributes above.

2.2 Non-goals

SIN does not define:

which Styles exist in a given Game,
how Pieces with a given Style move or behave,
what the Style names mean in human-readable form,
any mapping between Style letters and specific rule families,
any notion of legality, movement patterns, or Game outcomes.

Those belong to the Rule System.

3. Dependencies

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

4. Token format

4.1 Structure

A SIN token is:

<abbr>

Where <abbr> is exactly one ASCII letter (A–Z or a–z), serving as a single-letter abbreviation of the Player Style.

4.2 Grammar (EBNF)

sin  ::= abbr ;
abbr ::= "A"…"Z" | "a"…"z" ;

4.3 Regular expression

A SIN token MUST match the following regular expression, anchored to the whole string:

^[A-Za-z]$

Anchoring requirement (normative):

Implementations MUST ensure the anchors apply to the entire input string, not to individual lines.
If the target regex engine interprets ^ and $ as line anchors under a multiline mode, implementations MUST disable that mode or use the engine’s “string anchors” equivalents to preserve whole-string matching.
Implementations MUST reject any input containing line breaks (\r or \n).

Notes for implementers:

Tokens are case-sensitive.
Producers and consumers SHOULD treat any surrounding whitespace as invalid for a token (whitespace handling, if any, belongs to the surrounding container format, not to SIN itself).

5. Attribute mapping

A conforming implementation MUST interpret a valid token as follows.

5.1 Player Style (via abbreviation)

The <abbr> letter serves as a single-letter abbreviation of the Player Style, assigned by convention within a Game or Rule System.

The letter’s case is used to encode Player Side (see §5.2), but the identity of the abbreviation is case-insensitive: C and c represent the same Style abbreviation, differing only in which Player Side is associated.

SIN does not reserve or predefine any letters. The assignment of letters to Styles is context-dependent and defined by the Rule System or application.

5.2 Player Side

The case of <abbr> encodes Player Side:

uppercase (A–Z) → Player Side first,
lowercase (a–z) → Player Side second.

This aligns with the two-Side model defined in the Glossary.

6. Parsing and conformance requirements

6.1 Validity

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

it matches the grammar in §4.2 (or the regex in §4.3),
it contains exactly one character,
and contains no extra characters (no whitespace, separators, or surrounding quotes as part of the token).

Implementations:

MUST reject invalid tokens,
SHOULD provide a non-raising validity predicate (e.g., valid?),
MAY provide a raising/bang parser variant.

6.2 Canonical form

SIN tokens are already canonical by construction:

exactly one ASCII letter as abbreviation,
no prefixes or suffixes.

Implementations MUST NOT reorder or normalize tokens beyond strict validation.

6.3 Component extraction

Implementations SHOULD provide accessors for each component:

Accessor	Description
`abbr`	The single-letter abbreviation (always uppercase for comparison)
`side`	`first` or `second`

6.4 Invalid token examples

String	Reason
`""`	Empty string
`CC`	More than one character
`c1`	Contains a digit
`+C`	Contains a prefix character
`C^`	Contains a suffix character
` C`	Leading whitespace
`C`	Trailing whitespace
`1`	Digit instead of letter
`é`	Non-ASCII character

7. Design constraints and considerations

7.1 Character space

SIN provides 26 base letters (A–Z and a–z) as abbreviations.

When Player Side is encoded via case, a context may use up to 52 distinct tokens (2 Sides × 26 abbreviations).

7.2 Two-Side assumption

SIN encodes exactly two Player Sides (first/second) using case.

Games with more than two Sides MUST use a convention outside the scope of SIN or use a different notation designed for multi-Side encoding.

7.3 Abbreviation conventions

Since Player Style is represented by a single-letter abbreviation, a Rule System SHOULD:

keep the mapping from abbreviation to full Style name stable and unambiguous within a given Game context,
document which abbreviations correspond to which Styles.

7.4 Match-level stability

Because both Player Style and Player Side are fixed for the duration of a Match, a SIN token represents a stable identifier that does not change as the Game progresses.

This stability makes SIN suitable for:

identifying which Player performs an Action,
labeling Player-specific resources (e.g., Hands),
embedding in higher-level notations that require unambiguous Player references.

8. Examples

See SIN Examples for practical implementation guidance across various Game contexts.

9. Reference implementations

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

They generally provide:

strict parsing and validation (valid?, parse, and a raising/bang variant),
round-trip serialization (string ⇄ structured identifier),
component extraction (abbr, side),
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 — sin.ex
Ruby — sin.rb

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