My take...

1) I don't see the need to get pedantic without a real life problem. So far I haven't seen any real life problems. YAML has always been about treading that delicate line between Humans and Computers, not about pleasing mathematicians.

{a: 1, a: 2} is not a real life problem.

2) This is all about Schema. Thanks for getting to it Kirill. There are not that many real life, Schema Blind things going on with YAML. I think it's a good thing to tell people that:

A) *Technically*, a YAML stream found laying on the street, can mean many different things to many different programs.
B) *Generally*, a simple YAML stream will mean the same thing to all consumers.

Like Perl, simple things simple, hard things possible. The harder the use case, the more heavy-weight the schema.

3) Almost all current YAML applications are Schema Aware. Dump/Load processors, each have their own built in, somewhat language specific, somewhat spec guided, schema. The most important thing, is that they be true to themselves. The less, but also important thing, is to try to play nice with others.

Think of YAML processors as being houses in a neighborhood. Most important is to serve the owners, neighbors come second. If you have to paint your house plaid for religious reasons, do so. But don't do it on a whim, and piss off all your neighbors.

4) I don't think it's a sin for an isolated application, to honor key order and allow duplicate keys. It's just not a social thing to do. At the end of the day, a program works when all its tests pass.


Cheers, Ingy

PS Just an aside, FYI... I don't think it's a declared property of JavaScript, but every JS implementation I've used preserves key order in objects.

On Sun, Nov 29, 2009 at 11:11 AM, Kirill Simonov <> wrote:
Oren Ben-Kiki wrote:
> On Sat, Nov 28, 2009 at 8:55 PM, Osamu TAKEUCHI <
> <>> wrote:
>     I do not find very much importance to keep an arbitrary YAML file to
>     be acceptable to every implementation. Each YAML file must have its
>     own purpose. So, I expect no chance where one would like to feed the
>     YAML file in my example to any YAML implimentation that do not have
>     reference-based object model.
> Well, that's where we differ.
> YAML's goal 2 (portability) has higher priority than goal 3 (matching
> native data structures). That is, wo do see the point in being able to
> create generic "schema-blind" YAML tools, having a well-defined
> consistent YAML data model, and so on. I can see why someone only
> interested in a particular application (or implementation) may disagree;
> someone interested in generic tools and portability would agree. It is a
> matter of priorities; had we flipped the order of the goals, we would
> have had a different set of rules.

I don't think schema-blind tools have any chance to determine whether
two nodes are equal or not.  This is very schema-specific.  Not only two
nodes with different tags could be equal, but also a scalar node could
be equal to a collection node.  Consider, for instance, that in

x: 1.0i
y: { re: 0.0, im: 1.0 }
z: { rho: 1.0, phi: 1.5707963267948966 }

the three nodes 'x', 'y', and 'z' are probably equal.  You don't know
unless you know the schema.  Another example is from my own application,
where nodes

db1: postgres://localhost:5432/mydb
db2: mydb
db3: { engine: postgres, host: localhost, port: 5432, database: mydb }
db4: { database: mydb }

will generate the same object.

Anyway, what kind of schema-blind generic tools you have in mind?  I'm
not aware of any.  And I also don't understand how lack of equality
rules could affect them: a schema-blind generic tool cannot convert a
YAML node to a native object anyway.  A document of the form:

a: 1
a: 2

will be represented by a generic schema-blind tool as a mapping:

ScalarNode("a", tag="?"): ScalarNode("1", tag="?")
ScalarNode("a", tag="?"): ScalarNode("2", tag="?")

where ScalarNode objects use identity-based equality.

> Readability is YAML's first and foremost goal. However, I don't see how
> saying that { a: 1, a: 2 } may be legal in some applications and illegal
> in some other applications increases readability. I find it to be
> confusing and that it decreases readability; that is, I can no longer
> tell just by looking at a YAML file whether it is valid or not, or what
> it means if it is valid.

It's not clear what you mean by valid.  Is it well-formed or not?  In
this case, it is valid.  Is this document adheres some schema (for
instance, the standard JSON schema)?  In this case, probably not.
The thing is that equality rules are schema-specific.

> At any rate:
> I think I have an alternative everyone could live with, though, based on
> my original option 3. The following suggestion is to codify the current
> behavior of existing implementations, but on a per-tag rather than
> per-platform basis. This preserve portability (which, like it or not,
> YAML views as an important goal, second only to readability).

Could you explain what you mean by portability?  That any document could
be converted to a native object?  But that is hardly possible since
capabilities of mapping objects in different languages differ
considerably.  Some of them could only support string keys, others
support arbitrary scalar keys, some of them accept immutable collection
keys, and some could have arbitrary keys.

> 1. Expand the definition of scalar tags to specify a list of other
> 2. For collection tags - a mapping tag could specify its values are

You still insist on structural value-based comparison.  See my example
above where a scalar node is equal to a mapping node.

> This does not address Osamu's identity vs. value based equality issue
> for collections. I view this as a completely orthogonal issue. It is one
> we discussed at length at the time (years back); in a nutshell, since
> YAML is a data serialization language, and since value-based semantics
> are a subset of identity based semantics (that is, value-based data
> works in identity based systems, but not the other way around), I feel
> that we made the right call. Changing this would be a much deeper
> modification than the above suggested tweak to the equality rules. That
> is, IMO changing this would be a YAML 1.3 or even a YAML 2.0 issue.

I definitely don't agree with that.  The fact that you cannot represent
a native structure in YAML naturally because of value-based equality
means that value-based equality is a wrong choice.


Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
Yaml-core mailing list