Script updating archive at 2024-02-22T01:09:35Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2024-02-18T01:14:07.644899+00:00",
+  "timestamp": "2024-02-22T01:09:33.285293+00:00",
   "repo": "ietf-wg-jsonpath/draft-ietf-jsonpath-base",
   "labels": [
     {
@@ -16861,6 +16861,65 @@
           "updatedAt": "2023-12-20T15:56:52Z"
         }
       ]
+    },
+    {
+      "number": 516,
+      "id": "I_kwDOEIqrgc5_4ahQ",
+      "title": "Syntax for returning a set of indices/keys of an array/object",
+      "url": "https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/516",
+      "state": "OPEN",
+      "author": "gregsdennis",
+      "authorAssociation": "COLLABORATOR",
+      "assignees": [],
+      "labels": [],
+      "body": "[This question](https://stackoverflow.com/q/78024322/878701) popped up on StackOverflow in which the user wants to select the keys present in the resulting object.  To do this, they're expecting to end the query with `~`.\r\n\r\nSo `$.*~` would select all of the items and then return the keys for those items.\r\n\r\nIn a more complex query, you could have `$[[email protected] == 5]~` to find the property names (or array indices) of every child that meets the condition.\r\n\r\nTo date, I've asked what implementation they're using that supports this syntax, but I've yet to receive a result.\r\n\r\nWe also have #324 that proposed a function extension to do this rather than syntax, but there wasn't much discussion there other than the data is available through the location paths in the query result.  The problem with this is that you can't check that until the query is complete.\r\n\r\nI think a benefit of this is that you could continue querying on the property name set.\r\n\r\nBuilding on the more complex example, with an array of objects, if I wanted the index of the third item where `@.foo == 5`, I could do `$[[email protected] == 5]~[2]`.\r\n\r\nLogging for visibility and discussion.  It seems simple enough.  (This would also be the first functionality that actually _uses_ the location data as part of the query.)",
+      "createdAt": "2024-02-21T00:03:05Z",
+      "updatedAt": "2024-02-21T22:12:09Z",
+      "closedAt": null,
+      "comments": [
+        {
+          "author": "glyn",
+          "authorAssociation": "COLLABORATOR",
+          "body": "Returning indices or keys from a JSONPath query could require extending the spec's current notion of a nodelist, since the spec doesn't currently regard an index or a key as a node with a location. I suppose such a location could be defined, for example, by extending Normalized Paths so that they can address an index or a key, e.g. by allowing `~` at the end of a Normalized Path.\r\n\r\nIf the spec was to admit indices and keys as nodes, the definition of the descendant segment would need adjusting.\r\n\r\n> Building on the more complex example, with an array of objects, if I wanted the index of the third item where `@.foo == 5`, I could do `$[[email protected] == 5]~[2]`.\r\n\r\nNot sure what example this refers to, but I have a couple of observations. If that index exists, its value is `2`. Also, the query `$[[email protected] == 5]~[2]` ends with `[2]` although the intermediate result of `$[[email protected] == 5]~` would presumably be a nodelist of indices. So `[2]` would be indexing a nodelist, which is another extension to the spec.",
+          "createdAt": "2024-02-21T07:10:09Z",
+          "updatedAt": "2024-02-21T07:10:09Z"
+        },
+        {
+          "author": "gregsdennis",
+          "authorAssociation": "COLLABORATOR",
+          "body": "> the spec doesn't currently regard an index or a key as a node with a location\n\nTechnically, it's just the last segment of the path to the node, which the implementation should be tracking anyway.\n\n> If the spec was to admit indices and keys as node\n\nI don't think it needs to in order to support this, for the reason above.\n\n> So [2] would be indexing a nodelist, which is another extension to the spec.\n\nYes. That's true. I'll see if I can devise another example.  Extending the segment that way wasn't my intent.",
+          "createdAt": "2024-02-21T07:41:21Z",
+          "updatedAt": "2024-02-21T07:41:21Z"
+        },
+        {
+          "author": "cabo",
+          "authorAssociation": "MEMBER",
+          "body": "I think we already had discussed extensively whether to extend JSONPath from selection to projection, and how member names (or array indices) are not nodes in the JSONPath model.\r\n\r\nYour example may be a bit contrived, but is an indication that we would want to extend the model to cover this kind of use cases:\r\n\r\n> $[[email protected] == 5]~[2]\r\n\r\nIf I translate the intent I gather from this into what we have today, ~ would start a new query by converting the nodelist coming from the previous segment to a new JSON value (containing an array of indices) that serves as the query argument to the `[2]` selection.",
+          "createdAt": "2024-02-21T07:51:56Z",
+          "updatedAt": "2024-02-21T07:51:56Z"
+        },
+        {
+          "author": "jg-rp",
+          "authorAssociation": "NONE",
+          "body": "> To date, I've asked what implementation they're using that supports this syntax, but I've yet to receive a result.\r\n\r\n[Jayway JsonPath](https://github.com/json-path/JsonPath), [JSONPath Plus](https://github.com/JSONPath-Plus/JSONPath) and [Python JSONPath](https://github.com/jg-rp/python-jsonpath) all support using `~` as a keys selector, each with subtly different behaviour.",
+          "createdAt": "2024-02-21T10:41:59Z",
+          "updatedAt": "2024-02-21T10:41:59Z"
+        },
+        {
+          "author": "glyn",
+          "authorAssociation": "COLLABORATOR",
+          "body": "@cabo That's an interesting approach. For the output of `~` to be input to a segment such as `[2]`, wouldn't we have to extend the meaning of such segments to apply to arrays as well as nodelists (with values from the array and locations referring to those values)? That's quite a departure from the current model! \r\n\r\nAlso, if I've understood correctly the array produced by `~` could contain indices and member names, as in the example below.\r\n\r\nValue:\r\n```\r\n[{\"x\": \"a\", \"y\": \"b\"},[1,2]]\r\n```\r\n\r\nQuery:\r\n```\r\n..[*]~[0]\r\n```\r\n\r\ncould produce the value `0`, `\"x\"`, or `\"y\"`.",
+          "createdAt": "2024-02-21T10:52:56Z",
+          "updatedAt": "2024-02-21T10:53:43Z"
+        },
+        {
+          "author": "danielaparker",
+          "authorAssociation": "NONE",
+          "body": "> [Jayway JsonPath](https://github.com/json-path/JsonPath), [JSONPath Plus](https://github.com/JSONPath-Plus/JSONPath) and [Python JSONPath](https://github.com/jg-rp/python-jsonpath) all support using `~` as a keys selector, each with subtly different behaviour.\r\n\r\nJayway supports a `keys()` function as an _alternative_ to the tilde operator, I don't think it supports the tilde operator itself.\r\n\r\nNote that Jayway (and some other implementations) support functions applied to paths, the IETF document restricts them to filter expressions. \r\n\r\n",
+          "createdAt": "2024-02-21T22:07:43Z",
+          "updatedAt": "2024-02-21T22:12:09Z"
+        }
+      ]
     }
   ],
   "pulls": [
@@ -76680,6 +76739,40 @@
           "comments": []
         }
       ]
