Re: Equality of YAML nodes

Hi all,

I want to complement my post on the other day.

>> Note that, as seen above, constructing a ruby's hash or an 
>> instance of Test class from a YAML mapping node did not preserve 
>> the data equality. 
> 
> In order for YAML to work, the representation of the object to YAML must
> follow YAML's rules. The representation of "Test" objects as YAML did
> _not_ follow these rules. The author of the Test class should have
> overriden the default serialization-to-YAML to resolve it. As long as he
> hasn't, he has a bug, and this isn't YAML's fault.

Since we are talking about modifying current YAML, it can not be 
an answer for my question to say "this is the YAML's rule". ;)
So, let me discuss whether changing the rules is beneficial for 
the users or not at all. :(

I already gave a feedback to your question how a value-oriented languages
should treat ruby's Test object. But I'm afraid that was not selfcontaining
enough.

In my opinion, to have a specific YAML document really portable between 
environements, we must have some schema that describe the structure and 
the meaning of the nodes. So, there won't be a perfect portability without
any pre-exchange of knowledge between the serializer and the deserializer.
For languages such as ruby and C#, which provides access to the language's 
meta data, the definition of a class can be a useful schema of a YAML 
document.

Imagine we are serializing an instance of a class SomeClass in C#.

  public class SomeClass
  {
    public int a = 1;
    public string b = "1";
    public double c = 1;
    public Point3D p;
    public utf8u[] texts;

    bool Equals(object obj)
    {
      ... # specify how to compare SomeClass objects
    }
  }

  ...

    SomeClass obj = GetSomeClassInstanceWithMeaningfulContent();
    string yaml = YAML.Serialize(obj);

The resulting YAML document will be like the next.

%YAML 1.2
---
!SomeClass
a: 1
b: 1    # I prefered to have this as "1" for the readability, though.
c: 1
p:
  X: 3
  Y: 4
  Z: 2.1
texts:
  - "..."
  - "..."
  - "..."
  - "..."
  - "..."

Note that we do not have to go the next way.

%YAML 1.2
---
!SomeClass
a: 1
b: "1"            # By default, 1 is resolved to !!int 1
c: !!float 1      # By default, 1 is resolved to !!int 1
p: !Point3D
  X: !!float 3
  "Y": !!float 4  # By default, Y is resolved to !!bool true
  Z: 2.1
texts:
  - !!utf8u "..."
  - !!utf8u "..."
  - !!utf8u "..."
  - !!utf8u "..."
  - !!utf8u "..."

We can resolve the tags for the child nodes from the definition
of SomeClass automatically. I undestood YAML allow this, from the
description that the tag resolution can be dependent on the path 
leading from the root to the node. Note that the meaning of each 
field must be also exchanged in the form of SomeClass's 
specification between the serializer and the deserializer, to 
interplete the contents of the fields correctly when deserializing.

With languages that provides the access to the class metadata, 
a general purpose library can be build, which converts native 
objects of arbitrary classes like SomeClass into YAML document, 
with refering to the language's metadata database, without
having any other explicit schema.

Note that both the serializer and deserializer must know the
definition of nodes' content, anyway, to interprete the 
conceptual meaning of each field. Using the definition of
SomeClass for that purpose does not seem to weaken the 
document's portability.


I think exchanging the information, how an instance of SomeClass
should be evaluated its equality, between the serializer and the
deserializer also does not weaken the portability. The way of
comparison is often defined as the member function of the class,
for example, Equals for C# objects and == for ruby objects.

This was the reason why I defined the equality of YAML nodes
with non standard YAML tags as:
  If the nodes are identical, they are equal.
  If the nodes have different tags, they are not equal.
  Otherwise, the result is dependent on the native objects'
  equality evaluator.

Do not think this makes the YAML language dependent on a specific
language. It merely makes the YAML language dependent on the
schema of data. I guess it makes the YAML language applicable 
to wider variation of schemas of data.


> We'd rather not go down this road. The use case you demonstrated (using
> "Test" instances as keys) is pathological; I would be greatly suspicious
> of a system that used such a method, and I definitely wouldn't want to
> bend YAML out of shape to handle it.

I hope you understood the concept of my President-Party example.
If you think it is still useless, please give some response on it.

Thank you,
Osamu TAKEUCHI


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf