Bridging the requirement discussions in the encoder section

In the last meeting we tentatively decided to describe the "conditional normativity" of conforming (i.e. well-behaved) font encodings at the highest level of abstraction: Such encodings must behave the same as the whole font would relative to any given font subset description and the entire font should be available at the end of any given path through the patch graph (definition of "entire font" TBD).

My worry about this has been that I think of some of the less abstract aspects of the prototype and earlier specifications, such as the closure requirement, as, well, requirements. Things you probably can't avoid if you want the encoded font to behave correctly. The specific worry is that if we just say "it needs to behave the same way", someone implementing an encoder might think "well, sure!" but then not think enough about what that entails and how hard it might be to get that result.

After thinking about this more, I've come up with a sort of editorial formula that works for me and that I hope will work with the other editors. And that's just to give an example (abstract or concrete) in each relevant section that says "If you don't do this, this and this can happen, which means the behavior of the font will be different for this font subset description". Or "...this aspect of the source font will not be included in this 'terminal' patch" (or whatever). Basically, make it clear how what is being described is hard to get around by providing a clear example of how the abstract requirement isn't met when one attempts to. It may get a little repetitive, but it ensures that everything is tied together without having to resort to "musts".

Skef