corrections based on creating example parser (#4)

LanguageSpec.md

@@ -211,10 +211,9 @@ or more tokens, they are considered invalid numeric literals.
 
 So input is first scanned for the `numeric_literal` token type:
 ```ebnf
-numeric_literal = ( "." | decimal_digit ) { digit_or_point }
-                  { ( "e" | "E" ) [ "+" | "-" ] digit_or_point { digit_or_point } } .
+numeric_literal = [ "." ] decimal_digit { digit_point_or_exp } .
 
-digit_or_point = "." | decimal_digit | letter .
+digit_point_or_exp = "." | decimal_digit | ( "e" | "E" ) [ "+" | "-" ] | letter .
 ```
 
 When a `numeric_literal` token is found, it is then checked to see if it matches the `int_literal`
@@ -780,7 +779,7 @@ is because it is not intended to be used as an interchange format -- the binary
 and JSON are intended for that purpose. However, since the text format is used in the
 language for defining message literals, we _need_ a specification:
 ```ebnf
-MessageTextFormat = { MessageLiteralField }
+MessageTextFormat = { MessageLiteralField [ comma | semicolon ] } .
 
 MessageLiteralField = MessageLiteralFieldName colon Value |
                       MessageLiteralFieldName MessageValue .
@@ -791,7 +790,7 @@ SpecialFieldName        = ExtensionFieldName | TypeURL
 ExtensionFieldName      = QualifiedIdentifier .
 TypeURL                 = QualifiedIdentifier slash QualifiedIdentifier .
 
-Value          = ScalarValue | MessageValue | ListLiteral .
+Value          = ScalarValue | MessageLiteral | ListLiteral .
 MessageValue   = MessageLiteral | ListOfMessagesLiteral .
 MessageLiteral = MessageLiteralWithBraces |
                  l_angle MessageTextFormat r_angle .
@@ -1177,7 +1176,7 @@ This is typically to prevent old tag numbers and names from being recycled.
 ```ebnf
 MessageReservedDecl = reserved ( TagRanges | Names ) semicolon .
 
-Names = String { comma String } .
+Names = StringLiteral { comma StringLiteral } .
 ```
 
 Just like extension ranges, the `max` keyword is equivalent to 536,870,911, except for