[Yaml-core] Re: Scope for YAML 1.2

[Jeff K. <jt...@ya...>]

Clark C. Evans wrote:
> help set the direction for 1.2 activity:

This is more a comment on the process for YAML-1.2; I'd like to see
real-world parser design interacting with the spec process. YAML has an
uphill climb to find a niche with JSON's popularity, and XML's
entrenchment.

I think if we go another long stretch without pure scripting language
parsers, YAML is probably not going to fulfill its potential (for
widespread adotion).

I'm speaking only as an interested user who would like to introduce YAML
to various useful projects and frameworks where I can identify a need.
From that point of view, it would be tremendous if the YAML-1.2
development process could proceed with elements of the following:

- A draft of the YAML-1.2 spec is produced.

- The draft is published in a public repository, commit privileges can be
obtained through some reasonable process (i.e. more committers).

- A recommended reference parser design accompanies the spec draft
(push/pull, etc.) based on identified use cases. UML and pseudo code for
the reference parser design might even be appropriate as an appendix of
the spec.

- Reference parser projects are started in various scripting languages
(perl, python, ruby, javascript etc.), based on availability of volunteers
and/or sponsorship. This is to unify the efforts of various eager elements
within the community, so that usable parsers exist even before the spec is
finished. The reference parsers are developed in the same repository as
the spec.

- Reference parsers share a common design, to demonstrate the
best-practice parser design in different languages.

- The draft spec and the reference parser design is exercised completely
by literate unit and functional tests for each reference parser. For
python, 'doctests' are what I have in mind, other scripting languages
likely have something similar. JSON interoperability would be a component
of these doctests.

- User documentation is built up as part of the doctest process.

- The draft is updated based on feedback about the spec itself, and about
issues encountered during parser implementation.


After some number of draft cycles:


- The points where C will be needed for performance are identified
(hopefully common across reference parsers).

- A portable C library is developed to service those performance hotspots.

- C hotspot library language bindings for the reference parsers are
developed and integrated.

- The reference parsers always retain their fallback capability when the C
extension is not available.


As the spec nears final status:


- A portable C parser of the common reference design is written which also
uses the common C hotspot library.

- C reference parser language bindings are developed.


Once the spec is marked final:


- As of the YAML-1.2 announcement, is part of YAMLs 'draw' that pure
scripting language, scripting with C extension, and pure C YAML-1.2
parsers are immediately available, along with comprehensive documentation
via the 'doctests'.

- Profit!  ;)


Thanks for reading through this naive wishing-for-a-pony scenario.

Surveying the list of YAML users, it seems that a large fraction of people
here are experienced enough to have written parsers of some sort. The
fraction that could contribute to a directed implementation of a reference
design in their favorite language is probably much larger. More people
could contribute to doctests and editing thereof.

With a fairly open subversion repository (to support all the cross-project
branching and merging), I submit for your consideration that the total
process of spec-to-usable-implementations will not be slower because of
the parser-driven process. I suspect it might even converge on the 'right'
YAML for the current marketplace sooner.

Thanks,