Re: Equality of YAML nodes

> -----Original Message-----
> From: Oren Ben-Kiki [mailto:[email protected]] 
> Sent: Sunday, September 20, 2009 2:22 PM
> Subject: RE: [Yaml-core] Equality of YAML nodes
> 
> On Sun, 2009-09-20 at 11:34 -0400, BlueGM wrote:

<omitted the text Oren was responding to>

> Yes, you have hit the nail on the head. I think one the 
> errata we need to fix to reverse the order between points 2 
> and 3, to clarify this point (unless Clark objects).
> 
> The point never was to "perfectly" match native data 
> structures. Another good example of this point (that also 
> triggered a lot of debate at the
> time) was PHP's native maps-with-ordered-and-duplicate-keys. 
> YAML's solution to that is to use a sequence of single 
> key/value pairs, as in !!omap [ foo: bar, foo: baz ]. The 
> same arguments were raised there as well as here (for 
> identity): default mapping, matching native data structures, 
> portability, cleanness of the information model, commonality 
> of use cases, etc. The decision (there as well as here for 
> identity) was/is to stick with portability and cleanness of 
> the data and common uses cases rather than exactly matching a 
> specific programming language and less common use cases.


If that's the intent, then I agree that points 2 and 3 should be reversed.
And perhaps point 2 (what would become point 3) should be reworded slightly
to emphasize its "likeness" to those native data types rather than leaving
it open to interpretation as to whether it means "like" or "exactly
matches".

Which then leaves the question of, does this narrow the application of YAML,
as Osamu states when he writes:

"I agree that the way you go is completely selfconsistent and theoretically
very smart. But I feel it narrowers the application of YAML."

And, with that, if it does narrow the application of YAML, how great of a
concern is it? On that, I imagine there will be a great difference of
opinion.

My own opinion is that while it may make YAML a little harder to use in some
cases (certainly, some other recent conversations relate to problems of the
differences between the native representation of data and their YAML
representation), it doesn't actually prevent YAML's use in those cases and
widens its potential use in cases where systems must communicate cross
platform or language, which could be exceedingly difficult and, in some
cases, even impossible otherwise. In other words, I see the value of
portability as much greater than the extra cost of YAML not always perfectly
matching the definitions used by languages. I also see the cost of not
having that portability on applications that require it to be much greater
than the cost to applications that have to deal with differences in the
definitions of the types used (including their equality). This becomes
notable, by way of example, in the oft cited case of a YAML editor, which
will quite frequently be in a different language than the language that the
data in the YAML file will be used for.

Of course, this is largely a theoretical discussion anyways. As Osamu quite
effectively points out, existing libraries don't implement the YAML
specification perfectly. That's hardly new, or unique to YAML, though. It's
the real culprit behind cross platform incompatibility in more than a few
public standards.

Those, of course, are my thoughts. I'd be interested in hearing what others
have to say about this too. As I said, it is largely a question of opinion
(being a cost/value estimate of each).


Thanks,

BlueG


P.S. The yaml-core mailing list hasn't yet forwarded the message that Oren
was replying to, so it might be out of sequence with this message, assuming
it makes it through at all =p. If it doesn't I'll resend that message to the
list later.


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; 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&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf