You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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-ctype: maprequires: [name]TEMPLATE-DIVISION:
name: PIC X[30]version: REX semver; DEF "0.0.1"requirements:
- name: PIC X[30]version: REX semver; REQ trueCONSTRAINT-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.