Draft: draft-ietf-jsonpath-base

Commentary: Generally , use " this document " rather than " this specification " . Then use the term specification judiciously . Prefer the term " language " to " platform " . 
 Yep , environment is a nice synonym of platform . Thank you for addressing my concern !
Paragraph (version A):
Additional terms used in this specification are defined below.
Paragraph (version A):
This specification models the argument as a tree of JSON values, each
with its own node.  A node is either the root node or one of its
descendants.
Paragraph (version A):
This specification models the result of applying a query to the
argument as a nodelist (a list of nodes).
Paragraph (version B):
Additional terms used in this document are defined below.
Paragraph (version B):
This document models the argument as a tree of JSON values, each with
its own node.  A node is either the root node or one of its
descendants.
Paragraph (version B):
This document models the result of applying a query to the argument
as a nodelist (a list of nodes).
Paragraph (version A):
's popular JSONPath proposal dated 2007-02-21 JSONPath-orig, builds
on the experience from the widespread deployment of its
implementations, and provides a normative definition for it.
Paragraph (version A):
JSONPath was intended as a light-weight companion to JSON
implementations on platforms such as PHP and JavaScript, so instead
of defining its own expression language like XPath did, JSONPath
delegated this to the expression language of the platform.  While the
languages in which JSONPath is used do have significant
commonalities, over time this caused non-portability of JSONPath
expressions between the ensuing platform-specific dialects.
Paragraph (version A):
The present specification aims to remove platform dependencies and
serve as a common JSONPath specification that can be used across
platforms.  Obviously, this means that backwards compatibility could
not always be achieved; a design principle of this specification is
to go with a "consensus" between implementations even if it is rough,
as long as that does not jeopardize the objective of obtaining a
usable, stable JSON query language.
Paragraph (version B):
's popular JSONPath proposal dated 2007-02-21 JSONPath-orig, builds
on the experience from the widespread deployment of its
implementations, and provides a normative specification for it.
Paragraph (version B):
JSONPath was intended as a light-weight companion to JSON
implementations in programming languages such as PHP and JavaScript,
so instead of defining its own expression language, like XPath did,
JSONPath delegated parts of a query to the underlying runtime, e.g.,
JavaScript's "eval()" function.  As JSONPath was implemented in more
environments, JSONPath expressions became decreasingly portable.  For
example, regular expression processing was often delegated to a
convenient regular expression engine.
Paragraph (version B):
This document aims to remove such implementation-specific
dependencies and serve as a common JSONPath specification that can be
used across programming languages and environments.  This means that
backwards compatibility is not always achieved; a design principle of
this document is to go with a "consensus" between implementations
even if it is rough, as long as that does not jeopardize the
objective of obtaining a usable, stable JSON query language.
Paragraph (version A):
The parsing of a JSON text into a JSON value and what happens if a
JSON text does not represent valid JSON are not defined by this
specification.  Sections RFC8259 and RFC8259 of RFC8259 identify
specific situations that may conform to the grammar for JSON texts
but are not interoperable uses of JSON, as they may cause
unpredictable behavior.  The present specification does not attempt
to define predictable behavior for JSONPath queries in these
situations.
Paragraph (version B):
The parsing of a JSON text into a JSON value and what happens if a
JSON text does not represent valid JSON are not defined by this
document.  Sections RFC8259 and RFC8259 of RFC8259 identify specific
situations that may conform to the grammar for JSON texts but are not
interoperable uses of JSON, as they may cause unpredictable behavior.
This document does not attempt to define predictable behavior for
JSONPath queries in these situations.
Paragraph (version A):
Obviously, an implementation can still fail when executing a JSONPath
query, e.g., because of resource depletion, but this is not modeled
in the present specification.  However, the implementation MUST NOT
silently malfunction.  Specifically, if a valid JSONPath query is
evaluated against a structured value whose size doesn't fit in the
range of exact values, interfering with the correct interpretation of
the query, the implementation MUST provide an indication of overflow.
Paragraph (version B):
Obviously, an implementation can still fail when executing a JSONPath
query, e.g., because of resource depletion, but this is not modeled
in this document.  However, the implementation MUST NOT silently
malfunction.  Specifically, if a valid JSONPath query is evaluated
against a structured value whose size doesn't fit in the range of
exact values, interfering with the correct interpretation of the
query, the implementation MUST provide an indication of overflow.
Paragraph (version A):
In this specification, the semantics of a JSONPath query define the
required results and do not prescribe the internal workings of an
implementation.
Paragraph (version B):
In this document, the semantics of a JSONPath query define the
required results and do not prescribe the internal workings of an
implementation.