Just thought I'd explain my disappearance. I've been working on two things: my new web site (almost ready), and alternatives to YAML.
In particular, I've been focusing on giving the user more formatting freedom, eliminating cryptic symbols, and simplifying both the notation and the model.
I was able to allow the formatting freedom and to eliminate most of the need for cryptic symbols, but I had only limited success with simplifying the notation and the model. Too limited to happyize me.
The problem is that if any notation is going to be a serialization syntax, then it must inherit many of the problems and complexities of serialization.
For example, such a notation must encode type information. From recent discussions, it appears that YAML will only natively support various numeric and string types, but each of these values has the property that it is one of these types. OO languages extend this concept so that a value may have one of these types, but it may also have alternative types. It is artificial to distinguish between them, and YAML (de)serializers for OO languages will have to insert additional (non-orthogonal) information into its serializations.
I explored various ways of simplifying this problem and like problems, but ultimately gave up. If it's intended to be a serialization language, these problems arise in various forms, and there's no way around it.
When I look at the resulting complexity, I lose interest in YAML and in serialization languages in general. For me, the best weapon we can have is simplicity, and I worry that this weapon has been dulled too much. My primary motivation for being involved is to find a very simple alternative. If my gut feeling tells me that something isn't simple enough, I lose my motivation.
So I am now pursuing simplicity by restricting myself to a particular subset of all data: relational data. That's the kind of data I want to work with anyway. I don't really need the serializer. I've done some thinking about this and find that once you throw out general serialization, you can throw out the need for the data to conform to conventional data structure hierarchies (made into graphs by references). You end up with a lot of freedom.
I don't know where I'm going with it, but I have some ideas. I'm putting together a set of requirements for the kind of thing I want. This discussion on YAML has helped me figure out what they are and continues to do so.
Good luck, YAMLers! I'll probably hang around, but I'll be focusing my energy elsewhere.
I just wanted to add one clarification:
I think YAML is shaping up to be a pretty good serialization language.
My only real nit with YAML as a serialization language is its strict formatting, but I understand that this is more a religious issue than a technical one.
But YAML's focus on serialization introduces more complexity than I want, which keeps YAML from being the gold I'm looking for. My search goes on...