### Debug Xeto Environment Setup

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto.tools/Setup.md

Running 'xeto version' with specific environment configurations displays detailed information about the Xeto setup, including the detected work directory, home directory, install directory, and the effective search path for libraries.

```bash
/work/acme-lib> xeto version

...

xeto.version:    3.1.12
xeto.mode:       xeto.props
xeto.workDir:    /work/acme-libs
xeto.homeDir:    /work/haxall-home
xeto.installDir: /work/acme-libs
xeto.path:
  /work/acme-libs
  /work/project-libs
  /work/global-libs
  /work/haxall-home

```

--------------------------------

### Haxall CLI Tool Installation and Usage for Xeto

Source: https://context7.com/project-haystack/xeto/llms.txt

Provides commands for installing and using the Haxall CLI tool, which is used for working with Xeto libraries and specs. Installation can be done via npm for NodeJS or by downloading a JAR for Java. Commands for verifying installation and understanding environment configuration are also included.

```bash
# Install via npm (NodeJS)
npm i -g @haxall/haxall

# Install via Java
# Download from https://github.com/haxall/haxall/releases

# Verify installation
xeto version

# Example output:
xeto.version:    3.1.12
xeto.mode:       xeto.props
xeto.workDir:    /work/acme-libs
xeto.homeDir:    /work/haxall-home
xeto.path:
  /work/acme-libs
  /work/project-libs
  /work/haxall-home

# Environment configuration (xeto.props)
# path=/work/project-libs;/work/global-libs

# Library search paths:
# {dir}/src/xeto/{lib-name}/   - source files
# {dir}/lib/xeto/{lib-name}/   - compiled xetolib files

# Directory structure for library "acme.assets":
# src/xeto/
#   acme.assets/
#     lib.xeto        # pragma file (required)
#     specs.xeto      # type definitions
#     instances.xeto  # instance data

```

--------------------------------

### Xeto Version Constraint Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Libs.md

Provides practical examples of version constraints in Xeto, demonstrating exact version matching, wildcard usage for major/minor versions, and version range specifications.

```xeto
1.2.3         // version 1.2.3 exact
1.2.x         // any version that starts with "1.2."
3.x.x         // any version that starts with "3."
x.x.x         // any version - wildcard match
1.0.0-2.0.0   // range from 1.0.0 to 2.0.0 inclusive
1.2.0-1.3.x   // range from 1.2.0 to 1.3.* inclusive
```

--------------------------------

### Xeto Naming Conventions Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Specs.md

Provides examples of simple and qualified names for specs and slots in Xeto, illustrating the '::' separator for qualified names and '.' for slot names.

```xeto
Str                         // simple name
sys::Str                    // qualified name
NaturalGasMeter             // simple name
ph.equips::NaturalGasMeter  // qualified name
```

```xeto
LibDepend: Dict {
  lib: Str                      // qname is sys::LibDepend.lib
  versions: LibDependVersions   // qname is sys::LibDepend.versions
}
```

--------------------------------

### Xetodoc Table Formatting Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Xetodoc.md

Demonstrates the syntax for creating tables in xetodoc, adhering to the GitHub Flavored Markdown table extension format.

```markdown
| foo | bar |
| --- | --- |
| baz | qux |
```

--------------------------------

### Xetodoc Embedded YouTube Video Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Xetodoc.md

Shows how to embed a YouTube video using the image syntax with a 'video://' URI scheme. The example includes a placeholder for the iframe title and the specific YouTube video ID and session information.

```markdown
![iframe title](video://youtu.be/fr-K-MVbAa8?si=dnJTcLsVdzfUfE7T)
```

--------------------------------

### Xeto List Specification Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Specs.md

Demonstrates the definition and usage of lists in Xeto, including parameterizing the item type with 'of' meta and showing instance data examples.

```xeto
Foo: {
  numbers: List <of:Number>  // List that contains only Numbers
}
```

```xeto
// explicitly typed list with individual items typed
@foo-1: Foo {
  numbers: List <of:Number> { Number 2, Number 3, Number 4}
}

// items are implicitly typed as Number from the 'of'
@foo-2: Foo {
  numbers: List <of:Number> { 2, 3, 4}
}

// typed list is inferred from Foo.numbers slot definition
@foo-3: Foo {
  numbers: { 2, 3, 4}
}
```

```xeto
// This will not compile
MyNumbersList: List <of:Number>
```

--------------------------------

### Creating Floor and Room Instances in Xeto

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Instances.md

Provides an example of creating instances for a floor and a room in Xeto, demonstrating cross-referencing using relative IDs and the automatic addition of implied tags from specs.

```xeto
@floor-2: Floor {
  dis: "Floor 2"
}

@room-204: Room {
  dis: "Room 204"
  spaceRef: @floor-2
}
```

--------------------------------

### Verify Xeto Installation (Java)

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto.tools/Setup.md

This command verifies the installation of Xeto when installed for the Java environment. It checks if the 'xeto' executable is in the system's PATH and reports its version.

```shell
bin/xeto version
```

--------------------------------

### Xeto Name Resolution Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Namespaces.md

Illustrates the four different flavors of names used for referencing definitions in Xeto: fully qualified spec names (qnames), simple spec names, fully qualified instance identifiers, and simple instance identifiers. These examples show the syntax for each type.

```xeto
ph.points::AirTempSensor  // spec qname
AirTempSensor             // spec simple name
@ph::filetype:json        // qname instance id
@filetype:json            // simple instance id
```

--------------------------------

### Verify Xeto Installation (NodeJS)

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto.tools/Setup.md

This command verifies the installation of Xeto when installed for the NodeJS environment. It checks if the globally installed 'xeto' command is accessible and reports its version.

```shell
xeto version
```

--------------------------------

### Configure Xeto Environment Path

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto.tools/Setup.md

This example shows how to configure additional directories for Xeto to search for libraries. The 'path' property in 'xeto.props' accepts a semicolon-separated list of directories.

```properties
path=/work/project-libs;/work/global-libs
```

--------------------------------

### Install Xeto for NodeJS using npm

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto.tools/Setup.md

This command installs the '@haxall/haxall' package globally using npm, which is the standard package manager for NodeJS. It ensures the Xeto command-line tools are available on the system.

```bash
npm i -g @haxall/haxall
```

--------------------------------

### Xeto Lib Pragma Metadata Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Libs.md

A template for the 'lib.xeto' file, defining library metadata such as documentation, version, dependencies, and organization information using the pragma directive.

```xeto
pragma: Lib <
  doc: "Summary of the lib goes here"
  version: "2.0.6"
  depends: {
    { lib: "sys", versions: "1.0.x" }
    { lib: "foo.bar", versions "2.x.x" }
  }
  org: {
    dis: "Acme, Inc"
    uri: "https://acme.com/"
  }
>
```

--------------------------------

### Xetodoc Shortcut Link Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Xetodoc.md

Illustrates various ways to create links within xetodoc markdown, including absolute links to library elements, relative links within a library or chapter, and direct section anchors.

```markdown
---
--- Absolute Links ---
[ph.points::index]           Library index
[sys::Str]                   Spec type via qname
[sys::Spec.doc]              Spec slot via qname
[lib::my-instance]           Instance via qname
[doc.xeto::Xetodoc]          Markdown chapter via qname
[doc.xeto::Xetodoc#tables]   Markdown chapter via qname
[readAll()]                  Unqualified func name in namespace
[hx::readAll()               Qualilfied func name within namespace

--- Lib Relative Links ---
[Str]                        Spec type name in lib or its depends
[Lib.version]                Spec slot dotted name in lib or its depends
[Readme]                     Markdown chapter section anchor name without .md ext
[Readme.md]                  Markdown chapter name with .md ext
[Readme#section]             Markdown chapter section anchor without .md ext
[Readme.md#section]          Markdown chapter section anchor with .md ext

--- Chapter Relative Links ---
[#section]                   Section anchor within the markdown chapter
---
```

--------------------------------

### Xeto Dict Specification Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Specs.md

Shows how to define dictionary specifications in Xeto, including nested slots and default values for slots using the 'val' meta or syntax sugar.

