Doug Holton wrote: > That is exactly why YAML can be improved. But XML proves that getting > it "right" for developers has little to do with getting it right for > users (or for saving bandwidth). What's right for developers is what > requires the least amount of work. The problem is, that's what is right > for end-users, too.
Having spent some time with YAML and it's implementations (at least pyyaml and the ruby/python versions of syck), I thought I should comment. The only problems with syck we've encountered have been to do with the python wrapper rather than syck itself. Syck seems to be used widely without problems within the Ruby community and if anybody has evidence of issues with it I'd really like to know about them. PyYAML is a little inactive and doesn't conform to the spec in many ways and, as such, we prefer the syck implementation. In my opinion there have been some bad decisions made whilst creating YAML, but for me they are acceptable given the advantages of a data format that is simple to read and write. Perhaps judging the utility of a project on it's documentation is one of the problems, as most people who have 'just used it' seem to be happy enough. These people include non-technical clients of ours who manage some of their websites by editing YAML files directly. That said, I don't think it would be the best way to enter data for a life support machine, but I wouldn't like to do that with XML either ;-) One thing that should be pointed out is that there are no parsers available that are built directly on the YAML pseudo BNF. Such work is in progress in two different forms but don't expect anything soon. As I understand it, Syck has been built to pass tests rather than conform to a constantly changing BNF and it seems to have few warts. Tim -- http://mail.python.org/mailman/listinfo/python-list
