Required `description` rather than `name` field in Class Object

[pjhartzell]

More of a comment than an issue. I'm finding that I would prefer to have name, rather than description, be required in the Class Object.

In many cases, just a word or two is a sufficient description, which makes for a nice “machine readable” name designation when combined with underscores. If more context is necessary than can be communicated in just a few words, you can add a description with more expansive text. Except that is not how it works - the description is always required.

I suppose this gets into the question of how useful a short name field is. I'd be interested to hear others' thoughts on this.

You can always include both the name and description for consistency, but you often end up with virtually identical name and description fields, which seems wasteful.

[drwelby]

The idea was that description could be anything, machine readable or not, while name was a fallback for machine readable alternatives. Since names and descriptions are often interchangeable it seemed a slightly better fit to use description as the catch-all, and reserve name for something more specific and unique. And I think the earliest drafts all were value and description and name added later.

I'm not sure I want to switch them, I'd almost rather deprecate name. But if everyone finds the distinction to be opposite of expectations I'm open to the idea.

[gadomski]

Personally I find "machine readable" (which is a funny term) more useful than a free-text field, since it's common to want to filter data by class, in which case a short non-whitespace string is more useful as a query parameter/dictionary key/whatever.

[m-mohr]

I agree, required name would be better than description.

[m-mohr]

I created PR #35 for your convenience and discussions.