From 1fbc561035fcb1c82c91f777a4860ba1493e2c62 Mon Sep 17 00:00:00 2001 From: Oliver Kopp Date: Tue, 5 Jan 2021 17:08:03 +0100 Subject: [PATCH 1/2] Add special fields ADR Co-authored-by: Oliver Kopp --- ...ement-special-fields-as-seperate-fields.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 docs/adr/0018-implement-special-fields-as-seperate-fields.md diff --git a/docs/adr/0018-implement-special-fields-as-seperate-fields.md b/docs/adr/0018-implement-special-fields-as-seperate-fields.md new file mode 100644 index 00000000000..8466348a5ce --- /dev/null +++ b/docs/adr/0018-implement-special-fields-as-seperate-fields.md @@ -0,0 +1,71 @@ +# Implement special fields as seperate fields + +* Status: proposed +* Date: 2021-01-05 + +## Context and Problem Statement + +How to implement special fields in bibtex databases? + +## Considered Options + +* Special fields as separate fields +* Special fields as keywords +* Special fields as values of a special field +* Special fields as sub-feature of groups + +## Decision Outcome + +Chosen option: "Special fields as separate fields", because comes out best (see below) + +## Pros and Cons of the Options + +### Special fields as separate fields + +Example: +```bibtex +priority = {prio1}, +printed = {true}, +readstatus = {true}, +``` + +* Good, because groups are another view to fields +* Good, because a special field leads to a special rendering +* Good, because groups pull information from the main table +* Good, because hard-coding presets is easier than generic configuration +* Good, because direct inclusion in main table +* Good, because groups are shown with color bars in the main table +* Good, because there are no “hidden groups” in JabRef +* Good, because can be easily removed (e.g., by a formatter) +* Good, because prepares future power of JabRef to make field properties configurable +* Bad, because bloats BibTeX file (see below) +* Bad, because requires more timing (see below) + +### Special fields as keywords + +Example: +```bibtex +keywords = {prio1, printed, read} +``` + +* Good, because does not bloat the BibTeX file. Typically, 50% of the lines are special fields +* Good, because the user can easily assign a special field. E.g, typing “, prio1” into keywords instead of “\n priority = {prio1},” +* Bad, because they need to be synchronized to fields (because otherwise, the maintable cannot render it) +* Bad, because keywords are related to the actual content +* Bad, because some users want to keep publisher keywords + +### Special fields as values of a special field + +Example: +```bibtex +jabrefspecial = {prio1, printed, red} +``` + +* Good, because typing effort +* Bad, because handling in table gets complicated → one field is now multiple columns + +### Special fields as sub-feature of groups + +* Good, because one concept rulez them all +* Good, because groups already have special handling for author names +* Bad, because main table implementation changes From 90fcff0e0142c0567eb8b2ca0d459de0c4b7018b Mon Sep 17 00:00:00 2001 From: Oliver Kopp Date: Thu, 7 Jan 2021 00:24:37 +0100 Subject: [PATCH 2/2] Refine "Special fields as sub-feature of groups" --- ...mplement-special-fields-as-seperate-fields.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/docs/adr/0018-implement-special-fields-as-seperate-fields.md b/docs/adr/0018-implement-special-fields-as-seperate-fields.md index 8466348a5ce..13b4ac73fd5 100644 --- a/docs/adr/0018-implement-special-fields-as-seperate-fields.md +++ b/docs/adr/0018-implement-special-fields-as-seperate-fields.md @@ -1,8 +1,5 @@ # Implement special fields as seperate fields -* Status: proposed -* Date: 2021-01-05 - ## Context and Problem Statement How to implement special fields in bibtex databases? @@ -23,6 +20,7 @@ Chosen option: "Special fields as separate fields", because comes out best (see ### Special fields as separate fields Example: + ```bibtex priority = {prio1}, printed = {true}, @@ -38,12 +36,13 @@ readstatus = {true}, * Good, because there are no “hidden groups” in JabRef * Good, because can be easily removed (e.g., by a formatter) * Good, because prepares future power of JabRef to make field properties configurable -* Bad, because bloats BibTeX file (see below) -* Bad, because requires more timing (see below) +* Bad, because bloats BibTeX file +* Bad, because requires more writing when editing BibTeX manually by hand ### Special fields as keywords Example: + ```bibtex keywords = {prio1, printed, read} ``` @@ -57,6 +56,7 @@ keywords = {prio1, printed, read} ### Special fields as values of a special field Example: + ```bibtex jabrefspecial = {prio1, printed, red} ``` @@ -67,5 +67,7 @@ jabrefspecial = {prio1, printed, red} ### Special fields as sub-feature of groups * Good, because one concept rulez them all -* Good, because groups already have special handling for author names -* Bad, because main table implementation changes +* Good, because groups already provide [explicit handling of certain cases](https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#types-of-groups): groups based on keywords and groups based on author's last names +* Bad, because main table implementation changes: Currently, each column in the main table represents a field. The main may [mark entries belonging to certain groups](https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#group-color-bars-in-the-entry-table), but does offer an explicit rendering of groups +* Bad, because groups are more a query on data of the entries instead of explicitly assigning entries to a group +* Bad, because explicit assignment and unassigment to a group is not supported by the main table