Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bare minimal Query language for TDDs #232

Closed
relu91 opened this issue Nov 2, 2021 · 1 comment
Closed

Bare minimal Query language for TDDs #232

relu91 opened this issue Nov 2, 2021 · 1 comment

Comments

@relu91
Copy link
Member

relu91 commented Nov 2, 2021

In the last F2F, we have discussed how to narrow the scope of TDDs to allow simpler implementations (see #208). This issue wants to explore how to reduce the feature set of JSONPath to support minimal query support for Read-only TDDs as asked in #156 (comment).

Requirements

We didn't really define a good set of requirements for this minimal query language. Here's a list of what I recall:

  • It should not require excessive computation amount
  • Fairly simple to implement
  • Support tag based searches (i.e. text search)

I am aware that those requirements are a little bit fuzzy, maybe we should work on this in this issue.

Limit JSONPath

A possible approach to define this minimal query language is to restrict JSONPath features to be less computational heavy and handier to our use case. I would start by limiting the root sintax to this rule:

json-path = root-selector *( dot-selector / index-selector / filter-selector)

This basically allows users to select subsets of TDs (similar to a json pointer implementation) plus filtering. We can limit this even more:

json-path = root-selector *( filter-selector)

Which means that users are only allowed to filter the TDD collection of TDs. In principle, this would simplify a little bit the implementation cause it will not need to support the selection and manipulation of the query result set. However, this is my conjecture and it might be actually tested/proofed with concrete data.

About supported features, we could support free text searches with JSONPath through RegEx support. However, RegEx syntax is sadly marked as TBD (it is marked as a possible future consensus in the feature matrix). Without it we can only have exact text matches in the filter selector, which might be still ok for searches like: "look for TDs with @type equal to Sensor".

Another decision point is if we want to limit also the filter-selector, but it depends on what we want to achieve:

  • Support only simple root "@type", "title", "description", exact tag filtering:
    • We need to fix the allowed path in the filter-selector
    • O(1) complexity -> a simple map (@type -> TD) can be used to resolve the query
  • Support nested "@type", "title", "description", exact tag filtering
    • Similar to the previous one, but more memory is required
  • Support RegEx text (if ever defined in the spec) searches on a set of predefined properties :
    • It's at least O(n) operation with N equal to the number of TDs.
  • Anything else?

Reference: https://www.ietf.org/archive/id/draft-ietf-jsonpath-base-02.html

@relu91
Copy link
Member Author

relu91 commented Nov 4, 2021

Closing duplicate of #231

@relu91 relu91 closed this as completed Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant