Loading ...
Sorry, an error occurred while loading the content.

RE: [json] JSONPath

Expand Messages
  • Atif Aziz
    JSONPath looks very promising and close in spirit to the simplicity and effectiveness of JSON. I just finished an initial port and implementation in C# (should
    Message 1 of 4 , Aug 31, 2007
    • 0 Attachment
      JSONPath looks very promising and close in spirit to the simplicity and effectiveness of JSON. I just finished an initial port and implementation in C# (should compile and run on just about any platform where a decent C# compiler is available) and which can now be downloaded [1] from the same project site, i.e. http://code.google.com/p/jsonpath/ (thanks, Stefan). Comments and feedback appreciated.

      - Atif

      [1] http://jsonpath.googlecode.com/files/jsonpath-0.5.0.cs

      From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of Stefan Gössner
      Sent: Tuesday, August 28, 2007 5:26 PM
      To: json@yahoogroups.com
      Subject: [json] JSONPath


      In the current process to improve JSONT I implemented a lightweight
      component JSONPath, which compares a lot to XPath.

      You can download it for Javascript and PHP

      http://code.google.com/p/jsonpath/

      and read more about it.

      http://goessner.net/articles/JsonPath/

      Comments are welcome .. thanks.



      [Non-text portions of this message have been removed]
    • Henrik Hjelte
      ... I have a comment about the syntax. It is extremely easy to implement a JSON parser because the syntax is simple. In not only looks good, it is designed to
      Message 2 of 4 , Sep 5, 2007
      • 0 Attachment
        On 8/28/07, Stefan Gössner <stefan@...> wrote:

        > In the current process to improve JSONT I implemented a lightweight
        > component JSONPath, which compares a lot to XPath.
        > Comments are welcome .. thanks.

        I have a comment about the syntax. It is extremely easy to implement a
        JSON parser because the syntax is simple. In not only looks good, it
        is designed to be easy and good to implement.

        For example, a string starts with a double-quote and ends with a
        double-quote. So, when parsing a string there is only one character
        that can end it. It makes the implementation trivial and fast.
        The proposed syntax of JSONPath is not bad but a bit too ambivalent in
        my opinion.

        First, there is a choice of notation. It is simpler to select one and
        stick to that.
        And then the syntax is a bit more difficult than it should be.

        The first syntax:
        $.store.book[0].title

        To end parsing a component you need to look for either a dot, an
        opening square bracket or the end of line or the end of file

        The bracket notation is easier.
        $['store']['book'][0]['title']

        To find the end of a component is easy, it ends with a single quote.
        However there is another thing: after you have parsed an opening
        bracket, you need to peek ahead at the following character to know if
        it is a number or a string that follows.
        Also, since json doesn't use single quotes but double quotes only, I
        would use double quote to make it more similar. It might also make it
        possible to reuse code in various json implementations.

        My idea is the following syntax.
        $"store"."book"[0]."title"

        Just my two cents,
        Henrik
      • Stefan Gössner
        ... One design criterion of the JSONPath syntax proposal is, that simple expressions are also valid in Javascript. That applies to these two expressions above.
        Message 3 of 4 , Sep 6, 2007
        • 0 Attachment
          > First, there is a choice of notation. It is simpler to select one and
          > stick to that.
          > And then the syntax is a bit more difficult than it should be.
          >
          > The first syntax:
          > $.store.book[0].title
          >
          > To end parsing a component you need to look for either a dot, an
          > opening square bracket or the end of line or the end of file
          >
          > The bracket notation is easier.
          > $['store']['book'][0]['title']
          >
          > To find the end of a component is easy, it ends with a single quote.
          > However there is another thing: after you have parsed an opening
          > bracket, you need to peek ahead at the following character to know if
          > it is a number or a string that follows.

          One design criterion of the JSONPath syntax proposal is, that simple
          expressions are also valid in Javascript. That applies to these two
          expressions above. Extensions to that were modelled on E4X and ES4.

          The parsing is not very expensive, when we use regular expressions.

          > Also, since json doesn't use single quotes but double quotes only, I
          > would use double quote to make it more similar. It might also make it
          > possible to reuse code in various json implementations.

          The idea to use JSONPath expressions inside of JSON structures
          intensively seems to favor the choice of single quotes. See

          { "expr": "$['store']['book'][0]['title']" }

          vs.

          { "expr": "$[\"store\"][\"book\"][0][\"title\"]" }

          as an example, where we need to escape all double quotes.

          > My idea is the following syntax.
          > $"store"."book"[0]."title"

          In fact this is also a valid JSONPath expression (with a dot after the
          '$' though), but unfortunately not a valid Javascript expression.

          As the JSONPath proposal is exactly that - a proposal, nothing is set
          in stone. Thanks for your feedback.
          --
          Stefan
        Your message has been successfully submitted and would be delivered to recipients shortly.