Ok, I'm convinced. Let's give YAML a shot.

Ok, so there is a initial go at this in the other mail.

In terms of broad technical strokes, I think either YAML or XML would
be sufficient. But given your enthusiasm for YAML, and it's superior
human readability, there's no argument against it. (Other than the
work / support involved).

A few additional comments as we get going:

* I agree that Yaml-cpp seems like our best option of the ones you've
mentioned. Let's go with it. Is is feasible to wrap it into the
OCIO namespace? see src/core/tinyxml/tinyxml.h as an example It's
got a lot of source files, but I really would prefer if possible to
keep all OCIO symbols inside a versioned namespace.

I have added a local copy of yaml-cpp and a patch to make it build static.
Once we get a little further down the road, we can work with the yaml-cpp
project to get a customisable namespace for our purpose.

* For the OCIO:Config implementation, the list of display devices and
color spaces actually do preserve order. While the ordering is not
relevant to color processing, it is useful in a UI context.

So the yaml is slightly different to the demo's I sent through before displays
and colorspace are now YAML sequences so order is preserved. (there is
a !!omap tag for doing ordered maps but a sequence matches nicely to the
current OCIO structure http://www.yaml.org/spec/1.2/spec.html#id2761292)

eg.
displays:
- !<Display> ...
colorspaces:
- !<ColorSpace> ...

Roles are a map but could be a sequence also depending on preference.
roles:
default: !<Role> {colorspace: raw}

Both roles and displays get emitted in the Flow style (all on one line) but
could be emitted in the Block style if thats more legible.

Note.
-- this --
displays:
- !<Display> {device: sRGB, name: Raw, colorspace: raw}
-- and this --
displays:
- !<Display>
device: sRGB
name: Raw
colorspace: raw
--
Will parse the same, but it's nice to choose a style that makes sense for
emission.

Another thing which might be nice is having the following 'detail:' and
'gpu:' fields to make the profile not so vertically challenged.
--snip--
ocs_profile_version: 1
resource_path:
strictparsing: false
luma: [ 0.2126, 0.7152, 0.0722 ]
roles:
default: !<Role> {colorspace: raw}
displays:
- !<Display> {device: sRGB, name: Raw, colorspace: raw}
colorspaces:
- !<ColorSpace>
name: raw
detail: { family: raw, bitdepth: 32f, isdata: true }
gpu: { gpuallocation: uniform, gpumin: 0, gpumax: 1 }
description: |
A raw color space. Conversions to and from this space
are no-ops.
--snip--

* Keeping the serialization code internally as statics - not on the
Transforms themselves - is useful so we dont need to expose the
serialization to the public API. Or do you have a better
implementation in mind?

I have some ideas but I thought it would be better to just do a swap
out replacement first, then tackle plug-able Transform() serialization later.

Thanks for all your work on this issue,

No problem.

.malcolm