On Thu, May 02, 2002 at 12:43:58PM -0700, Brian Ingerson wrote:
| Whoa!! When did we drop the distinction from the graph model?
This was battered back and forth quite a bit in the December
time frame... the question comes down to if keyed vs series is
"sugar" or if it must be preserved during round-trips. It must
be one way or the other, but *not both*. Take these examples:
--- !seq ---
0: one - one
1: two - two
| - Parser hands a map and a transfer (!seq) to the Loader. Loader is free
| to load this any way that makes sense to the language. In Perl I'd
| load it as an array.
Given this directive, it appears that the examples above are
different in the tree model (output of parser and input to the
loader). This reflects the current distinction in Neil's API
Now, the question is, does the distinction exist in the graph
(native) model? If both of the two above result in the same
native binding, then the answer should be no. Thus, they are
distinct up-to, but _not_ including the graph model.
So. Let us assume that this is our choice. The distinction
is _not_ in the graph model, but is merely a syntax/tree issue.
Now imagine a programming language Y with two sorts of arrays,
SparseArrays and ContiguousArrays. Let us further imagine that
the implementer got "clever" and decided to use the distinction
between "keyed" and "series" in his loading process, such that
the first example (keyed) was loaded into a SparseArray and the
second example (series) was loaded into a ContigousArray.
Now. This binding is illegal if the distinction is not in the graph
model. Why? Beacuse it will not round-trip with the perl binding
which properly does not rely upon the distinction.
| Brian Quinlan has suggested he'd do something slightly
| different for Python.
As long as he follows the model we agree upon, this is fine.
However, if his binding uses information which is not in the
graph model, then his binding is _not_ YAML.
| Quite frankly, I don't think we need to define the graph model as
| strictly as we do the syntax model. Just have some guidelines and keep
| the implementors talking to each other.
Why we need the graph model that details what information
in a serialization can be stored, and, in particular what
should not be stored. If we leave it up to each implementer,
then some will do it one way, and others will do it a different
way, and then making a common toolset or data storage layer or
transformation toolset, or schema language, will be _much_ harder.
| As long as processes adhere to our syntax model, they should be able to
| do whatever they want internally. YAML is a serialization format.
This perspective is what has caused XML land no end of grief
and the reason why we've spent so much time working on the
information model. YAML should only be able to represent
what is expressable via the graph model, nothing more or less.
The syntax model is there for various "sugar" that we all like,
but should not find themselves as "content".
You didn't get my point about YPATH. I was trying to say that
YPATH is defined at the graph model. Quite clearly, we will have
to have a manner in which nodes of a particular "family" can be
identified in YPATH since family is part of the graph model. For
example, one may only want to select "!int" nodes of a given child.
As a coutner example, since format is _not_ in the graph model,
YPATH will not be able to select nodes based on "hex" or "dec"
formats, and thus a way to filter by format will not be a part
of YPATH. So. To get to the nitty-gritty. Does YPATH need
a way to distinguish between "keyed" and "series" nodes? If so,
then this distinction is part of the graph model; otherwise it
To belabor the point, if we want to chooose SparseArray vs
ContiguousArray based on "keyed" vs "series" in the syntax, then
YPATH must include a manner to choose one over the other; and further,
your perl implementation must be able to tell me which array came
from which syntax, "keyed" or "series". We cannot afford to let one
languge binding do it one way, and another langauge binding do it
a different way... this is the whole point why we have the graph model.
| YPATH is only for XMLish applications anyway. Not for YAML in general.
| (ie how do you do nested keys in YPATH, etc...)
The need for expressing a location within a structure is rather
universal requirement. Obviously our YPATH will have to handle
nested keys, so there will be some differences.
Now, let's get back to the e-mail which set me off...
- !perl/Foo::Bar 
# instead of
This may _look_ nice but what you've done is implicitly move the
distinction between the keyed and series node into the graph model.
If we want to do it this way, then we can't treat this distinction
as syntax sugar, that is, the first example that I lead with _must_
be different after loading. The !seq created by a series must be
different from a !seq created by a keyed construct.
This is _very_ important to get right. It will lead to nasty
interoperability bugs if we let any loader do as they please.
So? Which is it? I say the distinction stays out of the graph model.