Let's talk about IETF standardization of JSONPath #70
Comments
|
In fact, I see two basic possible goals:
I believe that first option is useless, because implementations would not cut off the power they had already implemented and thus we'll end in having non-standard "extensions" of core standard. I don't see any profits in it. @cburgmer 's work on calculating consensus clearly discovered that "bloodless" transfer to anything but very minimalistic subset of current inmplementations' functionality is impossible. If we follow the second option, we in fact declare that we're creating a new tool based on JSONPath ideas, partially compliant with existing implementations. That leaves to JSONPath implementors two viable options:
If JSONPath users could be satisfied with less powerful, but standard tool - they'd choose JSON Pointer. That's why I stand for the second option. |
|
I agree with @remorhaz, the first option is not an option, a JSONPath standard should be built on existing consensus, therefore we should work to add some constraints on corner cases and ill formed paths (e.g. I think nearly no one will complain if we forbid I think we should work towards opening an issue for each macro group/topic, like I did here: ietf-wg-jsonpath/draft-ietf-jsonpath-base#9, ietf-wg-jsonpath/draft-ietf-jsonpath-base#8. I mention some further macro categories that should be discussed:
If you all agree I think we should continue any further discussion here and start opening more issues. |
|
Thanks @cabo for raising this topic! I believe there are four short-term goals:
I plan to join the IETF 108 meeting today. |
|
Hi Glyn, formally, IETF WGs do not create test suites and reference implementations as an IETF product (well, reference implementations they sometimes do, as well as some test vectors, but I think the effort needed here goes beyond what we would put in an RFC). But that does not have to discourage us from considering those as parts of the package. I.e., we could make it explicit that we don't want to create a specification without having the other pieces in place. We also would want to make sure the specification actually stands for itself, i.e., you don't have to consult any reference implementation to build another. An IETF specification will by definition be developed in the open, let's make sure that happens for the reference implementations and test suites as well. My slides for today are at http://slides.cabo.space right now -- there is still a window of a couple hours where I should be able to update them, if needed. See you at the DISPATCH meeting! |
|
Hi @cabo I'm not sure how much we'll be able to cover in the meeting today, so let me dump my current thoughts here and please feel free to update your slides if appropriate.
See you later! |
|
Hi Glyn, thank you for putting this in!
The meeting starts soon, so I’ll be a bit terse and only reply to some points, but let’s keep up the discussion.
Grüße, Carsten
• The group which I assembled in June consists of 19 people who are mostly implementers/maintainers of JSONPath implementations, including @cburgmer of JSONPath comparison fame. There are only a couple of users AFAIK, so we certainly need to expand the number of users in a WG. So far three of have expressed a willingness to help with the writing of an Internet Draft while four more are happy to review. (The other 12 seem to be taking a back seat for now but I know that some of them are keen to adopt any future standard in their implementations.)
Good. Typically Internet-Drafts with this number of contributors have a small number of editors (2, 3, 4) and a list of contributors listed.
We also have some interesting users lined up to join the effort; I’m really thrilled at this point.
• I created a github organsation https://github.com/jsonpath-standard for developing an internet draft and we have made some progress with a draft document, although currently I'm the only active author (although others hope to find the time). I would happily transfer ownership of this organisation to yourself if that would be helpful. (Similarly, although the draft we've been developing has my name in the filename, I'd be delighted to see Stefan Göessner's name there instead as in your draft.) I'd also personally be happy to restart the https://github.com/jsonpath-standard/internet-draft repository from scratch so that a fresh start could be made by the assembled WG, although I haven't asked the others how they would feel about that. Alternatively, if you or the IETF prefer another location for the actual editing work, that's fine.
That will be for the WG chairs to decide. I’m not going to be a WG chair for this; I would like to push this forward from the editor side. So let’s see who wants to be WG chair. If there is a new group, we’ll probably look for an experienced IETFer plus some more on the side of the specialization of the WG.
• I believe our draft has made a good start in sorting out how to standardise the syntax and in particular the semantics and I'd be happy for any of this to be built upon if that would be helpful (although I still need to obtain sign-off from my employer before my contributions could be officially published, although this should be a formality).
We often have these release processes, that is usually just a matter of scheduling for them when considering deadlines.
I think we’ll need to discuss structure and content of the specification before plunging right in there. I see we have two straw men right one (one actually an Internet-Draft) that actually complement each other and could be merged. But that is not something we want to rush (as in: “this week” :-), especially in the middle of summer vacations.
• I'm a bit fuzzy on precisely how an IETF WG runs and whether the spec work is anticipated to take just a few months or quite a bit longer. I'd be happy to be involved for 6 months, but I can't necessarily commit to a longer term. Any clarification of the likely velocity of the spec work would be really helpful.
My experience is that we could be done at the end of the year from a technical perspective, but then we’d need another 6 months of patience for going through the approval and publication processes (no worries, I’ve been through this before). That is about as fast as it gets; if we have any technical hangups, it will take longer. So I think it would be good to budget the time we can invest in this, both in an absolute way and in terms of the real-time component.
Grüße, Carsten
|
|
Quick report from the meeting today: A JSONPath mailing list will be created, we get to discuss a charter for a new WG there, and then the DISPATCH group will decide if that is good to go. A little more process than I'd like to have, but still manageable. We can do this during the summer lull. More later. |
|
So we now have a mailing list. This is important as the IETF is set up to make decisions on mailing lists, and while the detailed wordsmithing is likely to happen on github, the mailing list provides a better way to include other IETFers into the more high-level decisions. Please subscribe if you care about the standardization project. Work on the charter is likely to happen in earnest when people have subscribed (and IETF108 is over). I'll make a first proposal. Announcement copied below, with subscription link. A new IETF non-working group email list has been created. List address: jsonpath@ietf.org Purpose: |
|
@cabo In your slide "Aren't there other ways to do this?", a notable omission is JMESPath. JMESPath is a query language for transforming JSON documents into other JSON documents. It's supported in both the AWS and Azure CLI and has libraries available in a number of languages. Unlike JSONPath, which is an ad hoc creation, it has a formal spec with compliance tests. Having implemented both, jsonpath and jmespath, my impression is that the JMESPath grammar, while far more expressive, can largely cover all of the JSONPath syntax with the exception of the recursive descent notation "..". |
|
XML has a pretty complete set of standards in terms of processing, querying and transforming XML documents and it is very exciting to see any efforts in standardization of a JSON Query Language as powerful as XPath. Everything which helps closing the gaps that exist in comparison to XML is welcome from my point of view as an application developer. In this regard JSONPath would fill the gap of querying JSON documents. Apart from that there's currently no standardized equivalent to XSLT for transforming/mapping/projecting JSON documents. For sure, such one could be built from JSONPath similar to how XSLT uses XPath at its core. Nevertheless, JMESPath and jq are very interesting languages in this regard, as they not only provide querying but also projections. The W3C XML standards used to separate the concerns of querying documents (XPath) and transforming/projecting documents (XSLT). Yet a JSON query language also capable of projections could prove very useful and a great step towards feature parity with XML. |
Some of you are already aware that we are looking into creating a standards-track specification for JSONPath, in the same way that RFC 6901 serves as a specification for JSON Pointer. We simply want to use the more powerful JSONPath in other standards, and that doesn't work well if there is not a standards document we can point to.
We created a strawman document in https://tools.ietf.org/id/draft-goessner-dispatch-jsonpath-00.html -- this is the way the IETF works, we like to have concrete documents to talk about. But the actual work of course still needs to be done.
I could imagine that the amazing work done by this community, and in particular the Proposal A you are converging on, could provide a significant input to get this right.
Next week we will have IETF 108 (as an online meeting), and we will need to discuss where to host JSONPath in the IETF.
I made a quick 1:43 video for introducing this discussion: https://youtu.be/Ujch6Wukjc0
But that discussion is maybe less important, but as the next item we'll need to think about the exact goals we have in mind for this activity. So if you have opinions about this, maybe we can use this issue to collect them. And maybe we need to have this discussion also so you can be comfortable that we are not going to ignore your input.
The text was updated successfully, but these errors were encountered: