On Mon, Nov 19, 2001 at 10:18:56AM +0200, Oren BenKiki wrote:
 > A node is the base construct of the YAML information
 > model. For the definition below, both a value and a
 > type family are an ordered set of unicode characters.

 Nope (see below).

 > A node has:
 >  a type family
 >  a value

 Yes. A type family is a mathematical definition of
 the set of values the node can have.
Nice definition of type family.
 > A node pair consists of
 >  a node called "key"
 >  a node called "value"

 Yes.

 > A collection is a node that additionally has:

 >  an unordered (possibly empty) set of
 > node pairs such that the value of
 > the key for each pair is unique
 > within the set.

 This is a type family. Consider:
 The collection type family: value is an unordered...
 The sequence type family: value is a collection with
 restricted keys: (0..n) integers...
 The map type family: value is a collection with arbitrary keys...
 The integer type family: value is (0, 1, 1, ...)
 The real type family: value is ...
 The text type family: value is a sequence of Unicode characters.
 The binary type family: value is a sequence of octets (bytes).
I can see where you are coming from. And this
level of detail is going to be required for
any YPATH expression mechanism. Thus, I
see that the above should make their way
into the information model, no?
That said, I don't think collection is a
type family; well, as much as scalar is.
Let's ask what a core YAML needs to know in
order to construct the serialization loop...
1. It needs to know if the node is a
scalar or a collection
2. If it is a scalar, it needs to know
the scalar's value as a sequence
of characters, and what transfer
method was used.
3. If it is a collection, it needs
to know what transfer method is
needed (so it can recreate the
right collection on load), and
it needs to be able to iterate
over the key/value pairs.
4. Lastly, it must be able to find
out if two nodes are identical
(I missed this one, oops).
All of this type family is well and
good; but it is in another "layer"
of the system. And I think that
the collection vs scalar is the
essence of this layer.
...
That said, I see all of the type
families plugging into the above
modular system which doesn't know
about styls and could care less
about families.
The above layer is only interested
in (a) the transfer method used,
(b) how the node is represented
as a sequence of characters, (c)
if nesting is needed (collection),
and lastly (d) if to nodes are
identical.
 This has nothing to do with transfer methods or node styles. We have a map
 type family, a map node style, and a map transfer encoding (we may also have
 a map class in some languages). The base name is the same but the concepts
 are different  we can clarify this by ensuring we use the full name in
 every place (the map transfer method deserializes a map node style into a
 map class which much satisfy the requirements from the map type family. It
 can also deserialize a scalar node style with the empty value, etc.).
Yes. The distinction is useful.
Ok. I got to catch some zzzz. I'd be
interested in what you think about the diagram..
Clark
