mpi post - fix link formatting

Author: refset

src/pages/blog/bitemporal-traderx-part2.mdx

@@ -26,7 +26,7 @@ In this follow-up post I will share some thoughts about [XTDB](https://xtdb.com)
 This was my first time using XTDB so I had some learning to do. Being a SQL database, most things about XTDB felt quite familiar but it still takes a little time to get used to the temporal syntax (at least you only have to learn it once!).
 After studying the existing TraderX data model and reading the project brief, my instinctive reaction was to start adding dedicated columns to the application's schema for handling various application and auditing timestamps like `traded_at` and `updated_at` - but what a pleasant surprise it was to find out there’s little need for many of these kinds of columns in XTDB - such timestamping is already ubiquitous and all handled under the covers.
 
-The biggest surprise, however, was that because of this built-in functionality, *compared to using a traditional SQL database for recording changes and keeping old versions around, how you interact with an XTDB database remains intuitive* - at least until you need to retrieve the historical data or introduce 'retroactive' updates (e.g. when you discover some past data was incorrect and need to correct it, or when you want to backfill some missing data). Essentially, you are able to use plain INSERT, UPDATE and DELETE statements to modify data as normal, yet you are left with a fully auditable history of all changes across all records _and_ easily review past states.
+The biggest surprise, however, was that because of this built-in functionality, *compared to using a traditional SQL database for recording changes and keeping old versions around, how you interact with an XTDB database remains intuitive* - at least until you need to retrieve the historical data or introduce 'retroactive' updates (e.g. when you discover some past data was incorrect and need to correct it, or when you want to backfill some missing data). Essentially, you are able to use plain INSERT, UPDATE and DELETE statements to modify data as normal, yet you are left with a fully auditable history of all changes across all records _and_ can easily query past states.
 
 Wait - what? History? Yes! You get all the change history for free! Not just what changed when, but a fine-grained ability to query the myriad historical database states exactly as they looked previously. For example, UPDATE statements in XTDB don’t actually overwrite old values - instead they create new entries that are carefully tracked across two time lines - 'valid time' (otherwise known as 'application time') and system time (what you can think of as wall-clock time).
 
@@ -38,7 +38,7 @@ import sliders from '../../assets/blog/bitemporal-traderx.png'
 
 <Image style="width: 100%; margin-left: auto; margin-right: auto" alt='View of TraderX showing SQL overlayed' src={sliders} />
 
-Adding temporal 'sliders' to the TraderX UI was an easy way to expose XTDB's time-travel capabilities. This approach makes it efficient for users of the various blotters and dashboards to quickly observe and scrub through the changing data, compared to alternatives like having to click on some calendar widget to navigate through the history. It's a great way to understand the value that the https://en.wikipedia.org/wiki/Bitemporal_modeling[bitemporal model] can bring: just imagine any existing application with a time slider and how useful that could be for the end user - especially in domains where the end user is making important decisions based on the changing data, and you later want (or need!) to be able to reconstruct the full context behind the decision.
+Adding temporal 'sliders' to the TraderX UI was an easy way to expose XTDB's time-travel capabilities. This approach makes it efficient for users of the various blotters and dashboards to quickly observe and scrub through the changing data, compared to alternatives like having to click on some calendar widget to navigate through the history. It's a great way to understand the value that the [bitemporal model](https://en.wikipedia.org/wiki/Bitemporal_modeling) can bring: just imagine any existing application with a time slider and how useful that could be for the end user - especially in domains where the end user is making important decisions based on the changing data, and you later want (or need!) to be able to reconstruct the full context behind the decision.
 
 Implementing this change required fetching data from multiple joined tables ‘as of’ a certain point in time. This involves a small amount of ceremony, particularly if you want to be able to control specific `valid time` or `system time` views for each table independently. However, if you don't need such detailed control, you can set the as-of time for the entire query quite easily using syntax like `SETTING DEFAULT VALID_TIME AS OF DATE '2020-01-01' ...`