Re: [Yaml-core] stability and acceptance of YAML

[Clark C . E. <cc...@cl...>]

On Sun, Jul 14, 2002 at 07:27:22AM -0700, Donnal Walter wrote:
| By way of introduction, I am a programmer by avocation only (my
| training and vocation is medicine). I'm also a staunch advocate for
| Python. For the past few months, I have been working on a personal
| toolkit to make it easier to write custom clinical applications in
| Python. My approach to persistence was to write a Python to
| (http://www.docuverse.com/smldev/minxmlspec.html) to Python
| writer/reader (using recursion and polymorphism). This has worked
| quite well so far, but I've worried about the verbosity of the data
| files among other things.

It's great to hear that some people are actually using 
the minimal XML specification!  Oren and I were actually
major contributors to this spec (less so to Common XML).
The other primaries, Mike Champion, Simon St. Laurent,
Joe Lapp, and of couse Don Park are all very sharp minds.

| When I read the YAML 1.0 spec, I was impressed with the clean
| syntax (goes right along with Python). It seems like my scheme
| would be easy to implement in YAML.

Thanks.  The credit belongs to members of this mailing list
and the debates that have raged here over the past year and
a quarter.  I'd like to point out that the information model
(which IMHO, is more important than the syntax) is also very
clean.  A solid information model is needed for a clean API
and generic tools that process YAML.

| 1. How stable is the core YAML specification? I am not talking
| about the bleeding edge, but have the basics changed much lately,
| or are they likely to change much in the future?

I'd say 95% of the spec is now immutable mod explanation
improvements and clarity.  A few things may change off
the top off my head:

 - adding escape mechanism to block scalars (10% chance)
 - removing extra constant sugars (on), (nill)  (20% chance)

The last big revision (about a month and a half ago) changed 
quite a bit as it reflected usage feedback since Febuary.
In this change, about 80% of my texts were unaffected; and
the other 20% needed a simple read-in with a old parser and
write-out using a new emitter.  Rather simple actually.

Right now the "C" and Python implementations are a bit behind
the spec; but the Perl parser is darn compliant.

| 2. How widely accepted is YAML at the current time? This is not the
| most important criteria for me, but wide spread (or widening)
| acceptance would be a plus.

Our team here is around 10 core members (many of them now coding 
up implementations) and about 15 on the bench and about 60-90 in 
the penut gallery, including a few XML-heads who are waiting till
it is safe to come out of the closet.  *poke*

We have several market nitches which XML does poorly:
 - Moving information between programming languages
 - Readable log files, object in-memory debugging dumps
 - Configuration files

And in those nitches, we are the only team with a serious 
specification and implementations in more than one major 
language.  I hope this does the snowball thing.

In the future we will expand further into "XML territory" with
tools for distributed systems; competing in the remote object
space with SOAP and XML-RPC, and with object transformations
using cYATL.  cYATL will be our up-and-coming transformation
language (about 2 years out) which will be similar to XSLT but
without the warts.  XSLT has to bend over backwards to cope with
XML's lack of information model; YAML was designed from the ground
up to have a solid information model so that transformations and
schemas will be clean  -- I was part of an XSLT implementation
team and had some early exposure with RELAX. 

Brian Ingerson has stated he is going to dig into Parrot (Perl 6)
to make sure that we are part of the core distribution.  Parrot is
a open source "register based" virtual machine which is being 
designed to run not only Perl, but have byte-code compilers for
Python, Ruby, Scheme, etc.   

| Just as I did not write a general purpose XML parser (nor did I use
| the XML packages included with Python), I have no plans to write a
| general purpose YAML parser. I am simply interested in using the
| YAML spec as the format for the data files that my writer and
| reader use.

It isn't compliant, but Steve has a very nice python implementation
that is in development.  A snapshot from the source code repository
is http://yaml.org/python/PyYaml_14jul2002.tgz ; it works, but expect
bugs (there are a few) and some un-implemented features (emitter
doesn't do anchors).  We may want to label this module "yaml" 
so one can do "import yaml".

I'm not sure what's up with the libyaml these days (Neil must be 
busy on other stuff) but it will re-emerge in a few months.  This
implementation includes a python binding as well; implemented via
a "C" module instead of Pure Python as Steve's implementation above.
I expect the two to be plug-in replacements for each other just
as cStringIO is a native replacemnt for StringIO.  Right now the
native binding is "yaml", I'm going to move it to cyaml.

I also expect to formalize an XML binding for YAML data, this is
needed for those people who have a manager that requires XML but
that they're sold on YAML.  When I get time I'll add the input/output
code to the python parser (both steve's and cyaml).   The provisional
spec for this is at http://yaml.org/xml.html but it needs one big 
semantic change -- all types not a string,list, or mapping are explicit.
Right now it uses the implict rules... and this makes it hard for any
XSLT transformations to work that rely upon typing information.

I hope this is helpful.

Best,

Clark