Relax <lib> requirement to include a dict

[ctrlcctrlv]

Cf. fonttools/fonttools#2234

I think it's too strict to require a . An empty should be OK. Also, there's a grammatical error in the sentence, which I fixed.

[benkiel]

Counterpoint: a lib element means that there must be a dictionary for the lib, hence the tight coupling. That lib can be empty, yes, but that means the dictionary is empty, not the lib element.

[benkiel]

Thinking about the above: I part of this comes down to if one things that an empty lib has a different meaning than no lib. If one things they are the same, then the requirement seems overly strict. If one thinks that they are different, the requirement makes sense.

[ctrlcctrlv]

I think they're the same.

[alerque]

In this case an empty lib tag adds no semantic value over no tag at all, so I don't see any sense in viewing them differently either. An empty tag should be skipped over in processing the same way no tag is.

The only real questions I see here are:

a) How to handle UFO versioning and backwards compatibility.
b) What to recommend for normalization purposes.

[anthrotype]

On the one hand, I don't see any semantical difference between an empty <lib/> element, or one with a single empty <dict/> child, or a glyph where no <lib> element is present. They all signal that the glyph has no "lib".
On the other hand, @ctrlcctrlv hasn't put forward any convincing arguments (besides "it should", or "too strict") as to why it would be desirable to explicitly allow the empty <lib/> element without the required plist <dict> element.
The lib element itself is optional. If the dictionary is empty, there is no need to write out the lib element. This is a non-issue to me.

[alerque]

This is a non-issue to me.

I don't know @ctrlcctrlv's use case either but the obvious one that occurs to me is using XML libraries to serialize data structures where you don't get a choice on how this is output. Which is also why normalization is a touchy subject. Unilaterally declaring that one way of representing this particular noop as right and the others wrong is not that much different from saying the XML has to be indented with tabs instead of spaces. I have strong opinions about which one is best, but not everybody has the luxury of doing it "my" way.

[anthrotype]

whatever. I'm ok with relaxing that restriction. It does not have any backward compatibility issues, because compliant implementations already support the current stricter requirement.

[anthrotype]

What to recommend for normalization purposes

drop it

[anthrotype]

on second thought, this does have backward compatibility concerns. In which case, it's not really worth it.

[anthrotype]

... or can be pushed back to UFO4

[ctrlcctrlv]

What are the backwards compatibility concerns?

[anthrotype]

If one tool (e.g. yours) emits such empty libs, and another tool that was working for current UFO3 fails because expects a lib to contain a child

[ctrlcctrlv]

Oh yeah, OK. I'm perfectly fine with pushing this to UFO4, by the way. MFEK is, in general, on a similar very long timeline. The glyph editor will probably be mostly done by the end of the year, but it's an ambitious effort. Won't be built in a day. Especially my days, what with the disability and all.