Clarify the language around parsing scenarios to avoid

versions/3.0.4.md

@@ -147,7 +147,7 @@ When parsing an OAD, JSON or YAML objects are parsed into specific Objects (such
 
 In version 2.0 of this specification, this section specified that the OAD is a "single file", which (together with the treatment of `$ref` as a URL resolved separately each time it is encountered), resulted in the common interpretation that if the same object is parsed multiple times in contexts that require it to be parsed as _different_ Object types, then as long as the reference target is valid for each Object type, then there is no error.  An example would be parsing an empty JSON object as a reference target twice: Once as a Path Item Object and once as a Schema Object.  Since both Object types allow empty objects, this is syntactically valid for both Objects.
 
-This approach to conflicting contexts remains valid in version 3.0, although it is not required by this version's text.  However, it is RECOMMENDED that description authors avoid such scenarios to maximize the portability of their OADs across tools, and to version 3.1, where the result of such conflicting contexts is _implementation-defined_ and MAY be treated as an error.
+This approach to conflicting contexts remains valid in version 3.0, although it is not required by this version's text.  However, it is RECOMMENDED that description authors avoid scenarios involving conflicting contexts to maximize the portability of their OADs across tools, as well as to version 3.1 where the result of such conflicting contexts is _implementation-defined_ and MAY be treated as an error.
 
 ### <a name="dataTypes"></a>Data Types