At 04:53 PM 8/2/2001 -0400, Clark C . Evans wrote:
Why? Beacuse I'm serializing to/from a database
all of the time, and my database already has
primary keys that are *data* and must be part
of the information stream. Yet, I'd like to
use these keys for YAML reference linking...
Thought #1: You are awesome!
Thought #2: Ugh, please no!
Thought #3: But I really need it!
Thought #4: Sometimes I'll want the keys to be data and accessible to the
application, in which case I don't get a graph. Sometimes I'll want
it all hidden from me, in which case I get just the graph.
Thought #153: I'm inclined to solve this problem transparently through
the (de)serializer. The (de)serializer would use type information
to decide how to (de)serialize a table record. One type might be
TabularRecord and another TabularNode. The schema for TabularNode
would know that a particular column holds a key that serves as a
reference, while the schema for TabularRecord wouldn't assert this (as in
the default case).
Hence, the (de)serializer decides whether to take advantage of YAML's
One strange consequence of this implementation is that table names would
actually serialize as type names. A table would be a typed but
unnamed list. Maybe this isn't so strange, since this is exactly
how a database is structured: tables are classes of instances, not
Well, now I firmly understand why YAML must support type