Mechanism to facilitate dynamic URI resolution for Thing Model extension and import

[dvalnn]

The algorithm for the derivation of Thing Description instances from Thing Models, as outlined in the td specification does not allow for the resolution of {{placeholders}} that are part of the links section of a Thing Model.

Example:

In the current implementation (and according to the specification steps), such a trying to instance the Thing Model below, would result in an exception since affordances are fetched before placeholder replacements:

{
    "@context": "https://www.w3.org/2022/wot/td/v1.1",
    "@type": "tm:ThingModel",
    "title": "simple_example",
    "description": "Example thing with a single property",
    "version": {
        "model": "0.0.1"
    },

    "links" : [{
        "rel": "tm:extends",
        "href": "http://{{MODEL_REGISTRY_ADDR}}/some_other_model.tm.jsonld",
        "type": "application/tm+json"
    }],

    "properties": {
        "random_value":{
            "description": "a random value between 0 and 100",
            "type": "number",
            "minimum": 0,
            "maximum": 100,
            "observable": true,
            "forms": [{
                "href": "mqtt://{{MQTT_BROKER_ADDR}}",
                "mqv:topic": "{{THING_UUID_V4}}/properties/random_value",
                "op": [
                    "observeproperty",
                    "unobserveproperty"
                ],
                "mqv:qos": 0,
                "mqv:retain": false,
                "contentType": "text/plain"
            }]
        }
    }
}

However, a dynamic replacement of the {{MODEL_REGISTRY_ADDR}} could be useful for the development process of WoT applications (my current use case) or when multiple registries exist that may be searched iteratively.

Could placeholder replacement be supported for this use case?
If not, could some other mechanism be added to the ThingModelHelpers to redirect affordance resolution attempts during the partialTD generation process?

[egekorkan]

This is a bug for the spec I think. The placeholder resolution should probably happen when fetching a TM and not as a last step? What should be the general algorithm?

[dvalnn]

From my usage of the tool so far here is how I'd expect the algorithm to behave

getPartialTD(model, map)

1. identify placeholders in the tm
2. substitute all placeholders from the map (throw/error if there are missing keys)
3. Identify extension/import affordances
   -> if none, return the partial TD
   -> if some, fetch models and recurse/iterate from step 1.

Yesterday, I opened #57, which, as far as I know, allows for this general behavior when handling affordances beyond the example provided in this issue.