Query language?

[Fitzsimmons]

If this thing takes off, and I hope it does, I'm eventually going to want a general purpose way to query or manipulate it (similar to XPath or jq). Is that something you would consider in line with your goals for this project? I realize that this is very early in the process and the significance of essentially asking if you want to design and maintain a whole extra grammar, documentation, reference implementation, etc. However, I thought it could be valuable to bring up the idea early in the process since it could influence design decisions or open up opportunities for outside contributions.

[zkat]

Yeah this is definitely something I've been thinking about too! I've mostly filed it under "just base it off something that works for XML", since most XML things should be conceptually compatible with KDL

[lilyball]

I was originally drafting a comment about how we could just convert KDL to XML and then run XPath on it, but I'm not sure how to represent node values in XML, or how to represent node properties with non-XML-attribute-safe names.

[zkat]

yeah, that's the tricky part. You should be able to convert (most) XML to KDL but not the other way around :(

[lilyball]

It occurs to me, preserving the types of values requires metadata anyway, so an XML serialization may just go the route of nested nodes, as in

foo "string" true key="value" {
  bar "I'm a child"
}

might become

<node name="foo">
    <string>string</string>
    <true/>
    <property key="key"><string>value</string></property>
    <!-- or maybe <property key="key" type="string">value</property> -->
    <node name="bar">
        <string>I'm a child</string>
    </node>
</node>

But this isn't fantastic to work with.

[Fitzsimmons]

XML based tooling might get you some quick wins but I have a feeling when you start to get into the edge cases of both languages it will get pretty scary. I'm not optimistic about the performance either.

With that said, you don't need 100% coverage or high performance to quickly prototype out some ideas! A quick program to turn KDL into your flavour of XML and another one to turn prototype query language ideas into XPath can yield working experimental implementations without needing to think about things like how to traverse graphs in memory.

[junosuarez]

Some prior art to look into:

XML: XPath
pros:

• very expressive
• spec'd in a very abstract way- useful for thinking through this problem space again, particularly "axis" concept
• clearly distinguishes nodes from properties

cons:

• maybe too powerful
• more difficult to learn and implement
• likely overkill, more difficult to implement
• feels kinda dated

CSS Selectors:
pros:

• lots of developers already know at least the basics
• maps well onto KDL nodes and properties (as attribute selectors)

cons:

• not obvious how to express a node argument selector - maybe similar to attribute selectors with numbers assumed to be arg indexes and strings assumed to be property names?

JSONPath:
pros:

• concise
• suitable for nodes, arguments

cons:

• not obvious how to express a node property selector to distinguish between child nodes and node properties - maybe similar to index selectors with numbers assumed to be arg indexes and strings assumed to be property names?

jq

• similar to xpath and jsonpath

====
While I don't think this needs to be tightly coupled to the spec, I think this is a useful thing to think about: it will clarify the implied object model and usage patterns from an application side.

[hkolbeck-streem]

I got a bit nerd sniped by this and wrote up a query language and implementation in Kotlin on top of kdl4j. The impl needs a decent bit of testing before I'm comfortable sharing it, but I wrote up a somewhat incomplete doc on the syntax and semantics. It's currently in a branch on the kdl4j repo as I'm actively tweaking things there as I go along.

The README is here.

[zkat]

For some reason, I missed/forgot about @hkolbeck-streem's query language, and ended up just speccing out my own: https://github.com/kdl-org/kdl/blob/main/QUERY-SPEC.md

Sorry! :(

Do folks have any thoughts on which they prefer?