General information about the Web of Things can be found on https://www.w3.org/WoT/.
The Web of Things (WoT) is made of entities (Things) that can describe their capabilities in a machine-interpretable Thing Description (TD) and expose these capabilities through the WoT Interface, that is, network interactions modeled as Properties (for reading, writing and observing values), Actions (to execute remote procedures with or without return values) and Events (for signaling notifications).
Scripting API is an optional building block in WoT and it is typically used in gateways or browsers that can run a WoT Runtime and script management, providing a convenient way to use WoT concepts in high-level applications.
This specification describes an application programming interface (API) representing the WoT Interface that allows scripts to discover Things, operate Things, and expose locally defined Things characterized by WoT Interactions.
See the rationale.md for an explanation of API design choices.
- Call information: We use the W3C Calendar. You can find the next Scripting API call at https://www.w3.org/groups/wg/wot/calendar.
- Wiki (contains agenda): https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf
- Contribution rules
- If you want to make a full-text review on the spec or other files, follow the steps outlined here.
- Latest Editor's Draft
- Latest Group Note
- Releases for other published versions are found in releases.
The specification uses WebIDL definitions, but TypeScript definitions are also available. We use json-schema-to-typescript to generate the TypeScript definitions for wot-thing-description-types and wot-thing-models-types.
We use labels to categorize our work items.
As discussed in the 27th February 2023 call, the task force decided to use a new versioning mechanism for the WoT Scripting API specification. In practice, we augment the current Typescript versioning with a more comprehensive tagging mechanism that takes into account also standard W3C process for publishing Notes. Each substantial change will trigger the creation of a git tag on the repository and when the Note is published it will trigger a full Github release. Substantial changes are anything that is not just an editorial or rephrasing of the current document content; examples of substantial changes are:
- Fixing an algorithm
- New function or change in the argument list of an existing function
- Introducing a new type
- Fixing WebIDL
- etc.
On the other hand, examples of non-substantial changes are:
- Typos in the document
- Introduce new examples or explanatory text
- Improve readability or document structure
In every circumstance, different substantial changes may be packed together in one single git tag if they are closely related or are merged in a short period (e.g. a day). Tags follow semantic versioning
major.minor.patch-[alpha].[id]
ididentifies the experimental revision of an ongoingmajory.minor.patchversion.
Here is an example of the process we will use:
- We publish the current document and tag it with 0.8.0
- Then we make some relevant changes (e.g. a bug fix)
- We tag version 0.8.1-alpha.1
- We continue fixing stuff
- Then we go for 0.8.1-alpha.2
- If we change the API (adding a new function) we should go for 0.9.0-alpha.1
- We can cycle in these changes as much as we want (e.g. 0.x.y-alpha.x)
- When we want to publish the document again we remove the alpha (e.g. assuming we were at 0.9.1-alpha.10 we release 0.9.1)
Since we are still in a exploratory phase, we will use the major number 0 until we reach a certain level of maturity.