```xeto
Point: Dict {
  x: Int
  y: Int
}
```

```xeto
Point: Dict {
  x: Int <val:"-99">
  y: Int <val:"-99">
}

// syntax sugar for same
Point: Dict {
  x: Int "-99"
  y: Int "-99"
}
```

--------------------------------

### Xeto Scalar Specification Examples

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Specs.md

Illustrates how to define scalar specifications in Xeto, including basic definitions, metadata like default values ('val') and regular expressions ('pattern').

```xeto
// meta data
MyScalar: Scalar <val:"default">

// syntax sugar for same
MyScalar: Scalar "default"
```

```xeto
Date: Scalar <sealed, pattern:"\\d{4}-\\d{2}-\\d{2}"> "2000-01-01"
```

--------------------------------

### Xeto Spec Definition Syntax Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Specs.md

Demonstrates the basic syntax for defining Xeto specifications, including scalars, dicts, and metadata. Scalars and list subtypes cannot define slots.

```xeto
SpecName: BaseType <meta1, meta2> {
  slotA: Type <slotMeta1, slotMeta2>
}
```

```xeto
// simple scalar
MyScalar: Scalar

// scalar with metadata
SocialSecurityNumber: Scalar <pattern:"\\d{3}-\\d{2}-\\d{4}">

// simple dict type
Point: Dict {
  x: Int
  y: Int
}

// dict with metadata
Person: Dict <sealed, icon:"user"> {
  name: Str
  height: Number <quantity:"length", minVal:0>
}
```

--------------------------------

### Xeto Global Spec Syntax Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Globals.md

Demonstrates the basic syntax for defining a global member in Xeto, using a leading asterisk to denote a global tag. It shows how this syntax is equivalent to explicitly adding the '<global>' meta tag.

```xeto
MyType: {
  *globalTag: Type <meta1, meta2> "default"
}

MyType: {
  globalTag: Type <global, meta1, meta2> "default"
}
```

--------------------------------

### Xeto Lib Directory Structure

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Libs.md

Example of the required directory structure for a Xeto library. The directory name defines the lib name, and 'lib.xeto' is mandatory for metadata.

```xeto
  src/xeto/
    acme.assets/      // directory name determines lib name
      lib.xeto        // must have a pragma file with this name
      specs.xeto      // additional definitions
```

--------------------------------

### Instance Definition with ID in Xeto

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Instances.md

Demonstrates how to define an instance within a Xeto library, where the 'id' is formed from the qualified name (qname). The 'id' must be a Ref value and cannot start with an uppercase letter.

```xeto
// instance in lib acme.widgets; id is @acme.widgets::sku-123
@sku-123: Part {...}
```

--------------------------------

### Xetodoc Table of Contents Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Xetodoc.md

Defines the structure and order of markdown chapters for a library's documentation. It uses h1 headings for section titles and lists of links to specify chapter names and their summaries.

```markdown
# Section Heading 1

- [Foo](Foo.md): summary of Foo
- [Bar](bar.md): summary of Bar

# Seciton Heading 2

- [Baz](Baz.md): summary of Baz
- [Qux](Qux.md): summary of Qux
```

--------------------------------

### Xeto Spec and Instance Export to JSON and RDF/SHACL

Source: https://context7.com/project-haystack/xeto/llms.txt

Demonstrates how Xeto specifications and instances can be exported to JSON Schema and RDF/SHACL formats. This enables interoperability with other systems by providing structured data representations. The examples show the Xeto spec, its JSON representation, a valid JSON instance, and an RDF/SHACL export.

```xeto
// Xeto spec
Person: Dict <sealed, icon:"user"> {
  name: Str  // Full name
}

// JSON representation of spec
{
  "id": "acme::Person",
  "spec": "sys::Spec",
  "base": "sys::Dict",
  "sealed": "marker",
  "icon": "user",
  "slots": {
    "name": {
      "id": "acme::Person.name",
      "spec": "sys::Spec",
      "type": "sys::Str",
      "doc": "Full name"
    }
  }
}

// JSON instance validation
// Valid JSON that conforms to User spec:
{ "username": "bob", "created": "2025-12-08" }

// RDF/SHACL export example
// acme:Person
//   a rdfs:Class ;
//   a sh:NodeShape ;
//   rdfs:subClassOf sys:Dict ;
//   sh:targetClass acme:Person ;
//   sh:property [
//     sh:path acme:Person.name ;
//     sh:datatype xsd:string ;
//   ]

```

--------------------------------

### Combine spec meta, slot meta, and new slots in a Xeto mixin

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Mixins.md

This example combines adding spec-level metadata (icon), slot-level metadata (icon for 'age'), and a new extended slot ('orgRef') to an existing Xeto spec definition.

```xeto
+Person <icon:"user"> {
  age: <icon:"calendar">
  orgRef: Ref <of:Org>
}
```

--------------------------------

### Parameterized Types with 'of' in Xeto

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/TypeSystem.md

Shows the use of the 'of' meta in Xeto to parameterize container and reference types like List, Ref, MultiRef, and Query. This example specifically demonstrates parameterizing a List.

```xeto
Foo: {
  list: List<of:Number>
}

Bar: Foo {
  list: List<of:Duration>
}
```

--------------------------------

### Project Haystack PhEntity Globals Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Globals.md

Demonstrates how Project Haystack uses globals to enforce consistent tag usage across all entity types. The 'PhEntity' base type defines globals like '*area' and '*battery' with specific types and metadata, ensuring these tags are used consistently throughout the ontology.

```xeto
PhEntity: Entity {
  // Area of a shape or floor space
  *area: Number <quantity:"area">

  // Equipment used to store electric energy
  *battery: Marker

  ...
}
```

--------------------------------

### Instance Spec Declaration in Xeto and Haystack

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Instances.md

Illustrates how instances declare their type spec. In Xeto, the 'spec' tag is often implied by name resolution. Examples show Xeto, Haystack, and JSON object representations.

```xeto
// Xeto instance - spec is ph::ElecMeter via name resolution
@meter-1: ElecMeter {...}
```

```haystack
id: @meter-1
spec: @ph::ElecMeter
```

```json
{
  "id": "meter-1",
  "spec": "ph::ElecMeter"
}
```

--------------------------------

### Enforce Required Color Choice on Car Entity

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Choices.md

This example shows how to apply the 'Color' choice to a 'Car' entity, making the color property required. It illustrates valid and invalid instances based on the 'Color' choice constraints, where exactly one color marker must be present.

```xeto
// color is required
Car: {
  color: Color
}

// instances
Car {red}         // valid
Car {}            // invalid, color is required
Car {red, blue}   // invalid, red and blue are mutually exclusive
```

--------------------------------

### Define Scalar Types in Xeto

Source: https://context7.com/project-haystack/xeto/llms.txt

Demonstrates defining atomic scalar types in Xeto, including basic scalars, scalars with pattern validation (regex), and scalars with default values using meta syntax or sugar syntax. It also shows valid and invalid instance examples.

```xeto
// Simple scalar with no constraints
MyScalar: Scalar

// Scalar with regex pattern validation
SocialSecurityNumber: Scalar <pattern:"\\d{3}-\\d{2}-\\d{4}">

// Scalar with default value using meta syntax
MyScalar: Scalar <val:"default">

// Syntax sugar for default value
MyScalar: Scalar "default"

// Example: Date scalar with pattern and default
Date: Scalar <sealed, pattern:"\\d{4}-\\d{2}-\\d{2}"> "2000-01-01"

// Username with alphanumeric constraint
Username: Scalar <pattern:"^[a-zA-Z0-9]+$">

// Valid instance
@valid-user: { ssn: SocialSecurityNumber "123-45-6789" }

// Invalid - pattern mismatch (will fail validation)
@invalid-user: { ssn: SocialSecurityNumber "123456789" }
```

--------------------------------

### Define Multi-Choice Color Property for Car

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Choices.md

This example demonstrates how to define a 'color' property for a 'Car' entity that allows multiple selections from the 'Color' choice. The '<multiChoice>' marker is used to indicate that an entity can have zero or more of the specified color markers, while still enforcing that at least one must be present if the property is defined.

