-
-
Notifications
You must be signed in to change notification settings - Fork 348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add spec/schema to implement mod tags #2034
Conversation
Due to my own concerns that my proposed data structure does not appear similar to other data structures in the CKAN file, I am patching this spec to include these multiple category definitions in an array. Also, as 'type' and 'description' seem like keywords, it's probably best practice to avoid using those as descriptors. I am not sure if it is possible to do it the way I originally had it, but better safe than sorry. |
This patch updates the Schema of the sort column to use an object array. This structure is similar to other structures used in the schema file. Additionally, the descriptors 'type' and 'description' have been changed to improve readability, and the spec file has been changed to reflect this.
My main concern is that there could be a lot of hand-wringing over categories, what they should be, which mods belong in which categories, et cetera. Ontology can be a blood sport to some people. Also, if we have a strict enumeration in the spec that means every new category would have to be accompanied by a revision of the spec. Especially problematic if we want to actually do runtime schema-checking and enforcement. I'd much prefer quasi-freeform tags (restricted to lowercase alphanumerics plus hyphen, i.e. |
Sure thing. I'll have those updates in a jiffy! ...just as soon as I figure out how to spec quasi-freeform tags... 😛 |
This patch alters the structure of the "Sort column" schema to remove the potential problems with ontology inherent to defining "Categories", and redefines it into an array of strings called "Tags" which may be chosen from a predefined list, or custom. Custom tags are restricted to lowercase alphanumerics and hyphens. A list of potential predefined tags may be found in prior commits or in the original issue KSP-CKAN#1021 opened by Andy81le.
@smattiso You'll want the Acceptable:
Unacceptable:
|
0-9! That's what I forgot. 😮 |
No problem, I think I left it off when I first listed the pattern in the previous comment. FYI, for anyone reading this in the future, I intentionally left out uppercase letters ( |
Changes look good to me, but you'll want to update the |
Haven't had my coffee this morning. *fixed |
This patch updates the Example CKAN file section to show example standard tags and custom alphanumeric tags relevant to the project.
Spec.md
Outdated
@@ -372,6 +380,30 @@ This field defaults to `false`, including for `spec_version`s less than | |||
`v1.16`, however CKAN clients prior to `v1.16` would only perform strict | |||
checking. | |||
|
|||
##### tags | |||
|
|||
The `tags` field describes keywords that a user or program may use to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a (v1.23) to indicate that this will only be supported by CKAN clients of version v1.23.0 and higher
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We always go up by two numbers (14, 16, 18, 20, 22). So shouldn't the next be v1.24?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding 1.24...
This patch updates the spec file with classification tags as of CKAN client versions 1.24.0 or higher.
🙄 That's what I get for logging in with my laptop... |
This patch is related to issue #1021