W3C

– DRAFT –
WoT Thing Description

14 June 2023

Attendees

Present
Cristiano_Aguzzi, Ege_Korkan, Jan_Romann, Kazeem_Oladipupo, Luca_Barbato, Michael_Koster, Sebastian_Kaebisch
Regrets
Kaz
Chair
Ege
Scribe
Ege, luca_barbato, sebastian

Meeting minutes

Past Minutes

Ege: We note the changes to be done on IRC and then kaz will edit accordingly if needed

Ege: Usual editing for the names

<overall review>

Ege: Consensus on the Minutes?

Ege: To recap: names and merging `minutes` and `minutes review`

<approved with those changes>

Zoom Links

Ege: I added the links to the calendar event to the wiki, the actual date should be ignored

Discussions

Ege: We invited parties to discuss more on what are the expectations in TD.next

Ege: Today Luca will present some pain points with the current specification

Ege: The presentation can be small and we will schedule in the next weeks (not the next since we have the detailed charter planning)

Detailed Charter Planning

Ege: I do not have more information, Sebastian do you have more information?

Sebastian: The plan is to have the meeting next week <checking the agenda>

<Ege> https://w3c.github.io/wot-charter-drafts/wot-wg-2023-details.html

Ege: This is the document we will discuss about

Ege: I expect to have around 3 hours for the discussion

Ege: If people are able to prepare a presentation on the parts of this document would be great

Luca: I have some concerns on some items and we could find time to work on something together with you (Ege)

Ege: <Adds presentation items on the wiki>

Cristiano: This presentation has to be done to the next week or the next weeks?

Ege: Next week want to refine the charter document, but the next weeks we want to have more presentations

Cristiano: I have some feedback with the experience with Discovery

Cristiano: We can refine the list after Luca's presentation

Sebastian: Two topics here
… One about what we should discuss the early beginning of the Charter
… how shall we manage the content of the TD document
… the document is generated parsing also the ontology and the whole process in complex
… we might find a simpler process

Cristiano: It is definitely a good topic to discuss

Ege: We note the people who are interested on the topic, at least one kickstarts the discussion

Sebastian: The second topic is about how about to optimise the workforce we have
… I suggest to not have so many many meetings in the week
… and concentrate on the TD topics first
… so the API and Discovery TF can work on the TD output as soon as it is done
… we could make a timeline
… so we see when the other task forces can start working

Ege: <Updates the document and recaps>

Ege: We could talk also about which protocol bindings to prioritise

Cristiano: Manageable Actions is also a topic of interest

Luca: +1

Sebastian: Next week we should not go into technical details
… the discussion should be more on the problem and not the possible solutions

Ege: I will prepare a shared document so it can be a joint presentation

<Ege> https://github.com/orgs/w3c/projects/31

Project Management

Ege: We prepared a github project with all the deferred to 2.0 issues

Ege: We should make sure everybody can access it

Ege: <shows the github project interfaces>

Ege: We can use it to manage the increasing complexity of the specifications

Sebastian: I like the project approach, we should make sure to filter the issues for planned features and not issue/questions

Luca: The project system in github is just a set of views, as long we label the issues correctly it will work fine

TPAC Agenda

<Ege> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf/2023_WoT_TPAC_Agenda

Ege: The information seems already correct

Thing Description 1.1 Proposed REC

<Ege> w3c/transitions#554

Ege: It is still wip

Sebastian: There is a section TBD

Ege: We discussed the PR in the Main call with a resolution, I'll contact Michael about it

Issues by rec transition

<Ege> https://github.com/w3c/wot-thing-description/issues?q=is%3Aopen+is%3Aissue+label%3A%22by+REC+publication%22+

Ege: the issues are minor changes and we can address them off-meeting

Presentation by Luca

<Ege> https://github.com/w3c/wot/tree/main/PRESENTATIONS

Luca: <showing slides; will be shared later>

Luca: Presentation topic: TD Pain Points
… the current TD spec is not uniformity
… it is unclear how to mange other specification
… we have also problems with the subspecifications such as profil and bindings

Luca: about the uniformity, the TD spec. has different meaning "of one" or "array"

Luca: affordances are not uniform
… input is in property and action, output in event, action, property
… event has 3 data schemas, property just inherits but no term

<sebastian> ok, Im back

Luca: action input and output are somewhat similar but events have different, namely data and dataResponse

Ege: the observation is correct. the input and output is the opposite

Cristiano: I can also confirm this problem. It would be nice if you link also the related issues
… this topic I like to start first in the new TD

Luca: I just prepared the presentation to start the discussion
… but not everything have to be addressed. Maybe it can be read differently

Luca: Property implies that the change is immediate and syncronous, even if it is never the case

Luca: Action cannot be subscibed
… a work around can be to define a Property that match a Action

Ege: do you mean the approach more coneptional?

Luca: its more about the status of the action

Sebastian: we will work on this topic in the next charter

Cristiano: agree with Sebastian. Topic has a history.
… I would not define a seperate property
… in JS properties defined with a promise and we cannot wait them

Luca: if you use a property, this is not immediate and is not synchronous

Ege: ok, I understand the issue now better

Luca: uriVariables clash badly with input
… in forms, response and additionalResponse fields that clash with dataResponse/data and output
… form does not have a way which parts of the Affordacne DataSchema should be map to its protocol
… uriVariables seem to be additive over the Affordance DataSchema

Ege: I agree, what is needed. is. a binding mechanism

Cristiano: I'm also agree with this points.

Koster: +1 what Chris said
… we have different places which can show up, such as in header, url etc

Luca: TD is mainly relied on JSON-LD
… but the spec says that TD can be processed without a JSON-LD processor
… we like to serialize TD in not-json (e.g CBOR)
… we should be clear how we can ensure interoperability

Sebastian: there is a history about the JSON serialization requirement and JSON-LD serialization requirement
… it is a compromise as specified in the spec

Luca: we do not have a concept about the concept of degraded bahavior regading consumption of something. chould be topic for next charter

Luca: dataSchema is related to the json-schema, but it is unclear if it is a subset or a superset

Ege: we should be very clear about this what you mentioned. First we need to fix the version first.

Cristiano: agree with Ege. we need a better explaination

Ege: thanks luca for the presentation. Very helpful
… other businesses?

Luca: this was just part 1 there will be another parts

adjourn

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).