```xeto
// color is required multi choice
Car: {
  color: Color <multiChoice>
}

// instances
Car {red}          // valid
Car {}             // invalid, at least one color is required
Car {red, blue}    // valid
```

--------------------------------

### Define Choice Types for Mutually Exclusive Markers in Xeto

Source: https://context7.com/project-haystack/xeto/llms.txt

Illustrates the definition and usage of choice types in Xeto, which represent mutually exclusive marker tags. It covers required, optional, and multi-choice scenarios, along with examples of valid and invalid instances, and the concept of sealed choices.

```xeto
// Define a choice taxonomy
Color: Choice
Red: Color { red }
Green: Color { green }
Blue: Color { blue }

// Required choice - exactly one must be present
Car: Dict {
  color: Color
}

// Optional choice - zero or one
Vehicle: Dict {
  color: Color?
}

// Multi-choice - one or more allowed
Artwork: Dict {
  colors: Color <multiChoice>
}

// Valid instances
@redCar: Car { red }              // Valid
@plainVehicle: Vehicle { }         // Valid (optional)
@mixedArt: Artwork { red, blue }   // Valid (multiChoice)

// Invalid instances (would fail validation)
// Car { }                         // Error: color required
// Car { red, blue }               // Error: mutually exclusive

// Sealed choice (cannot be extended outside lib)
Status: Choice <sealed>
Active: Status { active }
Inactive: Status { inactive }
```

--------------------------------

### Xeto Spec Definition Example

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Specs.md

An example of a Xeto spec definition for a 'Person' type. This demonstrates the basic structure of defining a dictionary type with slots.

```xeto
// Xeto spec example
Person: Dict <sealed, icon:"user"> {
  name: Str  // Full name
}
```

--------------------------------

### Define Libraries with Versioning and Dependencies in Xeto (Pragma)

Source: https://context7.com/project-haystack/xeto/llms.txt

Explains how to define libraries in Xeto using the `pragma: Lib` directive. This includes specifying library documentation, versioning, dependencies on other libraries with version constraints, and organization information. It also outlines library naming conventions.

```xeto
// lib.xeto - Library metadata file
pragma: Lib <
  doc: "My custom library for building automation"
  version: "1.2.3"
  depends: {
    { lib: "sys", versions: "5.0.x" }
    { lib: "ph", versions: "5.x.x" }
  }
  org: {
    dis: "Acme Corporation"
    uri: "https://acme.com/"
  }
>

// Version constraint examples:
// "1.2.3"         - exact version
// "1.2.x"         - any 1.2.* version
// "3.x.x"         - any 3.* version
// "x.x.x"         - any version
// "1.0.0-2.0.0"   - range inclusive

// Library naming conventions:
// sys             - core system types
// ph              - Project Haystack ontology
// com.acme        - organization with DNS acme.com
// cc.vendor       - community contribution for vendor
```

--------------------------------

### Define Typed Lists and Collections in Xeto

Source: https://context7.com/project-haystack/xeto/llms.txt

Demonstrates how to define lists with specific item types (Number, Str) or as untyped collections in Xeto. It also shows how to create list instances with explicit or inferred typing and apply constraints like nonEmpty or size ranges.

```xeto
// Slot with typed list
Foo: Dict {
  numbers: List <of:Number>    // List containing only Numbers
  names: List <of:Str>         // List containing only Strings
  items: List                  // Untyped list (any items)
}

// List instance data with explicit typing
@foo-1: Foo {
  numbers: List <of:Number> { Number 2, Number 3, Number 4 }
}

// Items implicitly typed from 'of'
@foo-2: Foo {
  numbers: List <of:Number> { 2, 3, 4 }
}

// Type inferred from slot definition
@foo-3: Foo {
  numbers: { 2, 3, 4 }  // Inferred as List<of:Number>
}

// List constraints
Config: Dict {
  tags: List <nonEmpty>                    // Must have at least one item
  options: List <minSize:2, maxSize:5>     // Size constraints
}
```

--------------------------------

### Xeto Fixed Value Constraint: fixed

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Constraints.md

Enforces a specific, unchanging value for a slot. Any instance using this slot must provide the exact fixed value. The example demonstrates a 'unit' slot that must always be '%'.

```xeto
Foo: {
  // requires all instances to use the fixed value "%"
  unit: Unit <fixed> "%"
}

// Slot 'unit': Must have fixed value '%'
@a: Foo {unit:"meter"}

```

--------------------------------

### Xeto Instance Syntax

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Instances.md

Shows the syntax for defining instances within a Xeto library. Slot tags can be separated by newlines or commas. Marker values can be used when the value is omitted.

```xeto
// separate slot tags with newline
@id: TypeSpec {
  slotA: valA
  slotB: valB
  ...
}
```

```xeto
// or separate slot tags with comma
@id: TypeSpec {
  slotA: valA, slotB: valB, slot: valC
  ...
}
```

```xeto
// the value can be omitted if it is a marker
@id: TypeSpec {
  markerA, markerB
}
```

--------------------------------

### Validate Xeto Lib Names

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Libs.md

Illustrates valid and invalid naming conventions for Xeto libraries. Names must adhere to specific character sets, dot separation rules, and starting character requirements for each segment.

```xeto
foo         // ok
foo.bar     // ok
foo.bar_13  // ok
foo!bar     // error - invalid char "!"
foo.7bar    // error - dotted sections must start with lowercase
foo_.bar    // error - underbar may not be adjacent to dot
foo__bar    // error - underbar may not be adjacent to another underbar
foo.barBaz  // error - only lower case ASCII letters permitted
```

--------------------------------

### Define Xeto Instances with Project Haystack

Source: https://context7.com/project-haystack/xeto/llms.txt

Demonstrates defining instances in Xeto, which are data objects conforming to spec definitions. Instances have an 'id' tag and reference their type via 'spec'. It covers simple definitions, references to other instances, nested instances with slot names, and auto-generated slot names. Also includes a JSON representation of an instance.

```xeto
// Instance definitions in a lib
@floor-2: Floor {
  dis: "Floor 2"
}

@room-204: Room {
  dis: "Room 204"
  spaceRef: @floor-2              // Reference to another instance
}

// Nested instances with slot names
@toolbar: Toolbar {
  save: Button { text: "Save" }
  exit: Button { text: "Exit" }
}

// Nested instances with ids
@toolbar: Toolbar {
  save @save-btn: Button { text: "Save" }
  exit @exit-btn: Button { text: "Exit" }
}

// Auto-generated slot names with ids
@toolbar: Toolbar {
  @save-btn: Button { text: "Save" }   // Slot name auto-generated as _0
  @exit-btn: Button { text: "Exit" }   // Slot name auto-generated as _1
}

// JSON representation of instance
{
  "id": "acme::room-204",
  "spec": "ph::Room",
  "dis": "Room 204",
  "spaceRef": "acme::floor-2",
  "space": "marker",
  "room": "marker"
}
```

--------------------------------

### Xeto Global Spec for Person Height

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Globals.md

An example of a global spec defining the 'height' for a 'Person' type, requiring it to be a Number with a 'length' quantity and a minimum value of 0. This global enforces consistency for the 'height' slot across all subtypes of 'Person'.

```xeto
Person: {
  *height: Number <quantity:"length", minVal:0>
}
```

--------------------------------

### Define Spec and Lib Meta Tags with Mixins (Xeto)

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Meta.md

Demonstrates how to define new meta tags for specs and libraries using mixins in Xeto. New meta tags are declared as slots on the `sys::Spec` and `sys::Lib` types, allowing for custom annotations and metadata.

```xeto
+Spec {
  // new spec meta tag
  specMetaTag: Type <meta, moreMeta>
}

+Lib {
  // new lib meta tag
  libMetaTag: Type <meta, moreMeta>
}
```

--------------------------------

### Xeto Scalar Constraint: pattern (regex)

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Constraints.md

Allows scalar types to be constrained by a regular expression pattern applied to their string encoding. This is useful for validating formats like Social Security Numbers. The example shows a valid SSN format and an invalid one.

```xeto
SocialSecurityNumber: Scalar <pattern:"\\d{3}-\\d{2}-\\d{4}">

// ok
@a: {ssn: SocialSecurityNumber "123-43-5678"}

// String encoding does not match pattern for 'acme::SocialSecurityNumber'
@b: {ssn: SocialSecurityNumber "123435678"}

```

--------------------------------

### Xeto Number Constraints: minVal, maxVal, unit, quantity

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Constraints.md

Constrains numerical values by specifying minimum and maximum allowed values, required units, or the quantity associated with a unit. Examples demonstrate validation of percentage values, power units, and temperature units.

```xeto
Foo: {
  percent: Number <minVal: 0, maxVal: 100, unit:"%"
  powerVal: Number <quantity:"power">
}

// Slot 'percent': Number 50°C must have unit of '%'
@a: Foo { percent:50°C, powerVal:70kW }

// Slot 'percent': Number 200% > maxVal 100
@b: Foo { percent:200%, powerVal:70kW }

// Slot 'power': Number must be 'power' unit; '°C' has quantity of 'temperature'
@c: Foo { percent:50%, powerVal:70°C }

```

--------------------------------

### Export Xeto User Spec to RDF

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Intro.md

This RDF Turtle syntax outlines how the Xeto 'User' specification can be exported as an RDFS class and SHACL NodeShape. It defines properties and constraints for the User class.

```turtle
  acme:User
  a rdfs:Class ;
  a sh:NodeShape ;
  rdfs:subClassOf sys:Dict ;
  rdfs:label "User"@en ;
  sh:targetClass acme:User ;
  sh:property [
    sh:path acme:User.username ;

  ...
```

--------------------------------

### Define Dict Types (Objects) in Xeto

Source: https://context7.com/project-haystack/xeto/llms.txt

Illustrates the definition of dictionary (object) types in Xeto, which are compound types composed of named slots with explicit value types. Examples include simple dicts, dicts with metadata, and dicts with default values.

```xeto
// Simple dict with typed slots
Point: Dict {
  x: Int
  y: Int
}

// Dict with metadata and documentation
Person: Dict <sealed, icon:"user"> {
  name: Str                              // Required string field
  email: Str?                            // Optional field (maybe type)
  height: Number <quantity:"length", minVal:0>  // Constrained number
  created: Date                          // Required date
}

// Dict with default values
Config: Dict {
  timeout: Int <val:"30">               // Default using meta
  retries: Int "3"                       // Default using syntax sugar
  enabled: Bool "true"
}

// User account with nested type constraint
User: Dict <sealed> {
  username: Username  // Uses custom Username scalar type
  created: Date
  email: Str?
}
```

--------------------------------

### Xeto Covariance Example: Widening List 'of' Type (Error)

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/TypeSystem.md

This Xeto code illustrates an invalid covariance scenario. The subtype 'Bar' attempts to widen the 'of' type of the list beyond the supertype 'Foo's contract, resulting in a compile-time error.

```xeto
Foo: {
  list: List<of:Number>
}

Bar: Foo {
  list: List<of:Obj>
}
```

--------------------------------

### Declaring Optional Fields with Xeto

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/TypeSystem.md

Demonstrates how to declare optional fields (maybe types) in Xeto using both standard and shorthand syntax. Optional fields allow instances to omit values for these slots.

```xeto
// standard syntax for optional age field
age: Number <maybe>

// syntax sugar for above
age: Number?
```

--------------------------------

### Xeto String Constraints: minVal, maxVal, nonEmpty

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Constraints.md

Validates string values based on length and content. Constraints include minimum and maximum string lengths and a requirement for strings to contain non-whitespace characters. Examples show validation of empty names and phone numbers with incorrect lengths.

