Draft: draft-ietf-jsonpath-base

Commentary: Lots of niggly details re blank space . Style consistency , some missing places ( assuming we stick with the liberal approach ) . Allowing " in " before or after a newline or tab . Adding some legend to the only remaining table with XPath content in the main document . 
 [ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be ( Do not use the term " whitespace " any more . ) Task " T1 " in the document 
 and 
 From the document : ( whitespace is now generally called blank space , but that does n't change the work to be done . ) 
 and 
 How much do we want to reference XPath within the spec ? I understand that XPath is the inspiration ( and in the tagline that used in his blog post : " XPath for JSON " ) , but I wonder if much of this can be left out of the spec . The argument for this is that we 're defining JSONPath . It should n't assume any understanding of XPath or any other technology . It 's not the job of the specification to convince readers to use it . It 's the job of the specification to define the technology . I 'm perfectly happy moving this into an external " Understanding JSONPath " website at some point . 
 I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix , with the possible exception of the overview table ( but that could be duplicated ) . 
 The XPath inclusion was moved into an appendix . 
 Do we allow spaces ( outside of string literals ) ? If so , where is whitespace allowed ? I think whitespace in query expressions should be allowed . This would fall in to the context of the . Maybe inside the union/ selector : Are there any other places where whitespace could be considered useful ? 
 It may be convenient to allow spaces between matchers - to allow well - readable multi - line queries for complex cases . 
 Looks like the allows whitespace internally , so that ( with leading and trailing whitespace ) is valid . 
 Closed in and 
 What was the resolution here ? Where did we end up allowing whitespace ?
Paragraph (version A):
The examples in tbl-example use the expression mechanism to obtain
the number of elements in an array, to test for the presence of a
member in a object, and to perform numeric comparisons of member
values with a constant.
Paragraph (version B):
The examples in tbl-example use the expression mechanism to obtain
the number of elements in an array, to test for the presence of a
member in a object, and to perform numeric comparisons of member
values with a constant.  For further illustration, the table shows
XPath expressions that would be used with a comparable XML document;
see also xpath-overview.
Paragraph (version A):
Next, "[*]" selects from any input node -- either an array or an
object -- all its elements or members.  The result is a list of three
nodes: "{"b":0}", "{"b":1}", and "{"c":2}".
Paragraph (version B):
Next, "[*]" selects from an input node of type array all its elements
(if the input note were of type object, it would select all its
member values, but not the member names).  The result is a list of
three nodes: "{"b":0}", "{"b":1}", and "{"c":2}".