fix markdown list fmt

docs/seqcol_rationale.md

@@ -5,6 +5,7 @@
 The Refget Sequence Collections standard specification is written mostly to answer the question of *how* to implement the standard, rather than explaining *why* we designed the standard the way we did. But because there are many different use cases and perspectives with an interest in sequence collections, several readers of the specification have completed reading it and understand how to do it, but are confused about why we made some of the decisions we did, particularly because the specification doesn’t perfectly fit with their expectations of the easiest way to solve their specific use case. This document is my attempt to broaden the perspective, provide the rationale for *why* on some of the more controversial decisions, and hopefully convince readers that the years of thought and discussion that went into sequence collections was useful and created a standard that, although not necessarily the easiest or simplest way to solve one particular use case, is an elegant balance between complexity and simplicity that allows it to solve a huge number of related use cases while maintaining interoperability wherever possible and flexibility when truly needed.
 
 More specifically, this document attempts to answer these questions:
+
 - Why should the specification include a specific recommended schema, with a defined set of terms, including which are *required* (must exist) and which are *inherent* (affect the outcome of the digest)?
 - Why is there not a digest for <insert my use case here>, so I can just compare two strings to see if the sequence collections are the same? Why do you need these more complex digests that make my comparison harder?
 - What is the purpose of the comparison function, which seems more complicated than a simple string match?