Style Identifier Notation (SIN) Specification
- Version: 1.0.0
- Author: Sashité
- Published: July 11, 2025
- License: MIT License
Overview
Style Identifier Notation (SIN) provides a foundational, compact ASCII format for identifying styles in abstract strategy board games. SIN serves as a primitive building block in the Sashité ecosystem, using a single ASCII letter with case encoding to simultaneously represent style identity and player assignment.
As a foundational primitive, SIN is completely self-contained and provides the minimal viable format for style identification. It does not depend on or derive from any other specifications.
A SIN identifier consists of two semantic components:
- Character (A-Z): Unique style identification within the ASCII alphabet
- Assignment (uppercase/lowercase): Indicates which player uses this style
Terminology
For complete definitions of terms used in this document, see the Glossary.
Dependencies
None. SIN is a foundational primitive with no dependencies.
Format Specification
Structure
<character>
Where <character> is an ASCII letter (A-Z or a-z) representing both style identity and player assignment.
Grammar (BNF)
<sin> ::= <uppercase-letter> | <lowercase-letter>
<uppercase-letter> ::= "A" | "B" | "C" | ... | "Z"
<lowercase-letter> ::= "a" | "b" | "c" | ... | "z"
Regular Expression
\A[A-Za-z]\z
Foundational Design
Primitive Principles
As a foundational primitive, SIN follows these design principles:
- Minimal viable format: Single character provides maximum compactness
- Self-contained: No external dependencies or derivation requirements
- Extensible foundation: Can be extended by more descriptive systems like SNN
- Universal applicability: Works across all abstract strategy game contexts
- Deterministic behavior: Clear, unambiguous identification rules
Character Assignment
SIN characters are assigned directly without derivation from external sources:
- Direct assignment: Characters represent styles through explicit association
- Contextual meaning: The meaning of each character depends on the specific game system or context
- Flexibility: Same character can represent different styles in different contexts
- Canonical usage: Within a specific context, each character should consistently represent the same style
Attribute Encoding
SIN encodes style attributes using this correspondence:
| Attribute | SIN Encoding | Examples |
|---|---|---|
| Character | ASCII letter (A-Z) | C = Chess, S = Shogi, X = Xiangqi |
| Assignment | Letter case | Uppercase = First player, Lowercase = Second player |
Assignment Rules
- Uppercase (
A-Z): Style used by the first player - Lowercase (
a-z): Style used by the second player
Interpretation Examples
| SIN | Style | Assignment | Interpretation |
|---|---|---|---|
C |
Chess | First player | First player uses Chess style |
c |
Chess | Second player | Second player uses Chess style |
O |
Ōgi | First player | First player uses Ōgi style |
o |
Ōgi | Second player | Second player uses Ōgi style |
Relationship with SNN
SIN and SNN are independent primitives that serve complementary roles:
- SIN: Compact, single-character identification
- SNN: Human-readable, descriptive names
Optional Correspondence
While both specifications can be used independently, they may be related through:
- Mapping tables: External context defining SIN ↔ SNN relationships
- Distinguished letters: SNN names containing SIN characters
- Case consistency: When mapped, case must be preserved (
C↔CHESS,c↔chess)
Important Notes
- No dependency: SIN does not depend on SNN, nor SNN on SIN
- Bidirectional mapping requires context: Converting between SIN and SNN requires external mapping information
- Independent usage: Systems may use SIN alone, SNN alone, or both with defined mappings
- Multiple mappings: One SIN character may correspond to multiple SNN names in different contexts
System Constraints
Character Availability
SIN provides 26 possible identifiers for unique styles (A-Z), with case encoding providing player assignment.
Player Limitation
SIN supports exactly two players through case distinction:
- First player: Uppercase letters (
A-Z) - Second player: Lowercase letters (
a-z)
Context Dependency
The meaning of SIN characters depends on context:
- Within a specific game system: Characters should consistently represent the same styles
- Across different systems: Same character may represent different styles
- Implementation responsibility: Systems using SIN must define character-to-style mappings
Design Properties
- ASCII compatibility: Maximum portability across systems
- Rule-agnostic: Independent of specific game mechanics
- Minimal overhead: Single character per style-player combination
- Foundational primitive: Serves as building block for more complex systems
- Extension-ready: Can be enhanced by descriptive naming systems like SNN
- Context-flexible: Adaptable to various style identification needs
Examples
See SIN Examples for practical implementation guidance and cross-style scenarios.
Reference Implementations
Ruby
- SIN.rb – Reference implementation with validation support and extension integration capabilities.