UFO Cleaner's "known keys"

[Adam Twardoch (List)]

Jens's UFO Cleaner maintains this very useful list of known lib keys at:

https://github.com/jenskutilek/RoboFont/blob/master/Extensions/UFO%20Cleaner.roboFontExt/lib/knownKeys.py

I think it'd be useful to put this somewhere in textual form. For example, set up a wiki at https://github.com/unified-font-object/ufo-spec and put such stuff there? Such a wiki could be a place for less-official notes around UFO. 

A.

Sent from my mobile phone.

[Adam Twardoch (List)]

In addition, I'd like to bring up an idea.

In Python, there is the convention of prefixing a method with "_" if the method is supposed to be private, and in OS X, prefixing the filename with "." makes it hidden.

More and more apps that work with UFO will use some lib keys which are defined by a vendor. For example, com.adobe.type.autohint key and the com.typemytype.robofont.mark are used by FontLab VI.

I'd like to propose a simple extension of the "reverse domain" convention for keys naming. If the first character of the key is a "." then the key should be considered private. This would show the vendor's intent that other apps should not implement any functionality based on these keys, should not rely on that key's contents' stability in any way etc. Of course it would not be enforceable, but within FontLab, I can imagine that we'd be happy if others use com.fontlab.v2.tth or com.fontlab.ttprogram but there may be some cases for some very specific data where we could name the key ".com.fontlab.ufo2to3migration" and it really would be "just for us".

Optional: In addition, 3rd party apps would not need to make any effort to maintain the contents of these keys. The spirit of the UFO spec is that different apps should make an effort to keep the contents of the "lib" intact. That's fine, but there may be quite a few cases where it's better to trash this data than keep it, and with a key prefixed with ".", an app would not need to bother.

I think that would be a fairly elegant system:
- public.* : not part of strict UFO spec but considered publicly-owned and stable
- com.vendor.* : vendor-owned and controlled but publicly-accessible with an implied vendor's intent to keep it stable
- .com.vendor.* : vendor-owned and controlled, and private; no guarantee whatsoever that it'll remain stable

Opinions?
A.

[Tal Leming]

>> On 09 Dec 2014, at 10:33, Adam Twardoch (List) <list...@twardoch.com> wrote:
>>
>> Jens's UFO Cleaner maintains this very useful list of known lib keys at:
>> https://github.com/jenskutilek/RoboFont/blob/master/Extensions/UFO%20Cleaner.roboFontExt/lib/knownKeys.py
>>
>> I think it'd be useful to put this somewhere in textual form. For example, set up a wiki at https://github.com/unified-font-object/ufo-spec and put such stuff there? Such a wiki could be a place for less-official notes around UFO.

A list like that could be very useful, but I don't have time to maintain it. In the past wiki's have become havens for spam, noise and debates about unrelated matters. I don't have time for that. Sorry.

> On Dec 9, 2014, at 4:52 AM, Adam Twardoch (List) <list...@twardoch.com> wrote:
>
> I think that would be a fairly elegant system:

This is an interesting idea. I'll open an issue for it in our tracker.

> - public.* : not part of strict UFO spec but considered publicly-owned and stable

Just to be clear, the public.* prefix is reserved for and owned by the spec. Vendors shouldn't define their own keys or value structures using this prefix.

> - com.vendor.* : vendor-owned and controlled but publicly-accessible with an implied vendor's intent to keep it stable
> - .com.vendor.* : vendor-owned and controlled, and private; no guarantee whatsoever that it'll remain stable

I think there needs to be some more subtlety here and it needs to be backwards compatible. For example, I certainly didn't define com.typesupply.AccentBuilder.* to be stable 10 years ago. I don't want that to be interpreted as being designed for external use.

One major point that I need to make: the spec will not state anything about vendors "owning" data within the lib implicitly, explicitly and certainly not legally. If there is a problem with someone doing something with some data in the lib, we are not responsible.

Thanks,
Tal