Skip to content
This repository was archived by the owner on May 20, 2026. It is now read-only.

Schema Divisions

trans edited this page Jul 14, 2011 · 2 revisions

Schema Sections

2011-07-12

Thinking about the overall design of Yes, I am very satisifed by it's simplicity and yet it's broad capability. However it still feels lacking in few impotrant ways.

First, I have not yet figured out how to "apply" a schema to document by type. This is imporant if we wish to load up a number of schemas together and apply them to a stream of incoming documents.

Secondly, reusable fragments of the schema must be defined on first use. In other words, there is no sepearate "scratchpad" section to draw upon that is not part of the schema itself. While this is a feature that could be forgone, it still might be nice to have.

Third, most YAML fomats that need a schema have a simple well defined mapping structure, almost all of which could be easily defined by a rather static template document --complex node constraints are not really needed.

Taking these altogether, this gives me the notion of creating a multi-part schema consisting of four division: HEADER, FRAGMENT, TEMPLATE and CONSTRAINTS.

    ---
    HEADER-DIVISION:
      apply-tag: "!foo.org/example"
      author: trans <transfire@gmail.com>

    FRAGMENT-DIVISION:
      - &req-c
        type: map
        requires: [name]

    TEMPLATE-DIVISION:
      name: PIC X[30]
      version: REX semver; DEF "0.0.1"
      requirements:
        - name: PIC X[30]
          version: REX semver; REQ true

    CONSTRAINT-DIVISION:
      requirements:
        value: &req-c

The nice thing about this design, as opposed to just utilizing constraints to define the entire schema, is that the template gives us a very easy to understand "snapshot" of what the format will look like. And it provides a quick way to define the basic constraints of type and values. In many cases the template will define all, if not most, the schema.

Clone this wiki locally