Required `description` rather than `name` field in Class Object
pjhartzell opened this issue · 4 comments
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.
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.
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.
I agree, required name
would be better than description
.