Brian Ingerson wrote:
> I just finished reading the daily yaml rants. Boy do you guys sometimes
> bore me to tears. And just when I think we've settled everything there
> has to be new major proposals. :(
I'm starting to feel that way too, sometimes. I've absolutely no idea
whatsoever why Clark is trying to define a DOM, for example, or what YPATH
has to do with things :-) I mean, it is all well and good to debate what the
base class of map and list would look like and whether the return value of
atom is a 'void *' or a 'wchar_t *' or whatever, but *why bother*?
We have an info model we all agree on (never mind the fact that it can be
worded in any of several ways, all meaning basically the same thing). We
pride ourselves on it being supported *directly* by every programming
language. Let's just leave it at that, OK?
> My thoughts:
> - I withdraw my "last key wins" proposal
> - || is fine
> - I want --UNIQUE instead of just ---
> - I don't still don't feel like answering \$a->
> - No forward references please
We all agree so far.
> - I really want to table "structured keys" until YAML 1.1
I have a problem here (see below).
> - I really want to *IMPLEMENT* now!
I agree. That's why I have a problem with the previous point :-(
> My rants:
> 1) The ideal info model is: "Whatever we need after we get Perl, Python,
> PHP, Tcl and Java implementations done." I actually know real people
> who are each experts in these languages and want to do
> implementations. And I bet they're very willing to find a nice common
> ground. We definitely have enough to get going. We could go on
> talking about things forever. Let's just freeze, implement, test, and
> then readdress the issues.
Well, yes. I think the last info-model talks were more of a re-phrasing
rather than an actual change in intent (well, perhaps a very subtle one
which isn't noticable to any implementation). We can start implementing
regardless - it doesn't change one thing as long as one maps to native data
> 2) In Perl, YAML will never *really* round trip in memory structures. So
> I'm not super worried about edge cases. Consider a string that is
> readonly. A constant. Upon roundtripping, it will not be. And that's
> just the tip of the perlberg. So just relax. I do have a very good
> idea of how I'm going to serialize Perl in YAML. But explaining every
> edge case at this point is futile. <subrant> The examples I get from
> you guys are somewhat problematic and have subtle issues that I
> really don't feel like discussing at length.</subrant> I'd rather be
> in the position of you guys saying, "Hey Brian, why does YAML.pm do
> this?". Will I ever get to write a YAML.pm?
OK, point taken. One point though - we want the Python or Java
implementation to be able to read whatever YAML.pm produces and result in
reasonable, *native* structures. We'll have a hard time if the magic you'll
use to serialize read-only strings (or whatever) would mean that reading
them into Java I'll have to use YAML-specific classes.
I guess this sort of problem is inevitable, but let's try to ensure it only
bites us if someone is doing something esoteric, rather than a common case.
Given the above, I promise to stop bugging you about it :-)
> Well I really am not trying to piss you guys off. I'm just feeling a
> little frustrated.
I share this as far as discussing the (DOM-like) API is concerned. I'm going
to just ignore it for now - I think we should start with a load/dump
interface to the native languages.
Which brings me to structured keys. I want to do the Java implementation. I
*really* would like to do it by latching to Java's serialization mechanism,
so you could just serialize your data into YAML. Some people already did it
using XML, I thought I could start with their code, change the formatting,
and make YAML a nice way to serialize any Java data.
The problem is Java hash tables. They can take just about anything as a key,
as long as it has a hashCode method (just like Python). I have written quite
a bit of Java code which used this - it isn't esoteric at all to a Java
I realize Perl would have a hard time with these. For all I care, just
reject them as unsupported. But I need them, sorry. Other than that I agree
we should just wrap things up.
Now, about these keys :-) For some reason Clark doesn't want to have
separate @ and % indicators for the separate map and list "styles". As he
> To cut to the chase...
> % !array
> 0 : val
> : one
> @ !array
> - val
> : one
> How are these different?
Sigh. In the same way that the following are:
The kind/style of the node is different. *And this kind/style is not
reflected in the data model* in both cases. Big deal. I think keeping "one
indicator <-> one kind/style" makes a lot of sense. Besides, I think:
Is neat. It also helps Brian in his blessed-empty-collection use case (not
such a big deal, he can manage without it, but it does help). It is
especially useful at the top level, where it *really* simplifies things *a
lot*. No more "you can have an empty top-level plain scalar as long as the
optional type property exists" - Good riddance!
> On a good note, I'm writing a Perl book for a major publisher, and so
> far they've agreed to a YAML appendix! (The software already uses a
> Data::Denter/YAMLish hack for configuration)
Congratulations, and Good Luck!
> See why I *need* implementations? :)
Agreed. Now if you just give me my hash table keys I'll start happily
working on the Java code :-)
I suggest we declare that next weekend, come hell or high water, we freeze
the spec and start coding. This weekend I'll work with Clark on putting all
the latest in. During next week we'll settle any remaining issues - by vote
if necessary (we are three, that makes things easier). Next weekend we cast
it into a frozen spec form *and start coding*. During this week no new
issues (YPATH, DOM, etc.) which aren't *directly* related to the frozen spec
*physical document* would be discussed.
I think this is a realistic schedule. We haven't raised any really new issue
for a while now - we are re-tracing old decisions seeing whether we are
comfortable with them, sort of a final review process. Let's let this review
have its week of grace and move on.
Now I'm going to take a look at Clark's latest doings to the spec :-)