Andrew Kurn wrote:
>>libs
>> - foo.so
>> - version - 1.2
>> - date - 2002-05-05
>> - bar.so
>> - version - 3.4
>>
>
> Second, foo.so and bar.so, to me are vertex labels, so it's
> not a pure graph, but a labeled graph. Third, *version* and
> *date* are edge labels, an important distinction, because
> to a man reading this tree, it's important to notice that
> there can only be a single vertex at the end of a "version"
> edge.
In the example, '-' are really edges. We can assume that it
is a directed labeled graph. But not a tree, since I can
link any two nodes with an anchor/alias pair. The way I see
this example is as in the first figure, g1.png.
This is perhaps too general, and we can use one special 'value'
node, as in g2.png. This does not convert the structure into
a tree, but also implies that any node can have a 'value'
node attached to it, even if in a tree representation this would
lead to an 'inconsistent' node (a node that has both value and
subnodes). That influences the query language, but that's ok
for me. Value nodes could be represented by the '=' operator,
for example:
libs
- foo.so
- version = 1.2
- date = 2002-05-05
- bar.so
- version = 3.4
But, again, '1.2' is a node (vertex).
We should not forget the origin of this discussion: schema
evolution. I want to have a list of libraries (as a string
array, for example), independently of the fact that each
library has attributes/subnodes or not. In the directed graph
example, schema evolution is natural. Well, the query expression
language would need to be adapted in some form, in order to be
able to return a list of node names or a node list or a value.
> Uh . . . I mean, yes, as you say, it's an "attribute", which
> again is a restriction on tree, an important one from the
> man-machine point of view. Yes, the general idea of labeled
> graph contains all the YAML sentences (using the terminology
> of formal languages), but it's too general and contains a lot
> of other stuff besides.
Besides the fact that this is not YAML anymore, what are the
concrete problems with this approach ?
> I might propose, as you might, specific simplifications
> to the current grammar, which is pretty big, never fear,
> but pushing it all the way back to labeled graph is just
> too, too far.
My problem is that I like the YAML idea, but I do have a
node structure below :-) (One that preserves order).
Obviously you can argue that this is not the purpose of YAML.
Yes, but it is the only format I've found that is close to my idea
and has a serious specification.
I'll continue to support the YAML format as per the spec,
in the form of a Java parser. But since I'll have a parser, I
can and will experiment with simplified production sets. That
has also to do with the fact that I'm kind of 'frontier blind':
I cannot see a clear distinction between map and list when
trying to represent events and facts from the real world.
Regards.
Rolf.
|