BIP88: clarifications, mistype fixes

Author: dgpv

bip-0088.mediawiki

@@ -91,17 +91,17 @@ installation of malicious or incorrect profiles, though.
 
 The format for the template was choosen to make it easy to read, convenient and visually unambigous. 
 
-Template starts with optional prefix "m/", and then one or more sections delimited by the slash character ("/").
+Template starts with optional prefix "m/", and then one or more sections delimited by the slash character (<code>/</code>).
 
 Implementations MAY limit the maximum number of sections.
 
-Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe ("'") or letter "h".
+Each section consists of ''index template'', optionally followed by the hardened marker: either an apostrophe (<code>'</code>) or letter "h".
 
 Index template can be:
 
 * An integer value from 0 to 2147483647 ("Unit index template")
 * A single "*" character, which denotes any value from 0 to 2147483647 ("Wildcard index template")
-* The <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (","), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
+* The <nowiki>"{"</nowiki> character, followed by a number of ''index ranges'' delimited by commas (<code>,</code>), followed by <nowiki>"}"</nowiki> character ("Ranged index template")
 
 Implementations MAY limit the maximum number of index ranges within the Ranged index template.
 
@@ -125,12 +125,12 @@ Constraints:
 # To avoid ambiguity, whitespace MUST NOT appear within the path template.
 # Commas within the Ranged index template MUST only appear in between index ranges.
 # To avoid ambiguity, an index range that matches a single value MUST be specified as Unit range.
-# To avoid ambiguity, an index template that matches any value from 0 to 2147483647 MUST be specified as Wildcard index template
+# To avoid ambiguity, an index range <code>0-2147483647</code> is not allowed, and MUST be specified as Wildcard index template instead
 # For Non-unit range, range_end MUST be larger than range_start.
 # If there is more than one index range within the Ranged index template, range_start of the second and any subsequent range MUST be larger than the range_end of the preceeding range.
 # To avoid ambiguity, all representations of integer values larger than 0 MUST NOT start with character "0" (no leading zeroes allowed).
 # If hardened marker appears within any section in the path template, all preceding sections MUST also specify hardened matching.
-# To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either "h" or "'").
+# To avoid ambiguity, if a hardened marker appears within any section in the path template, all preceding sections MUST also use the same hardened marker (either <code>h</code> or <code>'</code>).
 # To avoid ambiguity, trailing slashes (for example, "1/2/") and duplicate slashes (for example, "0//1") MUST NOT appear in the template.
 
 It may be desireable to have fully unambiguous encoding, where for each valid path template string, there is no other valid template string that matches the exact same set of paths. This would enable someone to compare templates for equality through a simple string equality check, without any parsing.
@@ -139,7 +139,7 @@ To achieve this, two extra rules are needed:
 
 * Within Ranged index template, subsequent range MUST NOT start with the value that is equal to the end of the previous range plus one. Thus, <nowiki>"{1,2,3-5}"</nowiki> is not allowed, and should be specified as <nowiki>"{1-5}"</nowiki> instead. This rule might make templates less convenient for frequent edits, though.
 
-* Only one type of hardened marker should be allowed (either "h" or "'").
+* Only one type of hardened marker should be allowed (either <code>h</code> or <code>'</code>).
 
 Instead of requiring the second extra rule, implementations can simply replace one type of marker with another in the template strings before comparing them.
 
@@ -191,7 +191,7 @@ The specification can be used with TLC checker and accompanying script to genera
 
 While the formal specification specifies an FSM, which would be convenient for implementation without access to rich string handling facilities, when such facilities are available, the implementation might use the whole-string deconstruction approach where the templates are first split into sections, then sections are split into index templates, and then each index template are parsed individually.
 
-A FSM-based approach can be made close to the formal specification, though, and the test data generated with TLC checker would give much better coverage for a FSM based implementation. If the template string contains several errors, an implementation that uses deconstruction apporach might detect some of these errors earlier than FSM-based implementation, and vise versa.
+A FSM-based approach can be made close to the formal specification, though, and the test data generated with TLC checker would give much better coverage for a FSM based implementation. If the template string contains several errors, an implementation that uses deconstruction approach might detect some of these errors earlier than FSM-based implementation, and vise versa.
 
 At the moment, three implementations exist: