Possible alternative design of Discovering API

Currently, the Discovering API uses the ThingFilter's method field to select which discovery approach to use. Therefore, we are using a factory style to select different strategies using an Enumerative value. This is common in the OOP world but I rather use a more functional style to solve this problem. The fact is that method field is hinting us that the discovery process could be carried out in different ways, which means that we could model the API using different functions.

Consequently, my proposal is to remove the method field from ThingFilter and design a set of functions that represents the different method enumerative values. In concrete, I'd define a subnamespace of WoT called discovery which contains the directory, local, mulitCast, direct (?), and any functions. I'll describe the interface formally using Typescript since I am not so used to WebIDL:

declare namespace WOT {
    namespace discovery {
        function directory(url:[string|ThingDescription],query?:string):ThingDiscovery ;
        function local():ThingDiscovery ;
        function multiCast():ThingDiscovery ;
        function any():ThingDiscovery ;
        function direct(url:string,form?:Form):Promise<ThingDescription>;
    }
}

Note that function signatures are just examples, they are not the topic of this issue.
However, it can be seen how this solution adds flexibility to the inputs/outputs of the different discovery processes. We are not limited to use the ThingFilter object containing all the possible inputs of the algorithms. We can now fine-tune the signature to better convey the anatomy of the discovery method. For example, see the (proposal) signature of the direct algorithm, where the output is not a ThingDiscovery but just the ThingDescription requested. Or see the directory function where we define as input also a ThingDescription of the directory service (if directories will have a TD).

Practically, devs will be able to call the discovery in the following way:

const TD = await WOT.discovery.direct("http://somehost.some");
const thing = await WOT.consume(TD)

pro

• algorithm input/output fine-tuning
• Easier to describe each algorithm. we do not need a big switch and explain each case, but we can use different subsections.
• More expressive. we model the process as a real function, not as an Enum value.
• More extensible. it is easier to change/add discovery algorithms (i.e. adding a new function or change its signature)
• Easy feature detection (e.g., checking if local is supported: wot.discovery.local !== undefined)
• ...?

cons

• Model any function might be hard
• WebIDL does not seem to support subnamespaces
• Increase the number of functions in the API (i.e. increase complexity)
• Cannot easily express a combination of different discovery methods. (suggested by @zolkis in the comment below)
• ... ?

see also

This design is similar to vscode extension API (they are using module instead namespace)

Start by reviewing the current Discovering API and ThingFilter design, then compare it with the proposed WOT.discovery functions. The issue does not name implementation files or tests; completion would require agreement on the API shape, WebIDL feasibility, and how combined discovery methods should work.