Re: Equality

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 <[email protected]> wrote:

> Oren Ben-Kiki wrote:
> > On Sat, Nov 28, 2009 at 8:55 PM, Osamu TAKEUCHI <[email protected]
> > <mailto:[email protected]>> 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.
>
>
> Thanks,
> Kirill
>
>
> ------------------------------------------------------------------------------
> 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.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>

------------------------------------------------------------------------------
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.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core