Draft: draft-ietf-jsonpath-base

Commentary: Can you explain how the test scripts work and how to interpret the output , please ? 
 I have n't done the work to make this a real CI script . You clone the JPC to a directory parallel to where you cloned the I - D repo .     - jsonpath- sh ruby scripts / test - abnf- scripts / test - abnf- 2&1 ruby scripts / test - abnf- scripts / test - abnf- 2&1 ruby scripts / test - abnf- scripts / test - abnf- 2&1 ruby scripts / test- scripts / test- 2&1 Compare the output with the checked - in output . ( The output contains all parse failures , including the intentional ones . The word FAIL tells you about unexpected output . ) An output that says " successfully completed " at the end has done exactly that . 
 ~JPC?~ oh ...  path comparison 
 Is this something that should be in the same repo as the spec ? Seems like it should be with a test suite . Or do we plan to remove it before publication ? 
 Indeed -- mentioned json - path - comparison ( which I call JPC ) and jsonpath - compliance - test - suite ( which I call CTS ) . Of course I 'd love to get more test data ... 
 This repo contains everything that is needed to work on the spec document . Testing the ABNF in the spec document is a typical case for including tests with the code . It 's testing the document . The information in there can possibly be used for building test suites , but I 'd rather use the original data in JPC and CTS ( which already is a test suite ) . The test data specifically collected ( test- ) could indeed be used for further testing , but it probably makes more sense to include sample documents and sample query results with that ( which were not needed to test just the ABNF ) . We publish the spec ( as an RFC ) . The repo that creates the spec is public , but not " published " in the stricter sense . 
 Two objectives : ( 1 ) aesthetic cleanup , e.g. : ( 2 ) more tests , e.g. , to be built from query corpora we can find 
 Looks plausible . I have n't reviewed or run the Ruby code .
Paragraph (version A):
The "dot-wildcard-shorthand" is shorthand for "[*]".
Paragraph (version B):
".*", a "child-segment" directly built from a "wildcard-selector", is
shorthand for "[*]".
Paragraph (version B):
".<member-name>", a "child-segment" built from a "member-name-
shorthand", is shorthand for "['<member-name>']".  Note that this can
only be used with member names that are composed of certain
characters, as specified in the ABNF rule "member-name-shorthand".
Thus, for example, "$.foo.bar" is shorthand for "$['foo']['bar']"
(but not for "$['foo.bar']").
Paragraph (version A):
The "descendant-wildcard-shorthand" is shorthand for "..[*]".
Paragraph (version A):
A "descendant-member-name-shorthand" of the form "..<member-name>" is
shorthand for "..['<member-name>']".
Paragraph (version B):
"..*", the "descendant-segment" directly built from a "wildcard-
selector", is shorthand for "..[*]".
Paragraph (version B):
"..<member-name>", a "descendant-segment" built from a "member-name-
shorthand", is shorthand for "..['<member-name>']".  As with the
similar shorthand of a "child-segment", note that this can only be
used with member names that are composed of certain characters, as
specified in the ABNF rule "member-name-shorthand".