Wot-thing-description: What can be a TM is not clearly defined

[egekorkan]

Coming from #1049

The current spec allows defining placeholders in TMs and it seems that they can be used everywhere. I think that placeholders should not be used in place of Objects.

The current spec allows the following:

1. Inside a Data Schema

"type":"object"
"properties":"{{MY_PLACEHOLDER}}"

1. Root level

{
  "@context": "...",
  "actions":"{{MY_PLACEHOLDER}}",
  "events":"{{MY_PLACEHOLDER_2}}"
}

1. Even the following is allowed

"{{MY_PLACEHOLDER}}"

Is there any use case to have such generic placeholders? The first case can be simply modeled by omitting the properties key. The second and third cases defeat the meaning of a model since the model on its own doesn't mean anything.

My proposal would be to limit placeholders to replace strings, numbers, integers, booleans which can of course be inside an object or array

[sebastiankb]

Based on the PR option 3 is not allowed. Option 2 would be possible. If there is a mapping file this can be also be taken into account for validation. But I would be ok to introduce limitation that placeholder not allowed to describe interactions. Any comments?

[danielpeintner]

Coming from object oriented programming I can see the point that someone wants to describe the "interface" in a TM.
e.g., saying a TD should have a property status which is of type string.

{
   ...
    "properties": {
        "status": {
            "type": "string",
            "forms": "{{STATUS_FORMS_PLACEHOLDER}}"
        }
    }
    ..
}

The forms array might make use of a placeholder. I think in this case support for arrays would be beneficial....

[egekorkan]

Based on the PR option 3 is not allowed

I have found this, is the following text the reason it is not allowed?

A Thing Model is recognized by the top level @type. Thing Model definitions MUST use the keyword @type at top level and a value of type string or array that equals or respectively contains ThingModel.

Regarding forms replacement above, wouldn't it be better to simply not put forms? However, I do see a bit of a benefit in making it clear that there will be a placeholder-based replacement and not another mechanism.

[sebastiankb]

@egekorkan not really, its this one:

Placeholder can be only applied within the value of the JSON name-value pair and the value have to be typed as JSON string.

[egekorkan]

Ah I see @sebastiankb. In that case, that part needs an assertion and should be gray highlighted :)

[sebastiankb]

Ah I see @sebastiankb. In that case, that part needs an assertion and should be gray highlighted :)

done.

I label this issue as proposed closing.