On Fri, May 17, 2002 at 09:00:52PM -0700, Brian Ingerson wrote:
| At 13:00 18-May-2002 Clark Evans and Brian Ingerson are
| scheduled to meet in Raleigh NC for a YAML mini-Summit.
| Steve Howell and Ryan King will also be in attendance.
We had fun. A few things of important interest:
We talked about boolean proposal and those in attendance
seemed to favor !bool 1 or !bool 0 for the actual values.
That said, we figured that we could introduce the concept
of a pre-defined anchors. Namely, we could specify in the
specification that *false is, by default, an alias to
!bool 0, and *true is an alias to !bool 1 ; to help config
files we can also specify *yes and *no as well. (and
*mabye could be defined as !bool 0.5... just kidding)
Oren's comment proposal was welcomed. In particular, I really
like being able to use a comment after an alias:
--- *true #This is a true value
We've decided to put up a Wiki for YAML. We would assimilate
all of our "archtectural choices" with a page in the wiki.
Unlike other Wiki's, we would not encourage "signing" style;
edit the page if you can say it better, otherwise one should
use the e-mail list for discussions. I think I heared that
Steve would be the leader on this project... yes? This should
help address Andrew's suggestion that we gather our core
decisions and their rationale into a single repository.
We talked about a random access API for YAML. Specifically
one that reflects the "generic" model. Ideally this API
would be an extension of the yet-to-be-described pull-parser
allowing random access interface. We would then implement
YPATH, our transformation language, and other goodies using
this API. In the new-rev of Neil's parser, he has replaced
his initial "string" library with a pluggable string lib so
that python/perl strings could be used. We would use the
same technique allowing the nodes themselves to be replacable.
We talked alot about YPATH and how it would work. Also we
reviewed a bit how XSLT works, and how we could write a transform
language for YAML. We seemed to generate a good amount of buy-in
from the participants around the table with regard to this... now
comes the hard part, slowly fleshing it out. Steve/Ryan are
going to implement what they need in Perl, and hopefully their
requirements/needs will be summarized to the list so that we can
collaboratively build a great YPATH. There didn't seem to be any
objection to "modifying xpath" to meet our specific use cases, etc.
We talked about various use cases. Since I don't have the notes,
I'll have someone else post this. To me it is quite a bit more
use cases that I was originally thinking (mostly messaging).
Once the Wiki is going strong, we will use it to extract
material to build several articles for journals. Also,
we should start to find local conferences and get on the
schedule. Brian is presenting at the next Perl conference.
In another year or so we may want to have a mini-yaml
conference... it'd probably be prudent to do this in close
proximity to a good sized potential userbase. Eventually
a book would be good (build from articles and the wiki),
thus contributors to the wiki should license their content
under a freeish license that would allow a publisher to
make money for printing paper..
We talked a bunch about the Perl/Python bindings and other
language bindings. It seems that for emitting we have two
related concerns: (a) a native object which may need to
"explode" into many yaml-nodes; (b) the need to detect duplicate
nodes so that anchors can be used only when needed. Brian
was thinking of using "tie" instead of blessing...
For the emitter, we need to be able to specify key
ordering (for easy reading). We were thining of a
good standard way to do this. The hack which the
perl library uses is simply a large list of keys, ordered
as you would like. Antother approach is to store the
"preferred" key ordering in the schema, or in a
"styling" document. Thoughts?
Hmm. There is lots more we talked about in the 4-5 hour
meeting... and lots we didn't get a chance to cover.
P.S. As always, this is from my "lossy" memory and
may not accurately reflect the subtles of the
actual events as they occurred.