You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current Thing Descriptions exposed by the gateway include a number of proprietary members which are not W3C compliant, may of which are used internally by the gateway UI.
Some examples include:
floorplanX
floorplanY
layoutIndex
selectedCapability
In order to make these Thing Descriptions W3C compliant I suggest adding a prefix to include these as semantic annotations, e.g.
wtg:floorplanX
wtg:floorplanY
wtg:layoutIndex
wtg:selectedCapability
This would also require adding an additional @context at the top of Thing Descriptions to refer to this custom context, e.g.
I've noticed there are also a bunch of members added for Zigbee devices and I'm not exactly sure why these need to be exposed at the Web Thing API level:
profileId
endpoint
clusterId
attr
attrId
fireAndForget
bindNeeded
configReportNeeded
initialReadNeeded
One exception to this is the current iconHref member, for which there's now a W3C compliant alternative in the latest Thing Description 1.1 draft.
Another term used internally is visible, on property affordances. Support for this property was removed in the the latest gateway-addon-node, but it appears some adapter add-ons may rely on it.
benfrancis
changed the title
Add prefix to proprietary members of Thing Descriptions
Remove or add prefix to proprietary members of Thing Descriptions
Dec 6, 2022
The current Thing Descriptions exposed by the gateway include a number of proprietary members which are not W3C compliant, may of which are used internally by the gateway UI.
Some examples include:
floorplanX
floorplanY
layoutIndex
selectedCapability
In order to make these Thing Descriptions W3C compliant I suggest adding a prefix to include these as semantic annotations, e.g.
wtg:floorplanX
wtg:floorplanY
wtg:layoutIndex
wtg:selectedCapability
This would also require adding an additional @context at the top of Thing Descriptions to refer to this custom context, e.g.
Alternatively it might be possible to keep them as they are without a prefix and with an anonymous context, but this risks name collisions:
See also: #2809
I've noticed there are also a bunch of members added for Zigbee devices and I'm not exactly sure why these need to be exposed at the Web Thing API level:
profileId
endpoint
clusterId
attr
attrId
fireAndForget
bindNeeded
configReportNeeded
initialReadNeeded
One exception to this is the current
iconHref
member, for which there's now a W3C compliant alternative in the latest Thing Description 1.1 draft.The text was updated successfully, but these errors were encountered: