-
Notifications
You must be signed in to change notification settings - Fork 3
Schema Divisions
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-cThe 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.