Add metadata rules for braille codes

[wfree-aph]

I followed the same template as the other documents. I put it in Best Practices too. I don't think that's necessarily the best location but wasn't sure where to put it. It's not just a suggestion like the other Best Practice documents.

[clapierre]

Should we be using the W3C's MUST, SHOULD, MAY vs. Required & Optional?
Just wondering if we already made this decision or not.

[mattgarrish]

MUST, SHOULD, MAY vs. Required & Optional

Required, recommended, and optional are the same as must, should, and may, so I think this is fine for now. We might want to add a conformance statements section.

I don't think this belongs under the best practices, though. I'd create a /registries/codes directory and put the document there.

I can make some tweaks for the above and adjust some of the respec metadata later this evening.

[mattgarrish]

Here's a quick summary of the changes I made in the last commit:

• moved the document to /registries/code
• reorganized the sections so the list of codes is separate from the rules. I also added a placeholder for explaining the registration process, which we'll need to document
• I added an EBNF definition for the codes. We can look at maybe turning it into something simpler later, but at least we get a formalized definition right at the top this way.
• I updated the brailleSystem property definition in the specification to recommend using values from the registry. I don't think we can make it stronger since that would make it an error to use values that haven't yet been registered.

Registry:

• Preview

eBraille specification:

• Preview
• Diff

[bertfrees]

Oops, I was too slow :/

Sorry for the late review:

I had a bit of a doubt about already adding the "Registered codes" section, because I imagine the process for registering new codes will involve proper reviewing, but this initial list hasn't been reviewed yet. Perhaps it would have been more appropriate to call them "Candidates".

Also, it seems more logical to me to have the definition terms and descriptions swapped in the definition list. E.g:

Afrikaans grade2

Afrikaans contracted

instead of

Afrikaans contracted

Afrikaans grade2

"Afrikaans grade2" is the code, "Afrikaans contracted" is the description of the code.

[wfree-aph]

@bertfrees, those changes make sense. I'm out starting tomorrow. Would you be fine making issues for those changes? I can address them when I get back or if someone else wants to go in and make those changes, they are welcome to do so.

[bertfrees]

I added three new issues:

• Review the list of braille codes before making them officially "registered" #289
• Registered braille codes would benefit from more elaborate explanation / metadata about metadata #290
• Consider using string without spaces for braille code metadata #291

and I'll make a PR to address the first.

[bertfrees]

@wfree-aph Something went wrong here: "The goal is to have a unified system that makes it easier for software developers and braille library mantainers to ... ?"