Publish mini-specifications for the various "semi-public" lib keys

[belluzj]

The lib mechanism to add custom data to UFOs is widely used, and while some keys are "private" implementation details of some UFO editors, some of these lib keys are "semi-public" in the sense that they're used by several programs that agree on the meaning for the keys, or are put in the UFOs on purpose by users in order for other UFO tools to pick them up and do something with that data. (I wrote "semi-public" to avoid confusion with proper "public" keys that are included in the official spec)

There is also a proposal for new spec additions to start as lib keys and then be included in the official specification once they've gained traction and maturity.

For both semi-public lib keys and draft specifications, I believe that it would be very useful to publish, alongside the official specification, a series of "mini-specifications" for the various proposals, with accompanying example UFOs ready for inclusion in the validation suite proposed in #117, and matching lines in the tool compatibility tables (even if only 1 tool out of all them currently supports that lib key/feature). Those mini-specification would follow the same format as the main specification, and maybe even a common template (that would facilitate the writing of these if they could start with "fill in the blanks" of the template).

Having one reference source of documentation and UFO examples for the key would facilitate discussion and interoperability; all vendors and tools could look into supporting the extra features themselves, and once the feature has gained traction and reached maturity, it's easy to fold into the main specification (half of the work will already be done).

[alerque]

CSS vendor prefixes.

_{Ducks for cover.}

[benkiel]

@belluzj A good idea

[typesupply]

would be very useful to publish, alongside the official specification, a series of "mini-specifications" for the various proposals

This is a great idea. My initial idea was "you publish your key" but that was because I didn't want to be responsible for keeping the site updated. At that point it was a huge pain because the "source" was a bunch of .textile files on my drive that were compiled with a homemade tool that spit out HTML files that I had to FTP. It's much easier to update the spec now, so this is a very good idea for interoperability and a lot of other stuff.

[benkiel]

Meeting consensus is that we should do this.

[typemytype]

as I converted the static html to jekyll on github, I can propose a system to build mini specs.

add a folder _miniSpecifications in the root of this repo, containing <reversed.domain.name.lib.key>.md files with the following setup:

---
layout: default
title: reversed.domain.name.lib.key
ufo-version: 
    - 3
    - 3.1
    - 4
---

# any mark down 

* my tool
* your tool
* data z
* data y
* data x

Each UFO version (except 1 and 2) will have a page forhttp://unifiedfontobject.org/versions/ufo<versionNumber>/mini-specifications with a list of all mini specs (based on ufo-version) + some "how-to-write-spec-info" related to the UFO process and design philosophy.

[justvanrossum]

It's probably implied, but I'd like to explicitly add that the *.ufo/data folder should be part of this, too.

(Ideally, also designspace.lib.)

[typemytype]

@justvanrossum each mini spec will need to specify where it will be stored: glyph lib, font lib, font data...

[belluzj]

I started some work in this pull request: https://github.com/unified-font-object/ufo-spec/pull/124

[Alhadis]

Stupid question: Is this more-or-less analogous to a JSON schema? (Sans requirements over a file's name and/or physical location).