🏗 SEP 7: Consolidate collection definitions/attributes

Status: Partially Implemented 

Date: 2022-09-16
Commit: 56837160c39d767067cc6567b386c71343c2b5a0
Almost fully implemented. Remaining to do: add reverse sort support, clarify 
terms in build script.

Currently the attributes of a pages collection – made available primarily for the purpose of index-type pages – are defined in two places. A list of

Implementing this proposal would also I lend itself to making another tiny adjustment to the vocabulary of collections. The current vocabulary when defining the collection of eg. an index page is as follows.

...
collections:
  - tag1
  - tag2
  - tag3
options:
  - $COLLECTION_TYPE (one of collection-title, collection-fulltext,
      collection-summary etc)
...

The proposed new format and vocabulary would

• Change collections to collection (singular), more clearly communicating that this becomes a single collection made available during rendering of that particular document.
• Move the $COLLECTION_TYPE option into the collection element.

The new format would thus be

...
collection: 
  type: title OR summary etc
  order: date  OR alphabetical etc
  tags:
    - tag1
    - tag2
    - tag3
...

For conceptual simplicity¹ it would be wise to enforce this vocabulary more strictly in the build pipeline. Example: in the template rendering function the distinction between collections and collection is hard to parse.

output = template.render(data=data, collections=collections, collection=collection, page=page, site=site, search_index=search_index)

The use of tags vs collection must be clarified, likely the plural form (collections) should be entirely replaced with ‘tags’.