misc grammar and avoidance of abbreviations

4 files changed, 22 insertions, 22 deletions

diff --git a/_conclusion.qmd b/_conclusion.qmd
index 859f8e1..688b343 100644
--- a/_conclusion.qmd
+++ b/_conclusion.qmd
@@ -90,7 +90,7 @@ PDF documents support metadata and text-specific annotations stored as XMP
 [@PDFAssociation2020 chapter 14.3, @Adobe2012, p. 9];
 HTML documents support text-specific annotations stored as RDFa
 [@Herman2015].
-Both XMP and RDFa are concrete formulations (serializations)
+Both XMP and RDFa are concrete formulations (serialisations)
 of Resource Description Framework (RDF),
 an abstract language for expressing semantics.
 
@@ -131,9 +131,10 @@ Also,
 Pandoc could extend its AST to block- and inline-specific metadata
 (in addition to the existing document-wide metadata).
 Such change, and consequential refinements of default Pandoc templates
-encouraging more normalized structures e.g. about authors and publishers,
+encouraging more normalized structures,
+for example, about authors and publishers,
 might reduce the amount of custom restructuring
-needed downstream e.g. in Quarto.
+needed downstream, for example, in Quarto.
 
 ### Nuanced citations in scholarly papers
 
@@ -146,4 +147,4 @@ which can likely leverage on this work as well as the planned next phases.
 
 ## Conclusion
 
-*FIXME: ca 10 linier samlet konklusion på hele projektet*
+*FIXME: ~10 lines conclusion on the whole project*
diff --git a/_filter.qmd b/_filter.qmd
index b746141..3b87afb 100644
--- a/_filter.qmd
+++ b/_filter.qmd
@@ -15,11 +15,10 @@ instead of writing an import extension.*
 This project is implemented in the scripting language Lua.
 
 Pandoc filters can be written in any general-purpose language.
-Pandoc provides a JSON serialisation and parsing of its AST,
-some filters are written in Haskell using same libraries as Pandoc itself,
-and others are implemented in Python or Perl.
-Pandoc also offers a JSON serialisation/desrialisation interface for its AST
-allowing for even wider creativity in filter implementations.
+Pandoc provides a JSON serialisation and parsing API for its AST,
+which some filters make use of.
+JSON-based Pandoc filters have been found in active use
+that are written in Haskell (same as Pandoc itself), Python, Perl and Rust.
 
 In recent years, Pandoc has embedded a Lua interpreter
 and offers the alternative of processing Lua filters
diff --git a/_intro.qmd b/_intro.qmd
index ad0d5e4..f63f79c 100644
--- a/_intro.qmd
+++ b/_intro.qmd
@@ -16,12 +16,12 @@ But Markdown can only express structure and hypermedia annotations,
 not semantic annotations.  
 Annotating text differs from annotating the document as a whole
 in that the information is tied to specific text strings.
-A document annotation can say
-e.g. "this document contains strong language somewhere"
-or "this document contains a link to this URL somwehere",
-whereas a text annotation can say
-e.g. "this text string is strongly emphasized"
-or "this text string links to this URL".
+A document annotation can state, for example,
+"this document contains strong language somewhere"
+or "this document contains a link to this URL somewhere",
+whereas a text annotation can state, for example,
+"this text string is strongly emphasized"
+or "this text string links to this URL."
 
 Semantic text annotation
 is the process of applying information about meaning
@@ -49,7 +49,7 @@ by way of a Pandoc filter to handle semantic text annotations.
 
 ## Problem formulation
 
-So,
+Thus,
 **how can Pandoc be extended to support semantic text annotations?**
 
 * What are the core qualities of Markdown,
@@ -114,7 +114,7 @@ however,the latter, if successful, is likely to be far more reliable.
 
 This project aims at introducing new syntax
 while staying close to existing Markdown,
-unlike e.g. SAM that deviates notably from Markdown
+unlike, for example, SAM that deviates notably from Markdown
 [@SAM2018].
 
 Many Markdown processors exist,
diff --git a/_markdown.qmd b/_markdown.qmd
index 928adac..c2cfa9f 100644
--- a/_markdown.qmd
+++ b/_markdown.qmd
@@ -79,16 +79,16 @@ Syntax of `Block`, `Header` and `Paragraph`.
 :::
 
 Reading order matters:
-The syntax diagrams should be read left-to-right and top-to-bottom,
-also at places with choice --
-e.g. the block type `Header` should be tried before `Paragraph`.
+The syntax diagrams should be read from left to right and top to bottom,
+including at points with choices --
+for example, the block type `Header` should be tried before `Paragraph`.
 Otherwise if `Paragraph` syntax was parsed first,
 then it would match both blocks
 because that block type begins with any words,
-including the characters defitive for the `Header` block type.
+including the characters definitive for the `Header` block type.
 In other words,
 these syntax diagrams do *not* represent the more common EBNF grammars
-but instead a parsing expression grammar [@Ford2004],
+but instead, a parsing expression grammar [@Ford2004],
 chosen because context-free grammars are unlikely
 to be able to cover Markdown
 [@MacFarlane2014].