W3C

WoT Scripting API

01 February 2021

Attendees

Present
Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Daniel
Scribe
zkis

Meeting minutes

previous minutes

<kaz> Jan-25

No objections, approved.

PR 289

<dape> PR 289 - Add definitions for partialTD

<dape> related with wot-architecture issue 574

Daniel: related to the issue discussed in Architecture

Daniel: the PR was merged, so we have a definition for the Partial TD
… since it may be useful for other use cases as well
… so now we have the PR from Cristiano
… we decided last time to rename PartialTD to ExposedThingInit

Cristiano: yes, it's been a minor update, just a name change

Zoltan: usually we don't make separate sections for dictionaries

Cristiano: but we have 2 algorithms

Zoltan: ok then it makes sense

CA presents the PR

Discussing structuring of the ExposedThingInit section into the produce() section
… as subsections of produce()

Cristiano: another thing, what to do with the table for generating the partial TD
… and how to deal with possible differences in implementations
… in order to be interoperable
… also, take care of mandatory definitions (like security, context, ...)

Daniel: if someone specifies a scheme that is not supported, it should replace or handle it

Zoltan: usually we need to specify in the algorithms how to handle these

Daniel: for instance, could href point to another Thing?

Zoltan: do we do syntactic or semantic check?

Cristiano: syntactic
… the app might not want the impl to replace the href

Zoltan: the TD should give us possibility for that

Cristiano: we could use relative URI here

Daniel: the problem is that e.g. node-wot uses the input to generate a full href, and the app cannot have that knowledge

Cristiano: the input from app should be respected up to the level of definition: name, partial URI, or full URI
… if it cannot be respected, then an error would be reported
… but the parts not specified should be completed by the runtime
… also, understand that we cannot use other URIs than the ones we own

Daniel: need to check this

Daniel: impls should not allow other origins in the input
… but rather use the handlers for accessing external URLs

Cristiano: also have a use case that the address generated by node-wot is not what was expected by the app
… anyway, I agree, make it simple and don't accept other origins here

Zoltan: also need a default handling for security input (e.g. no-security)

Daniel: difficult to provide the right credentials for the exposed Thing

Cristiano: will try to propose something and discuss in github

Zoltan: it would be nice if the TD TF would define the exact TD producing

Daniel: the TD TF is concerned only about the decoding, not the encoding
… the only thing to make sure is that everyone decodes the same way

Zoltan: so you say it's application's domain to describe the encoding

Daniel: well, yes

Zoltan: we should separate the pure syntactic checks from the semantic checks and transformations by impl
… and feel it's a gap if we don't specify the transformations

Cristiano: agree with that

Daniel: so let's start with syntactic and then decide

implementation feedback

<dape> Issue 292 - Simplification of interface InteractionOutput

Daniel: InteractionOutput is too complex

Zoltan: we need to support other content types than DataSchema
… the TD permits that and it was a gap

Cristiano: I also wonder why can't we have streams

Zoltan: we could raise up in the main call if we want to stick to DataSchema

Daniel: just not sure about this in real life
… this will be a problem in many implementations

Cristiano: but streams is optional, the value() function can throw

Zoltan: I think any impl based on http or coap library can do it out of the box

Daniel: ok, let's discuss further

adjourned

Minutes manually created (not a transcript), formatted by scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).