+    },
+    {
+      "number": 517,
+      "id": "PR_kwDOEIqrgc5nkAvo",
+      "title": "Add codespell config, workflow to avoid adding typos. Fixed few typos still found",
+      "url": "https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/517",
+      "state": "CLOSED",
+      "author": "yarikoptic",
+      "authorAssociation": "NONE",
+      "assignees": [],
+      "labels": [],
+      "body": "",
+      "createdAt": "2024-02-21T19:00:22Z",
+      "updatedAt": "2024-02-21T19:58:11Z",
+      "baseRepository": "ietf-wg-jsonpath/draft-ietf-jsonpath-base",
+      "baseRefName": "main",
+      "baseRefOid": "d6c8d7be0d7146e9db9b3db0d382ba53ede48a93",
+      "headRepository": "yarikoptic/draft-ietf-jsonpath-base",
+      "headRefName": "enh-codespell",
+      "headRefOid": "3a9f0e689bac80e3c26f5d8a812b82508e9c76ef",
+      "closedAt": "2024-02-21T19:58:11Z",
+      "mergedAt": null,
+      "mergedBy": null,
+      "mergeCommit": null,
+      "comments": [
+        {
+          "author": "fiestajetsam",
+          "authorAssociation": "MEMBER",
+          "body": "Thank you for this pull request, however this document is now in the hands of the RFC Editor. I've checked the most recent edit of the document and the spelling errors you've found have already been fixed. Once the document has been published this repository will along with the rest of the organisation be archived and handed over as per RFC 8875.",
+          "createdAt": "2024-02-21T19:58:11Z",
+          "updatedAt": "2024-02-21T19:58:11Z"
+        }
+      ],
+      "reviews": []
     }
   ]
 }