docs: Switch to Competency Taxonomy table to indicate taxonomy type instead of new field in Taxonomy table, indicate that Competency Taxonomies can be displayed in the existing Taxonomy UI screens, updated/removed unnecessary images

Author: mgwozdz-unicon

docs/decisions/0022-competency-criteria-model.rst

@@ -12,21 +12,26 @@ Additionally, we need to be able to track each learner's progress towards compet
 Decision
 --------
 
-1. Update `oel_tagging_taxonomy` to have a new column for `taxonomy_type` where the value could be “Competency” or “Tag”.
+1. Add a new database table for `oel_competency_taxonomy` to track which Taxonomies are to be used as "Competency" taxnomies as opposed to as a generic tag.
 
-   A taxonomy with a `taxonomy_type` of "Competency":
+   A taxonomy listed in this table:
 
    - is able to be displayed in the UI with the competency criteria association view.
    - will be able to be displayed in the UI with the competency progress tracking view(s).
+   - is able to be displayed in the UI with the existing Taxnomy views.
    - has constraints on its associated content objects to only be those supported for progress tracking
    - has contrainsts on its associated content objects to only include ones that could logically be used to demonstrate mastery of the competency (for example, it would not make sense to have a competency associated to both a course and a subsection assignment within that course because then there's no way to know if it's the final course grade or just that one assignment that needs to be tracked for mastery).
 
-   In contrast, a taxonomy with a `taxonomy_type` of "Tag":
+   In contrast, a taxonomy that is not listed in this table:
 
    - is only displayed in the UI with the existing Taxonomy view, not able to be displayed in the UI with the competency criteria association view.
    - is not able to be displayed in the UI with the competency progress tracking view(s).
    - has no constraints on its associated content objects, and can be associated with any course content object.
 
+   This new database table will have the following columns:
+   1. `id`: unique primary key
+   2. `oel_tagging_taxonomy_id`: Foreign key to `oel_tagging_taxonomy.id` to identify which taxonomy is being designated as a competency taxonomy.
+
 2. Add new database table for `oel_competency_criteria_group` with these columns:
 
    1. `id`: unique primary key
@@ -147,8 +152,22 @@ This allows authors to set a single default rule for most tagged content, and on
 
 Rejected Alternatives
 ---------------------
+1. Update `oel_tagging_taxonomy` to have a new column for `taxonomy_type` where the value could be “Competency” or “Tag”.
 
-1. Same as above except combine the `oel_competency_criteria` and `oel_tagging_objecttag` tables by adding the rule information as columns on the `oel_tagging_objecttag` table. This would be a more denormalized approach that would reduce the number of joins needed to retrieve competency achievement criteria information but would add complexity to the `oel_tagging_objecttag` table and make it less flexible for other uses.
+   1. Pros
+   
+      1. Simpler model with fewer tables
+      2. Reuses existing taxonomy table and keeps reads straightforward when checking taxonomy usage
+      3. Avoids introducing an additional join for queries that only need to know whether a taxonomy is competency-enabled
+   2. Cons
+   
+      1. Couples CBE concerns directly into the generic tagging domain model, reducing separation of concerns
+      2. Makes `oel_tagging_taxonomy` less generic and encourages enum/flag growth as new specialized usages are added
+      3. Prevents strong foreign key guarantees for CBE tables, since they can only point to `oel_tagging_taxonomy` and not specifically to competency-enabled taxonomies
+      4. Makes it harder to keep competency features optional for deployments that only want generic tagging
+      5. Increases risk of future refactor/migration work if the competency domain later needs to be split from tagging
+
+2. Same as above except combine the `oel_competency_criteria` and `oel_tagging_objecttag` tables by adding the rule information as columns on the `oel_tagging_objecttag` table. This would be a more denormalized approach that would reduce the number of joins needed to retrieve competency achievement criteria information but would add complexity to the `oel_tagging_objecttag` table and make it less flexible for other uses.
 
    1. Pros
 
@@ -165,12 +184,7 @@ Rejected Alternatives
       6. Performance risk if the objecttag table becomes very large and is queried for both generic tagging and competency criteria use cases with mostly-null criteria fields.
       7. Future rule types may require different fields, further bloating `objecttag` and reducing performance for non-competency use cases.
 
-   .. image:: images/CompetencyCriteriaModelAlternative2.png
-      :alt: Competency Criteria Model Alternative 2
-      :width: 80%
-      :align: center
-
-2. Add a generic oel\_tagging\_objecttag\_metadata table to attempt to assist with pluggable metadata concept. This table would have foreign keys to each metadata table, currently only assessment\_criteria\_group and assessment\_criteria as well as a type field to indicate what metadata table is being pointed to.  
+3. Add a generic oel\_tagging\_objecttag\_metadata table to attempt to assist with pluggable metadata concept. This table would have foreign keys to each metadata table, currently only assessment\_criteria\_group and assessment\_criteria as well as a type field to indicate what metadata table is being pointed to.  
 
    1. Pros
 
@@ -179,12 +193,7 @@ Rejected Alternatives
 
       1. Adds additional overhead to retrieve specific metadata
 
-   .. image:: images/CompetencyCriteriaModelAlternative.png
-      :alt: Competency Criteria Model Alternative
-      :width: 80%
-      :align: center
-
-2. Split rule storage into per-type tables (for example, `competency_criteria_grade_rule` and `competency_criteria_mastery_rule`) instead of a single JSON payload.  
+4. Split rule storage into per-type tables (for example, `competency_criteria_grade_rule` and `competency_criteria_mastery_rule`) instead of a single JSON payload.  
 
    1. Pros