From: Clark C. E. <cc...@cl...> - 2002-09-11 22:28:59
|
On Wed, Sep 11, 2002 at 02:36:10PM -0700, Brian Ingerson wrote: | > We also want the match to be "close" for commonly _used_ types in "most" | > languages. I think !map/!seq/!str (or scalar, anyway) is a great choice | > here, and that anything else can be made to pay some extra cost, one way or | > the other. | | Well resaid. The spirit of YAML is in the plain old map/seq/str model. We are | realizing the potential to do other stuff, which is great. But that's not | what we should formalize in the spec. I'm not quite sure. But your posts resonate. Esp. the one about wasting time. If I would have spent 1/2 the time on this last set of stuff on a YAML schema, we'd be quite far along. I'm looking forward to getting back to libyaml implementation. | My current thought is to keep an information model in the spec, but have it | use layman wording and limit it to the basic models that we have today. | Basically it would just be describing what Perl/Python/Ruby programmers | implicitly know: how hashes/arrays/scalars work. The reason to do this is | that we can freeze the spec SOON. I was thinking of focusing on what I was calling the "generic" model in my last few posts (with duplicate keys and key order) since this model is a very close model of what the syntax allows. This is, in essence, just removing the stuff about the functional model and cleaning the rest up. | Then, I would propose that we work on a separate "Useful YAML Information | Models" document which we can spend more time on. If you don't make a | separation between that which has been decided and that which is still very | much debatable, then you'll just stimey implementation. Yes. I'm starting to see the wisdom of moving the "functional" model out. Perhaps that's where YAML tools work, but this doesn't necessarly have to be in the YAML spec itself. If people then do stuff that supports the "functional" model, they can use the tools; if not, so be it. But this way the spec doesn't necessarly tie people to the tool set that I had in mind. For example, with a the current syntax, someone could easily represent Minimal XML in YAML syntax, perhaps even building a "native" loader into a subset of XML's DOM complete with XPATH. I'm not saying I like the option; but it is an alternative which I have no right in saying "no" to. ... That said, I've enjoyed your last few posts and agree with most of the stuff. Give me another day or so to collect my thoughts before I start a posting spree again. This next time I'll try to keep it shorter. Best, Clark |