W3C

– DRAFT –
WoT Scripting API

05 February 2025

Attendees

Present
Cristiano_Augzzi, Daniel_Peintner, Jan_Romann, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Cristiano
Scribe
zkis

Meeting minutes

Past Minutes

<kaz> Jan-22

Minutes approved.

PRs

PR 561 Extended return type of invokeAction()

<cris> w3c/wot-scripting-api#561

Cristiano: the current starting point is to include the extensions to a single object.

Cristiano: Zoltan argued for extending the InteractionOutput object (summarizing the comment).

Cristiano: agree with the message, but we lack information due to TD 2.0 gaps
… not clear what assumptions can we make
… the proposal is to keep the feature low in the abstraction layer, i.e. add it to the ConsumedThing interface

Daniel: the solution is vague because it's underspecified
… we should acknowledge this
… so it's in the application domain how to deal with this

Cristiano: The discussion is relevant also for other op's
… in theory we support all operations

Zoltan: it's a syntactic thing where we expose canceling actions
… if canceling is not supported, it can return an error (if it's known it cannot cancel); otherwise it's a problem

Cristiano: we already have a use case for controling actions

Kaz: agree with Zoltan, think for several possible patterns for the actions and return types using several use cases.
… regarding publication of the Scripting API Note, we can publish that is in sync with the TD spec, and describe additional considerations as Editor's Notes.

<Zakim> dape, you wanted to future

Daniel: let's assume TD 2.0 will break compatibility
… Scripting might also have breaking changes

Daniel: we should do our best for current TD spec, then might do changes

Zoltan: the current design will not break, it's just extension

Cristiano: ok, but it's not a problem if we break since TD 2.0 is assumed to break things

Cristiano: the web usually is backward compatible

Jan: we can proceed with the object approach

Cristiano: the TD use cases are supported also by extending ConsumedThing, but we'd need to identify the actions (payloads), or URI variables
… both designs have ways to pass information in the headers

<kaz> PR 561 - diff for index.d.ts

Daniel: are you saying we should add options to cancel()?

Cristiano: yes

Cristiano: we can do what we do with e.g. write: options or URI variables

Daniel: what is the cancel endpoint is different?

Cristiano: that is likely a form index

Cristiano: similar to canceling subscriptions

Zoltan: so when there is no args to cancel, impls try to figure out, otherwise they take args from the app

Zoltan: ok, this doesn't change the API shape, only parameters

Cristiano: what is later this is deprecated?

Zoltan: then we add prose to say we'll ignore arguments from now on

Jan: we need implementation experience, will provide

Daniel: the status() call returns what?

Cristiano: a streaming object, since we don't know yet its format
… to be decided

Daniel: and cancel() is like stopping a subscription?

Cristiano: yes

Daniel: so these signatures are compatible

Cristiano: we can return InteractionOutput, for future flexibility

Zoltan: cancel cannot be guaranteed, but it can register user intent for canceling

Daniel: we should expose all errors we get

Zoltan: yes

Kaz: there are bigger issues than just return type
… we should decide what to include in the Note itself, and then clarify what to be done for the future Note inline with TD 2.0.

Kaz: we need use cases on how to map the returned streaming object for the 2nd point above.

Cristiano: we cannot make assumptions yet on action lifecycle data
… nor about payloads in query and cancel actions
… we can only invoke the ops of cancel and query

Zoltan: I am not sure we want an error property

Daniel: yes, and also replace status() with query()

Zoltan: but the TD spec will have to define the result types of query()

Cristiano: yes, we can use InteractionOutput for now

Publication schedule

Cristiano: how should we do release approach

Cristiano: or should we stop development for TD1.1?

Zoltan: we already have the mechanisms in place

Daniel: agree with that, but the current link is generic

Kaz: We don't need to think about the publication URLs today, but the latest URL will be used by the latest version document. Then the older version documents will be identified by the dated URL (and the history area).

<kaz> e.g., TD history 1.0

Zoltan: Scripting should be able to handle Things with both TD1.1 and TD 2.0 specs
… so we need a single Scripting API to handle both

Cristiano: time is up, call adjourned

Minutes manually created (not a transcript), formatted by scribe.perl version 242 (Fri Dec 20 18:32:17 2024 UTC).