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

Coordinate Encoding for Layered Locations (CELL) 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 (Board, Square, Location, Game Protocol, Rule System) are defined in the Glossary and are not redefined here.

2. Overview

Coordinate Encoding for Layered Locations (CELL) defines a standardized ASCII format for encoding protocol-level Location identifiers on multi-dimensional Boards.

A CELL string is a concatenation of dimensions, each using a specific character set in a fixed cycle:

Dimension Character set Examples
1st, 4th, 7th… Lowercase letters (a–z) a, e, aa, file
2nd, 5th, 8th… Positive integers 1, 8, 10, 256
3rd, 6th, 9th… Uppercase letters (A–Z) A, C, AA, LAYER

Common examples:

Note (informative): Some traditions use other coordinate encodings and scripts (e.g. shogi-style 9九). Such strings are not valid CELL coordinates and MUST be mapped to valid CELL coordinates by a Rule System or conversion layer before validation.

3. Dependencies

None. CELL is a foundational primitive with no dependencies on other Sashité specifications.

4. Scope

4.1 What CELL defines

CELL defines:

4.2 What CELL does not define

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

All geometric and ordering semantics belong to Rule Systems, not to CELL or the Game Protocol.

5. Format specification

5.1 Dimensional structure

A CELL string encodes a Location as one or more consecutive dimensions:

<dim-1>[<dim-2>[<dim-3>[...]]]

The character set for dimension n (where n ≥ 1) follows this cycle:

Condition Character set
n % 3 = 1 Lowercase Latin letters (a–z)
n % 3 = 2 Strictly positive integers (1, 2, …, 10, 11, …)
n % 3 = 0 Uppercase Latin letters (A–Z)

A CELL string MAY end after any complete dimension (1D, 2D, 3D, etc.).

5.2 Dimensional patterns

Dimensions Pattern Examples
1D <lower> a, e, file
2D <lower><integer> a1, e4, aa10
3D <lower><integer><upper> a1A, e4B
4D <lower><integer><upper><lower> a1Ab, e4Bc
5D <lower><integer><upper><lower><integer> a1Ab2

The semantic meaning of each dimension (file, rank, layer, etc.) is defined by Rule Systems, not by CELL.

6. Grammar

6.1 BNF

<cell> ::= <latin-lower> <tail₁>

<tail₁> ::= ε
          | <arabic-numeral> <tail₂>

<tail₂> ::= ε
          | <latin-upper> <tail₃>

<tail₃> ::= ε
          | <latin-lower> <tail₁>

<latin-lower>    ::= <latin-lower-char>+
<latin-upper>    ::= <latin-upper-char>+
<arabic-numeral> ::= <positive-integer>

<latin-lower-char> ::= "a" | "b" | ... | "z"
<latin-upper-char> ::= "A" | "B" | ... | "Z"
<positive-integer> ::= <non-zero-digit> <digit>*
<non-zero-digit>   ::= "1" | "2" | ... | "9"
<digit>            ::= "0" | "1" | ... | "9"

6.2 Regular expression

^[a-z]+(?:[1-9][0-9]*[A-Z]+[a-z]+)*(?:[1-9][0-9]*[A-Z]*)?$

Anchoring requirement (normative): Implementations MUST validate CELL coordinates 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 CELL coordinate if and only if:

  1. ASCII-only and case-sensitive — The coordinate 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 lowercase — The first dimension consists of one or more lowercase letters.

  3. Follows the cycle — Each subsequent dimension uses the next character set in the lowercase → integer → uppercase cycle.

  4. Positive integers only — Numeric dimensions are strictly positive (1, 2, …) with no leading zeros.

  5. No mixed characters — Each dimension contains only characters from its assigned set.

  6. No skipped dimensions — Dimensions progress sequentially (e.g., no jumping from lowercase directly to uppercase).

8. Invalid coordinate examples

String Reason
"" Empty string: missing initial lowercase dimension
1 Starts with digit instead of lowercase
A Starts with uppercase instead of lowercase
a0 Zero is not a valid positive integer
a01 Leading zero in numeric dimension
aA Missing numeric dimension between lowercase and uppercase
a1a Missing uppercase dimension between numeric and lowercase
a1A1 Cannot place a numeric dimension after an uppercase dimension without restarting the cycle with a lowercase dimension
1a Starts with digit instead of lowercase

9. Usage within the Game Protocol

Within the Game Protocol:

The Game Protocol may stipulate that Board Locations are identified by CELL strings. Rule Systems define:

10. Examples

See CELL Examples for practical implementation guidance across various Board geometries.

11. Reference implementations

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

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.

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