W3C

– DRAFT –
WoT Scripting API

05 March 2025

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Jan_Romann, Kaz_Ashimura, Tomoaki_Mizushima
Regrets
-
Chair
Cristiano
Scribe
kaz

Meeting minutes

Minutes

Feb-19

Cristiano: (goes through the minutes)

approved

Calendar

Kaz: (mentions DST changes)

PRs

PR 561

PR 561 - Extended return type of invokeAction()

Daniel: (gives summary)
… addition around ActionInteractionOutput
… InteractionOptions for query is optional
… also for cancel
… (shows index.d.ts)
… the change here is minimum
… (also revisit his comments last week)

Daniel's comments last week

Daniel: inline with the comments above

Cristiano: mixed feeling here...
… what is the use case?
… wondering why we get errors

Daniel: good point
… if I query something, that can fail

Cristiano: we can remove it then?

Daniel: ok

Cristiano: let's see others' comments too
… having InteractionOptions optional itself is fine, but what about input?

Daniel: there is InteractionInput as well
… originally started with InteractionInput
… and was wondering if we need both

Cristiano: that surprises me too...
… we should be consistent
… why do we want to have query, etc.?
… (goes through the Editor's Draft)

WoT Scripting API Editor's Draft - 8.12 The InteractionOptions dictionary

Daniel: not sure if we really need both
… two possibilities here...
… was not really sure which way would be better

Cristiano: anyway, the API should be consistent with the other APIs

Jan: also wondering about that
… this InteractionOptions for query()
… we can indicate which form to be used

Cristiano: you're right
… but something is missing by the TD spec

Daniel: on one hand, we have formIndex
… at the moment, we don't need the status
… both query() and cancel() are optional

Jan: ok

Cristiano: can afford with the same algorithm
… we don't know about the actual protocol, so wondering about cancel()

Daniel: maybe to be aligned with stop() from Subscription
… here, InteractionOptions for stop() is also optional

Cristiano: we have to review the method carefully
… can you check it for the TD spec as well?

Daniel: let me see...

Web of Things (WoT) Thing Description - Next (Editor's Draft)

Cristiano: open issue there

Daniel: issue with the data model to me

Cristiano: let's double check the issue with the TD TF

TD spec (Editor's Draft) - Table 7: Vocabulary Terms in EventAffordance Level

Cristiano: this could be an issue for TD as well

Daniel: the name is also being reused, e.g., for stop()

Cristiano: right
… this is a bug or missing feature of the Scripting API spec

Jan: wondering about the interface
… data can't be defined for the properties

Cristiano: right

Daniel: maybe we could split it

Cristiano: possibly could use sub interface?

Jan: wondering if we should use the same mechanism for both

Cristiano: it's rather an issue of the TD spec, I think

Kaz: what should be the next step then?
… should we bring this to the TD TF?

Cristiano: yeah, would create an issue for TD

Kaz: ok. tx!

Daniel: will update the PR based on the feedback today

Cristiano: and then I'll create an issue for TD

Issues

Issue 566

<cris> Issue 566 - [Use-case] WoT in the Browser

Cristiano: we should support WoT in the browser in general

Daniel: we all agreed based served as an external library (at the beginning)
… if browser vendors are interested themselves in native implementation, that would be great, though

Cristiano: right
… also would be nice for us to capture problems with the Scripting API beforehand

Kaz: agree
… we should clarify what to be done as the WoT WG as a whole

Cristiano: (adds some more comments to the issue)
… we're aligned with Ben's comments
… the question is not just about the WoT Scripting API but the whole WoT including TD and Discovery

Cristiano's comments

Issue 567

Issue 567 - [TD] Consequence of contentType being optional

Cristiano: we need to handle this for TD 2.0. right?
… after clarifying what to be done for TD 1.1
… let's wait for TD updates

Daniel: maybe we need to add some statement about our stance

Cristiano: (adds some comments about that to issue 567)

Daniel: the PR Jan created is only about response at the moment

TD PR 2081 - Make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes

Jan: there is no schema for Discovery

[adjourned]

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).