Draft: draft-ietf-jsonpath-base

Commentary: Any parameter type works with 
 Indeed . We could make the example more general by not talking about the parameter type there . 
 Or by adding a bit variety . Done . 
 How does this work with a parameter ? 
 It does n't . Example needs to be fixed . Thanks . 
 Ref : Currently is not allowed . The argument is that we 've not defined as resulting in a instance ( an artifact of not extending the type system to the whole expression ) , but I do n't really see a problem with allowing it . It 's pretty intuitive . I can see applications where you 'd want an argument to a function to be whether a location in a path is a certain value , e.g. . An function could work this way . 
 If we extend the use of the type system in this way ( any would be of type , possibly after implicit conversion from ) , we should also roll out the other types across the spec . Then any would have type and any would have type . This fixes a bug in the current spec which I 've only just noticed . The and functions are assumed to be able to take Singular Queries , but as the spec is currently written , these would need converting to using the function . 
 Thanks . Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend ... 
 I can next work on implementing this issue on Saturday . 
 PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec . 
 Approving with several suggestions that I believe will complete the remaining editorial work . ( I raised some editorial nits unrelated to this PR in issue )
Paragraph (version A):
This section defines the extension point as well as four function
extensions that use this extension point.  While these mechanisms are
designed to use the extension point, they are an integral part of the
JSONPath specification and are expected to be implemented like any
other integral part of this specification.
Paragraph (version B):
This section defines the extension point as well as some function
extensions that use this extension point.  While these mechanisms are
designed to use the extension point, they are an integral part of the
JSONPath specification and are expected to be implemented like any
other integral part of this specification.
Paragraph (version A):
A function argument is a "filter-query" or a "comparable".
Paragraph (version A):
According to filter-selector, a "function-expr" is valid as a
"filter-query" or a "comparable".
Paragraph (version A):
If the nodelist contains one or more nodes, the conversion
result is "LogicalTrue".
Paragraph (version A):
If the nodelist is empty, the conversion result is
"LogicalFalse".
Paragraph (version A):
Given an expression with a declared type of "NodesType", a
"ValueType" can be obtained using a function such as "value()" (see
value).
Paragraph (version B):
If the nodelist contains one or more nodes, the conversion result
is "LogicalTrue".
Paragraph (version B):
If the nodelist is empty, the conversion result is "LogicalFalse".
Paragraph (version B):
Extraction of a value from a nodelist can be performed in several
ways, so an implicit conversion from "NodesType" to "ValueType" may
be surprising and has therefore not been defined.  A function
expression with a declared type of "NodesType" can indirectly be used
as an argument for a parameter of declared type "ValueType" by
wrapping the expression in a call to a function extension such as
"value" (see value).
Paragraph (version A):
If it occurs directly in a test expression, the function is
declared to have a result type of "LogicalType", or (conversion
applies) "NodesType".
Paragraph (version A):
Otherwise, it occurs as an argument in another function
expression, and the following rules for function arguments apply
to its declared result type.
Paragraph (version A):
The argument is a function expression with declared result type
"NodesType" and the declared type of the parameter is
"LogicalType".  In this case the argument is converted to
"LogicalType".
Paragraph (version A):
The argument is a value expressed as a literal and the defined
type of the parameter is "ValueType".
Paragraph (version A):
The argument is a query and the declared type of the parameter
is "NodesType".
Paragraph (version A):
The argument is a query and the declared type of the parameter
is "LogicalType".  In this case the argument is converted to
"LogicalType".
Paragraph (version B):
If the function expression occurs as a "test-expr" in a logical
expression, the function is declared to have a result type of
"LogicalType", or (by conversion as per type-conv) "NodesType".
Paragraph (version B):
If the function expression occurs directly as a "comparable" in a
comparison, the function is declared to have a result type of
"ValueType".
Paragraph (version B):
Otherwise (the function expression occurs as an argument in
another function expression), the following rules for function
arguments apply to its declared result type.
Paragraph (version B):
The arguments of the function expression are well-typed, as
follows.
Paragraph (version B):
The argument is a function expression with declared result type
"NodesType" and the declared type of the parameter is
"LogicalType".  In this case the argument is converted to
"LogicalType" as per type-conv.
Paragraph (version B):
The argument is a value expressed as a literal and the declared
type of the parameter is "ValueType".
Paragraph (version B):
If the query results in a nodelist consisting of a single node,
the argument is the value of the node.
Paragraph (version B):
If the query results in an empty nodelist, the argument is
"Nothing".
Paragraph (version B):
The argument is a query (including singular query) and the
declared type of the parameter is "NodesType".
Paragraph (version B):
The argument is a "logical-expr" and the declared type of the
parameter is "LogicalType".
Paragraph (version B):
Note that the last bullet item includes the case that the argument is
a query (including singular query) and the declared type of the
parameter is "LogicalType".  In this case the nodelist resulting from
the query is interpreted as a logical-expr in the same way (extest)
it would be converted to "LogicalType" as per type-conv.
Paragraph (version A):
Its only argument is an instance of "ValueType" (possibly taken from
a singular query as in the example above).  The result also is an
instance of "ValueType": an unsigned integer or "Nothing".
Paragraph (version B):
Its only argument is an instance of "ValueType" (possibly taken from
a singular query, as in the example above).  The result also is an
instance of "ValueType": an unsigned integer or "Nothing".
Paragraph (version A):
Its arguments are instances of "ValueType".  If the first argument is
not a string or the second argument is not a string conforming to I-
D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse".
Otherwise, the string that is the first argument is matched against
the iregexp contained in the string that is the second argument; the
result is "LogicalTrue" if the string matches the iregexp and
"LogicalFalse" otherwise.
Paragraph (version B):
Its arguments are instances of "ValueType" (possibly taken from a
singular query, as for the first argument in the example above).  If
the first argument is not a string or the second argument is not a
string conforming to I-D.draft-ietf-jsonpath-iregexp, the result is
"LogicalFalse".  Otherwise, the string that is the first argument is
matched against the iregexp contained in the string that is the
second argument; the result is "LogicalTrue" if the string matches
the iregexp and "LogicalFalse" otherwise.
Paragraph (version A):
Its arguments are instances of "ValueType".  If the first argument is
not a string or the second argument is not a string conforming to I-
D.draft-ietf-jsonpath-iregexp, the result is "LogicalFalse".
Otherwise, the string that is the first argument is searched for at
least one substring that matches the iregexp contained in the string
that is the second argument; the result is "LogicalTrue" if such a
substring exists and "LogicalFalse" otherwise.
Paragraph (version B):
Its arguments are instances of "ValueType" (possibly taken from a
singular query, as for the first argument in the example above).  If
the first argument is not a string or the second argument is not a
string conforming to I-D.draft-ietf-jsonpath-iregexp, the result is
"LogicalFalse".  Otherwise, the string that is the first argument is
searched for at least one substring that matches the iregexp
contained in the string that is the second argument; the result is
"LogicalTrue" if such a substring exists and "LogicalFalse"
otherwise.
Paragraph (version A):
Its only argument is an instance of "NodesType" (possibly taken from
a "filter-query" as in the example above).  The result is an instance
of "ValueType".
Paragraph (version B):
Its only argument is an instance of "NodesType" (possibly taken from
a "filter-query", as in the example above).  The result is an
instance of "ValueType".
Paragraph (version B):
Note: a Singular Query may be used anywhere where a ValueType is
expected, so there is no need to use the "value" function extension
with a Singular Query.