Meeting minutes
Agenda
Ege: anything to be added specifically??
Kaz: McCool mentioned additional use case templates for User Story and Use Case Category were generated, and wanted to work on "tryout" during the TD calls. maybe tomorrow.
Cristiano: Maybe we could talk five minutes about additionalExpectedResponses, since the topic came up in the Scripting API call
<kaz> agenda for today
Minutes Review
Ege: We will first have a look at the minutes of the last regular meeting, then we will talk about WoT Week
… and something related to standardization
Minutes from November 20
<kaz> Nov-20
Ege: The scribenick looks odd
Kaz: Just the IRC nicks used during the call
Ege: We talked about the initial connection topic
… there was a lot of agreement, more discussion regarding algorithms etc.
… oh, there is a typo here, Kaz (HW => How)
… we carried over the results from hackmd to GitHub
… any remarks regarding the minutes from the people here?
… minutes are approved once the typo is fixed
Kaz: Just fixed
Ege: Then the minutes are approved
WoT Week Minutes (Friday TD session)
<kaz> Nov-29
Ege: Will only focus on the Friday TD session, plugfest recap has been done elsewhere
… (scrolls through the minutes)
… there was some discussion regarding the Binding registry, vocabulary prefixes
… I think "SV" here is Salvatore
… or is there someone else?
Cristiano: Was I the scribe?
<kaz> fixed
Cristiano: if so I think it was Salvatore
Daniel: I think it was actually me
Kaz: Fixed already, don't worry
Ege: Then we updated the document during that call
… the results of the discussion are actually in the registry work
… any other remarks?
… alright, then I guess the session on TD and bindings is approved
… I guess there is nothing else
Plugfest Outcomes
<kaz> wot PR 1223 - Organizing Plugfest Outcomes Folder
Ege: Wanted to ask whether it is fine to merge this PR (wot PR 1223)
… aligned the names of the presentations to "Plugfest Outcomes" and included everyone's name in the file name
… I also extended the README
… there was also a duplicated presentation by Toumura-San, I removed the duplicate
… not hearing any objections, then I guess it is fine to merge
Kaz: Plugfest resources are mainly installed under the wot-testing repository, but do you want to put the report on the wot repository. right?
Ege: Some things are under wot-testing
… other things are in this repository
Kaz: If that is what you meant then that is fine, just wanted to confirm
Ege: Then let's merge this one
PR is merged
Standardization-level feedback
<kaz> Ege's recap
Ege: Came up with my own summary to extract what is relevant for the standardization process
… please tell me if you want to change anything while I go through the list
… so this is based both on the slides and the minutes
… but I might have missed something
Multi-part form
<kaz> wot-thing-description Issue 1464 - How to describe multipart/form-data in TDs
Ege: there were multiple people mentioning multi-part form inputs
… e.g., like in a website form where you can upload a picture and provide profile information
… this is currently not supported by TD
Streamed responses
Ege: another aspect is streamed responses
… like if you get subsequent responses to one query
<kaz> wot-thing-description 1044 - Adding term to indicate a stream of data
Ege: McCool has commented on an existing issue (1044)
… Deutsche Telekom has also brought this up
… might also be relevant for non-IoT devices
… was mentioned by Ben Francis, whether we should also support services this way
… but in a way, he is correct that this kind of services is sometimes embedded into devies
… so it is not necessarily out of scope for us
… the use case is definitely still there
… Roman Blinkert has also raised a similar issue, that was dealing with streaming the position of a robot
Sleepy devices
Ege: Then Matthias and Jan brought up sleepy devices, was also raised in Mahda's slides, for example
… mentioned by multiple people
… when the device is not available, but will be in 10 minutes or so, this is not describable via TDs at the moment
… there are two issues opened regarding this, one in TD by me and one by Jan in the wot-binding-templates repository
Invalid data according to the schema
Ege: Then Conexxus and Cristiano brought up that data schemas might not always fit the data received from a device
… need to deal with this, maybe additional responses could be used here
… need to cover the non-usual cases as well
Sleepy devices - revisited
Daniel: Wanted to comment on the sleepy devices: I think Carsten Bormann mentioned that data might be relatively old, since measurements are only taken every X minutes
… he also wanted to add a term for that
… reminds of this discussion, also related to saving memory/battery
Ege: I think it is not exactly the same, but under the same umbrella, would be great to find that issue
… another example might be MQTT where values might be retained and therefore outdated
… cannot specify this at the protocol level
Daniel: I will research this and add it to the Wiki
Cristiano: Agree that this is related
… but it's tricky, since in CoAP you cannot reach the device at all while it is sleeping
External Schema
Cristiano: Something else I wanted to convey was that the data that is exposed from the thing
… Conexxus is more concerned with the data they publishing, did not really think about the consumer
… this is problematic and can be a problem for interoperability
… e.g., for each transaction they publishing the whole history and you need to parse and rearrange it again
… would be nice to have an event, in this case we had to add custom logic to parse the array
Ege: I remember, but I think this is actually another point
Cristiano: Maybe some more guidelines/teaching is needed here
… does not necessarily have to go into the REC
… also uncovered some validation issues
… since we are saying that the data needs to be valid, and this was definitely an exception in the plugfest
Ege: I think we were thinking about this, but the schema might become to complex
Cristiano: I think they mentioned this, but this was kind of the root of our problems
… for example, they someone broke validation in node-wot, and suddenly their whole TD was wrong, not sure why
Ege: There was a request in Conexxus, they are using $ref in their OpenAPI definitions
… there is an existing issue for this, will require pre-processing
<kaz> wot-thing-description Issue 1249 - Refer to external data schemas
Ege: (shows issue 1249)
… the issue is that $ref has to refer to an outside document, not the same document
… need to think about this, might need to put some restrictions in place
Ege: We talked to Conexxus regarding events on the first day
Kaz: The discussion itself is great, but for today we can probably continue the discussion on the Wiki
… my proposal is to copy the wiki content to a Markdown file
Ege: This is something I wanted to ask
… in the scenarios, we included a "Results" section for each one
… maybe we can use that
… but where should we put the information
Kaz: That's why I was asking you about whether putting the results in the wot repository would be intended or not.
… so my proposal would be to quickly skim the issue list on the TD agenda wiki, and then discuss how to handle further discussion next rather than diving into the detail one by one today.
Cristiano: Just wanted to mention that we might need to use SchemaDefinitions, but this might be very hard
… the whole mechanism should be consistent and nicely put
Ege: Yeah, I agree
Ege: Then there were some questions regarding the eventing mechanism
… should provide some guidance here, e.g., not use long-polling
type vs @type
Ege: Then we have the type vs @type, Mahda/Daniel brought it up
Writeproperty
Ege: then there was an old issue again regarding writeproperty operations that might return a value
Human readable data
Ege: there other aspects mentioned regarding the importance of LLMs brought up by Toumura-San and Michael McCool
URI Schemes
Ege: lastly, in the context of UPC UA, there was the question regarding URI schemes and unauthorized characters
Where to put the summary?
Ege: I will put the information into the wot-testing repository, if that is fine for everyone
… (starts copying the content from the Wiki and adjusts the README in the StandardizationTests directory within the folder for the Munich event)
… this will move it here
… just wanted to ask whether someone wants to add something here
… was there something that was good to learn for the standarization, e.g., bugs to clarify
… alright, so I'll put it here, but if you see anything you want to extend, you can do a pull request
… and then maybe, Kaz, we can link it here in the wiki
… (adjusts the wiki)
Kaz: My suggestion was and is putting detailed questions and analysis into the GitHub side, because Wiki content tend to get longer and longer.
… so it might be better to put the content into some kind of repository
Ege: Yeah, so I did this, is that fine?
<kaz> WoT Week summary on the GitHub side
Kaz: Yes, thank you
Ege: No worries
TD SpecWork
Additional Expected Responses (feedback from the Scripting API TF)
<kaz> Scripting API discussion on Dec-12
Cristiano: Just a question, we started the discussion from the errors
… if I remember correctly, the additional responses could be successes or errors
… but I did not find any success responses
… do you know if there is an example for that or do you remember something?
… I looked into the TDD and I thought there was something, but there was nothing there
Ege: I think I implemented that, but do you want an example or a real-world example?
Cristiano: Real-world is better of course, but any example is good
Ege: (shows an example TD)
… so in this case, the response we were getting was different from the one regular one
… when we query an action
… and it was a similar thing with queryaction
Cristiano: Couldn't you just use the response here?
Ege: I think this is a bug we have in TD
… as you can only provide the content type, but not a data schema
Cristiano: Then this is just a workaround
Ege: I agree
… the real workaround came rather from the TDD
Cristiano: I quickly scanned it, but I did not find it
… only got additionalResponses with errors
… but as I said, we will start with errors
… so maybe we can think about this again, once we have dealt with the errors
Ege: This is similar to writeproperty that cannot return a value
Cristiano: I recently had a similar issue
… with an example where you get a 207 response with a list of partial IDs that were okay during an update
… or bulk operation
… but you could even argue that this might be an error response
Ege: I think there are real-world examples
… perhaps more regarding this writeproperty case
… for example, if you write something that could be processed
Ege: added the link to the example above
Initial Connection Discussion
<kaz> wot-thing-description PR 2058 - Initial Connection Feature Description
Ege: Before the plugfest, I started working on a JSON Schema to describe what we had
… still haven't been able to finish this, but I am working on it
… question is where to put it
… where should we put this experimental stuff?
… Could keep it in a personal repository, but maybe an official repository would be better
… maybe some experimental repository? Do not want to put it into the toolchain repository and don't want to pollute the TD repository
… usually, I think this should go into the editor's draft, but in this case it might be too experimental
Daniel: I always thought that the "proposals" folder might be the way to go here
… we have some proposals for hypermedia there, but I don't know why you don't want to put it there
Ege: Just not to pollute the commit history
Kaz: Whatever is fine, if there is no impact, then I think we could put it into the proposals folder for example
… another possiblity would be creating another repository
Jan: Experimental branch could be also an option
Ege: Don't want to mess up the HTML etc., since we have the toolchain coming up
Kaz: So for a while, we could think about this as another detected section to merged into the main document
Ege: Yes, currently, it is also in the planning section, which is very ugly, we cannot do this for everything, since it will explode the document
… should move it somewhere else at some point
… can also go to the proposals folder
Kaz: If we create a dedicated repository, it will be easier to look at the rendered document (if we want to have an HTML)
Ege: We can just look at the rendered markdown
… I think I like the proposal from Daniel
… and eventually, we can just delete it, as we are agreeing to put it in the main document
… are you also fine with this approach, Jan? Or do you prefer the experimental branch?
Jan: Totally fine with that, just wanted to mention it as a potential alternative
AOB
Ege: Is there any other business?
… then we can adjourn, and we will see each other tomorrow
… have a nice evening, night, or day, see you tomorrow
[adjourned]