On Tuesday 21 October 2003 12:13 am, Robin G. wrote:
> On Mon, 20 Oct 2003, Sean O'Dell wrote:
> > I just don't see why it has to be that complicated. The programmers who
> > look at YAML for their needs already understand scalar, arrays and
> > hashes. Why not just say "this is a set of strings, arrays and hashes?"
> We are looking for one simple word to use for what used to be called a
> "document" in the spec.
Why? Use document.
> > I must have been under a rock for in my 20 years of programming then =) ;
> > I've never heard any programmers use graph for anything except to show
> > visually the relationship between related values.
> Right, this is a good point. If we do end up using the word graph for
> what used to be called "document", maybe we should make this distinction
> clear somewhere in the spec, e.g.
Sometimes you cannot avoid having to define your terms elsewhere, such as a
glossary. But for something so fundamental? I wouldn't think so.
> ... graph (i.e. a network of nodes and vertices) ...
> Pedants note: I'm using "network" in a tautologous way there, but I think
> it helps because it has visual connotations.
You made me look up "tautologous!" Now you have to do the same thing ... I do
not think it means what you think it means. =)
> Normally it is not considered necessary to define elementary
> theoretical words before using them, but in this case we could perhaps
> make an exception because of the potential confusion with "that other kind
> of graph".
That's why I think YAML shouldn't use "graph." If you have to have a whole
thing where you explain why you're using a certain term and what it means
exactly, it's the wrong term in the first place. The meaning of the term
should become apparent immediately in a brief explanation. Look at these two
To provide interoperability between various languages, platforms,
and applications, this specification defines an abstraction called
a YAML graph. A YAML graph models native data structures of
modern programming languages, including strings, arrays, hashes,
and user-defined types.
This means virtually nothing unless you've spent a lot of time in the
yaml-core mailing list or you have someone willing to stop and spend a couple
minutes explaining to you what a graph is.
A YAML "node" models native data structures common to modern
programming languages, such as strings, arrays, associative
hashes, and user-defined data types. YAML nodes are grouped into
"sets" which may arrange nodes according to a particular specification
This is much clearer and easier to grasp, I think.
> I mean, the XML spec isn't very readable for the average programmer.
> There's no reason why, as we've got a reasonably simple, easy-to-read
> serialization language here, why we can't make the spec easier to read
> than the XML spec - it's not a high bar to cross!
The spec isn't easy to read, but public-consumption introductions to XML are.
When it comes time to submit something to W3C, sure ... pack it with
terminology that only lawyers can understand. For now, be practical.
> > Data grouped in a YAML document are not necessarily related in any way
> > except that they belong in the document.
> True, if the YAML document is just a flat list.
> If it is more than just a flat list, then child nodes are related to their
But not in any meaningful way; they're just collected that way. I am related
to my father; the relationship is meaningful. If node a is a child of node
A, it is related to a, but not in a meaningful way.
> In either case, consider the document as a node in its own right, and
> all other nodes are then related to their parents. So, you have a network
> of relationships (in fact, a tree, if you don't use aliases), and this we
> call a graph.
I'm just trying to keep things above-board with this. It seems like you guys
don't get a whole lot of public feedback here and are producing these terms
with very little input, and little, if any, from anyone with actual
experience developing standards. I think YAML has the potential to be a
serious, widely-accepted format, and I just don't want to see something so
easily modified now end up staying and turning away developers because its
too hard to grasp or because they, like me, think the terms are on the silly
Here, let me show you something:
I am building a brick wall.
I am assembling a concert of masonic elements into a protective barrier.
Which is easier to understand? Why did I use the word "concert?" Well,
because a concert, in music, is an arrangement of musicians playing a musical
composition in a unified way which a single listener can listen to and
appreciate fully. In this way, a brick wall is an arrangement of bricks
adhered together in a unified way which provides a barrier that a single
trespasser may not pass.
The use of the word "concert" above is childishly contrived; deliberately so.
I can make the analogy between "concert" and "brick wall," but it seems more
creative than practical.
The term "graph" is like that to my eyes and ears. It seems far more
creatively contrived than practically.
> > If they *are* related, then their
> > relationship is defined above the YAML level.
> The semantics of the relationships expressed by the representation are
> defined at a higher level, sure. But all we are talking about here is
> structural relationships, which derive entirely from syntax.
Exactly; and the relationships are not meaningful. You only graph meaningful
data, and the data itself is not the graph. Here is meaningful data:
Daily average high temperatures for a week
Rads sampled once an hour for 2 days
This is arbitrary data:
Names of people riding the subway today
Total number of gallons of water used in a house last week
The arrangement of mah-jong tiles after a complete game
Data in a set of YAML nodes are not meaningfully related to each other, unless
so dictated by a specification above the YAML level, and therefore they
cannot, in any way, be thought of as a graph. Further, a graph would be the
analysis of the data set, not the data set itself.
If no one agrees, I'll let you folks run with the terms you've chosen and let
it go. I think what I've said can stand without further iteration.