On Wed, May 08, 2002 at 06:28:50PM -0700, Brian Ingerson wrote:
| The above paragraph triggers redflag thoughts though. Could someone explain
| this in detail. Why do we need to store type family in the native model? Do
| you mean explicitly, or implied? Would it be exposed or opaque to the
| application? I'm confused.
Our wording above was bad. The native model will be
worded so that anything is allowed (opaque as a native
binding would be) as long as it it has an "image" in
the graph model, complete with the constraints of
the graph model.
| - We distinguish between map and sequence at the graph model.
| - We simplify the verbage.
| - We don't put constraints on the native model.
| - We target Ytools at the graph model.
Yep. Only that we have the kind/family compatibility constraint.
| I've been working on the new API for libyaml. Interesting... It turns out
| that the same work required by application to define dumping opaque to graph,
| is exactly the layer needed to support Ytools at the native model. I guess
| that is obvious now that I realize it.
| I've even figured out how to round trip things like key order in a YNY
| scenario. Interesting stuff.a
Well, this would mean that your application is working at the
"tree" or "syntax" model, and not with the graph model. It's
ok to round-trip key order; but the graph model does not (obviously)
require this. ;)
| Also, Neil and I were discussing (over coffee) (good to be in Vancouver :)
| that the same node structure created by the parser is the very argument
| that you want to pass to a graph-to-native transform. Only it would have an
| associated class for accessing things like kind, family and content.
Right. The yaml_node_t structure will be shared between the
sequential-access API and a random-access API. ;)
| At that point it makes me wonder (again) why family must imply kind...
It depends how you think of YAML. If you consider YAML as just
a serialization language; then the compatibility constraint does
not seem obviously needed. And, I'd rather you think of it as
a constraint on a document rather than "family implies kind",
since "family implies kind" gives the wrong API idea...
The constraint is needed so that one can uniquely 'identify'
nodes of a particular kind using the family URI irrespective
of the kind and/or format. Without this constraint, this isn't
possible and then the "type" of the node becomes a tuple
(family,kind) which is much harder to work with. Thus, to make
the generic model more "useable" this constraint is needed.
Basically, 99.9% of user data expressable won't violate the
constraint; but the data that does is just "invalid YAML". This
is needed since it keeps the YAML specific tools simpler... that
is, it can consider "family *is* the node's type", rather than
"family is only one factor in the node's type... let me check
the other part, kind".
I hope this helps! In short, the constraint isn't obvious from the
API (and it may even be a bit counter intuitive) but it is needed
to have a clean YAML toolset, and it happens to fit the common
data patterns (despite a slightly less pretty syntax).