| > | > D. We define that a YAML text A is
| > | > E. For each node N, a synthesized
| > | > F. For the pull (iterator, parser) API, define
| > |
| > | I have had enough coffee to grok these. :)
| > Really? This is a hard concept... but _very_
| > powerful as it allows backward-compatible schema
| > migration _without_ a re-write!
| Sorry. Meant "I haven't had enough coffee to grok these. :)"
Ok. Substituability by example coming up. Let us write
"X > Y" to mean "X is substituable for Y". In other words,
if a program is expecting a YAML text structured like Y, it
will happily accept a YAML text structured like X. Take
the following three YAML texts: A, B, and C.
= : value
added : info
= : @
Here, we have A < B and B < C. Substituability is transitive,
thus A < C as well. Note, that neither A > B, B > C, nor A > C
are true statements.
Why substitutability? This propery is important since it allows
further information to be added to a YAML text without breaking
older software. In other words, it allows for "forward
compatibility", letting old programs handle new data.
How substitutability? For each node, aNode, we introduce
a synthesized attribute, asScalar. aNode.asSclar() is
defined to be:
(a) aNode, if aNode is already a scalar.
(b) aNode.firstChild().asScalar(), if aNode is a list.
(c) aNode.getChild("=").asScalar(), if aNode is a map.
Ok. Let's see how this works on a program *expecting*
a structure just like example A, a single map having
a key "sample". It would do...
This would return the scalar node "value". When this
code is executed on B and C, it returns... guess what?
Yes, a single scalar node, "value".
Thus, the above code, written to accept data structured
like A, can now happily accept data structured like
B or C without _any_ code changes.
This gives programs which are based on YAML that use
the asSclar() synthesized attribute liberally to be
"forward compatible" with "substituable" changes in
the YAML file.
asSclar() can be implemented as a property of
a random access YAML Node, or it could even
be implemented in the parser or emitter interfaces!
P.S. This is what Oren and I mean by "color". This
allows a data file to be "colored" by attributes
recursively as required *without* breaking older