```xeto
Foo: {
  name: Str <nonEmpty>
  phone: Str <minVal: 7, maxVal:10>
}

// Slot 'name': String must be non-empty
@a: Foo { name:"", phone:"5551234" }

//  Slot 'phoneNum': String size 3 < minSize 7
@b: Foo { name:"Bob", phone:"555" }

// Slot 'phoneNum': String size 11 > maxSize 10
@c: Foo { name:"Bob", phone:"21255512345" }

```

--------------------------------

### Haystack Representation of Xeto Instances

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Instances.md

Shows the Haystack dictionary representation of the Xeto floor and room instances, including the resolved qnames and implied marker tags like 'space' and 'floor'/'room'.

```haystack
id: @acme::floor-2
spec: @ph::Floor
dis: "Floor 2"
space
floor
---
id: @acme::room-204
spec: @ph::Room
spaceRef: @acme::floor-2
space
room
```

--------------------------------

### Define Optional Color Choice with Maybe Type

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Choices.md

This snippet illustrates how to define an optional 'Color' choice for a 'Car' entity using the 'maybe' type modifier. This allows the color property to have zero or one selection from the defined 'Color' markers. It includes examples of valid and invalid instances.

```xeto
// color is required
Car: {
  color: Color?
}

// instances
Car {red}          // valid
Car {}             // valid, color is maybe type
Car {red, blue}    // invalid, red and blue are mutually exclusive
```

--------------------------------

### Xeto List Constraints: minSize, maxSize, nonEmpty

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Constraints.md

Enforces constraints on list types, including the minimum and maximum number of items allowed and whether the list must contain at least one item. Examples illustrate validation for empty lists and lists with incorrect item counts.

```xeto
Foo: {
  listA: List <nonEmpty>
  listB: List <minSize:2, maxSize:3>
}

// Slot 'listA': List must be non-empty
@a: Foo { listA:{}, listB:{"a", "b"}}

// Slot 'listB': List size 1 < minSize 2
@b: Foo { listA:{"x"}, listB:{"a"}}

// Slot 'listB': List size 4 > maxSize 3
@c: Foo { listA:{"x"}, listB:{"a", "b", "c", "d"}}

```

--------------------------------

### Define Optional Fields (Maybe Types) in Xeto

Source: https://context7.com/project-haystack/xeto/llms.txt

Demonstrates how to define optional fields in Xeto using either the '?' suffix or the '<maybe>' metadata. It also shows how optional types can be narrowed to required types through covariance.

```xeto
// Optional fields using ? syntax
Person: Dict {
  name: Str          // Required
  email: Str?        // Optional (maybe type)
  phone: Str?        // Optional
}

// Equivalent using meta syntax
Person: Dict {
  name: Str
  email: Str <maybe>
  phone: Str <maybe>
}

// Valid instances
@person1: Person { name: "Alice", email: "alice@example.com" }
@person2: Person { name: "Bob" }  // email and phone omitted - valid

// Covariance: maybe can be removed (narrowing)
OptionalAge: Dict { age: Number? }
RequiredAge: OptionalAge { age: Number }  // Valid narrowing
```

--------------------------------

### Compile Xeto User Spec to JSON

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Intro.md

This JSON output represents the 'User' Xeto specification, detailing its structure, base type, sealed status, and slot definitions including types, optionality, and documentation.

```json
{
  "id": "acme::User",
  "base": "sys::Dict",
  "sealed": "✓",
  "slots": {
    "username": {
      "type": "acme::Username",
      "doc": "required string field"
    },
    "created": {
      "type": "sys::Date",
      "doc": "required date field"
    },
    "email": {
      "type": "sys::Str",
      "maybe": "✓",
      "doc": "optional string field"
    }
  }
}
```

--------------------------------

### Define User and Username Specs in Xeto

Source: https://github.com/project-haystack/xeto/blob/master/src/xeto/doc.xeto/Intro.md

This Xeto code defines a 'User' dictionary type with required and optional fields, and a 'Username' scalar type with a pattern constraint. It demonstrates defining data types, metadata, and comments.

```xeto
// User account object
User: Dict <sealed> {
  username: Username  // required string field with constraints
  created: Date       // required date field
  email: Str?         // optional string field
}

Username: Scalar <pattern:" ^[a-zA-Z0-9]+$.">
```