Skip to content

Discovery filtering #115

Closed
Closed
@zolkis

Description

@zolkis

I would like to ask for input for typical discovery scenarios in WoT scripts. I have the hunch most scripts simply use wot.discover() which defaults the discovery method to "any", or by specifying a directory: wot.discover({ url: ... }); (where method also defaults to "any").

Currently we (theoretically) support constraints and queries which are flexible, but if defined, must be standardized. That takes considerable effort. Also the runtime size might be considerably increased by including for instance JSONiq or JMESPath implementations.

I am not sure how much of this is needed.

Note that for generic standardized filtering support, this should be done in the receiving (local to the script) WoT runtime. For filtering at source (directory or endpoints), we'd need protocol support in order to transmit the filters, and we'd need translation of the filters. Filtering at source (e.g. in directories) should be defined by the specific WoT interface level, probably defining specific actions for discovery.

At the moment I am inclined to drop filtering support, since scripts could use local filtering libraries. Alternatively we could label filtering as "next version" feature, or restrict to a simple subset of JSON query language that is summarized in the Scripting spec in a non-normative section (like e.g. Observable).

For that we need input on what typical searches will look like.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions