Вы, вероятно, на правильном пути. В общем, имена классов и атрибутов должны в значительной степени соответствовать спецификации, и вы должны включить ссылки на спецификацию в документацию XML. Сопоставляя имена, человек, знакомый со стандартом, может легче понять, что делает код.
Я бы настоятельно рекомендовал включить модульные тесты для всего проекта. Это не только поможет вам сохранить целостность каждой сборки, но и обнажит области, которые не так удобны, как должны быть. Например, если вам нужно использовать запутанную путаницу классов и методов, чтобы просто запросить аутентификацию для чего-то, то вам нужно реорганизовать ее, чтобы было проще для потребителя библиотеки.
В принципе, ваши приоритеты должны быть в следующем порядке:
- Рабочий код
- Простота в использовании
- Документация
- Соответствует спецификации
Кроме этого, у вас есть свобода применять его по своему усмотрению. Вы можете заметить, что есть некоторые домены, которые имеют множество разных библиотек, которые выполняют одно и то же разными способами. Это хорошо, потому что разные люди любят разные вещи. Некоторые люди захотят использовать библиотеку, которая отражает спецификацию, в то время как другие захотят использовать библиотеку с хорошей документацией, которая может быть трудной в использовании. Другие просто хотят что-то, что будет работать с несколькими строками кода и не мешать им. Это во многом зависит от ваших убеждений по этому вопросу. Вы не можете угодить им всем, но просто выберите путь и бегите по нему.
Тем не менее, я бы рекомендовал против чрезмерного пространства имен. Людям гораздо проще сделать include MyOpenAuth, чем включать 3 разных пространства имен. Используйте их там, где это кажется логичным, но в целом концепцию открытой аутентификации можно считать ее собственной предметной областью (под эгидой единого пространства имен). Но это зависит от вас.