Meeting minutes
Agenda Review
<kaz> Agenda for today
Ege: So today there is going to be this use case discussion
… but only a small one
… then we are going to talk about the initial connection topic
… and the backlog
… tomorrow, we are going to talk about the registry
Minutes Review
<kaz> July-31
Ege: Koster, Kaz, and I already had a look, you have probably also seen the email
… I will now quickly scroll through them, let me know if you notice anything
… don't see any points being raised, minutes are approved
… thank you, Michael Koster, for taking the minutes last time
TPAC
Ege: I am not going to be present the first two weeks in September
… given that TPAC is quite close by, it would make sense to work on topics for TPAC
… we should discuss which topics we want to focus on. Should concentrate on registry requirements
… and use cases
… we also have a TD slot at TPAC, so the question is what we want to discuss there
… there is also a tooling breakout
… already had a breakout day earlier this year
… could make sense to share our experiences with tools like LinkML and also invite the community behind it
… there is also a registry breakout, where we could share our experiences as well
… does anyone think we can contribute something here?
… does anyone object to these proposals?
Kaz: You want to talk about schema-related topics, right? Would it make sense to involve Pierre-Antoine here?
Ege: Talked to him earlier this year, but then we did not follow up on that. Can continue the discussion
Kaz: Maybe you can send him a reminder
<EgeKorka_> TPAC 2024 Breakout proposals on GitHub
Ege: (shows the tpac2024-breakouts repository)
… this is the repository where people can propose breakout sessions, everyone can make proposals here by the way
… if there are any aspects that you think need a wider audience you can either propose them in the wiki or on GitHub
Ege: I think one thing we can do so far is doing a summary of the work so far
… these two topics are promising, but something like initial connection might be more interesting for people within the TF
TD
Extracting Use Cases from TD GitHub Repository
<kaz> wot-thing-description issues with "Selected for Use Case" label
Ege: Thanks to the labelling work done before, we now have a nice list of issues
… that could be used for creating use cases, inserting them into the new "level 1" use case template
… in the template, there is less information needed to submit a use case
<kaz> wot-usecases PR 300 - New Use Case Template Proposal
<kaz> Preview of new "level 1" use case template
Ege: by filling out the template, we can collect information about our existing use cases and experience on working with the template, which we can use to improve the template
… can be seen as a test run
… this is why I want to go to the issue list and pick something "new", so to say
… I wanted to ask if someone is motivated to pick something here and propose as a new feature using the template
Daniel: I think some are somehow overlapping
… for example, actions with query and cancel looks rather broad
Ege: Better topics might be metaoperations, external JSON Schemas, binary encodings, ...
Kaz: Maybe we can look into the identified issues one by one, but as Daniel mentioned, we can maybe look into the possible categories of issues later, seeing which ones are related
Ege: I want to automate this as much as possible...
Kaz: Yeah, we cannot handle everything at once today, but we can assign people and then have them look into related issues
Ege: Seems like in the beginning of the list, there some of the bigger issues
… for example, composed things, in which I think Michael Koster was interested
<kaz> Issue 1902 - Evaluating composed Things as a work item
Koster: Yeah, I am interested in that one and looking into a potential pattern
… are we assigning them right now?
Ege: Yeah, or tomorrow, since beginning with next week, there are not going to be TD calls for a while
… maybe one question is where the resulting Markdown document should go
… since we have not merged the Markdown-based template yet
… maybe we should just provide a prelimary template that can be used
… we can give that to people to do the test runs
… not sure about the simplest way to do this
… (creates an issue documenting what to do)
… what I will do after the call then is creating a Markdown document to list the chosen issues there
… (adds the one by Michael)
<kaz> Issue 757 - Reconsider security & securityDefinitions being mandatory
Jan: I can look into the issue related to security and securityDefinitions being mandatory
… could be a simple one to start with
<kaz> Issue 300 - Allow "security" to include both SecurityScheme objects and declared identifiers
Ege: Looks like issue 300 is also related to this topic
… will add it to the list
… any other volunteers?
Daniel: I am willing to work on one, but I have doubts which one it should be
… I mean, there some that I created, like reading and writing, but I am not sure if they are pressing issues
… I can do it, though, if you think it could be relevant
<kaz> Issue 875 - Should it be possible to indicate whether writing a property returns set value?
Ege: That might be related to the data mapping topic, so it could make sense to work on that
… by the way, I am not taking anything intentionally, since I won't be available, otherwise I would do it
… (shows the resulting issue)
… so this the list we have now
… looks good for now to collect experience with the template
… please as critical as you can with the template, since there will also be people from the outside that will use it, although they are going to have at least some WoT knowledge
<kaz> level-1 template preview from wot-usecases PR 300 to be copied
Kaz: Ege, you will copy the template from the UC repository to the TD repository, and the people assigned can use the topic to work on their issues, right?
Ege: Exactly
… thanks to the volunteers, by the way
Initial Connection
<kaz> PR 2037 - Moving Planning folder
Ege: There is a simple PR to look at for this topic
… this PR moves the related planning folder to the TD repository, since it is the one where the work on this topic is going to happen
… also added some temporary files to the .gitignore file
… don't expect that much discussion here
No objections to merging, PR is merged
Ege: Then the next point is going to the hackmd document which I showed last time
<EgeKorka_> Ege's proposal on Hackmd
Ege: the goal here is to have some more discussion and then move it to the TD repository eventually, where it definitely belongs
… there is one important question that has become relevant in this context
… (shows the hackmd document)
… does anyone want to look at the past proposals? Otherwise we could just go to the most recent proposal
No objections to that
Ege: This proposal is based on the old proposal 5
… here we have a connections object, which can be referenced from the forms and a top-level connection field
… this is quite similar to the way security is being handled
… (recovers a JSON listing that got accidentally deleted in the hackmd document)
… as I showed here, this was question that came up already yesterday, raised by Michael Koster
… we are not just putting the connection information here
… which is why we came up with the name "common elements"
… so this raises the question what we should include in this object
… so far, I also put things here that are usually assumed the default in the TD specication
… for example the content type
… but I also now put the default HTTP method here, as an example.
… but that signals that this is an HTTP connection, for MQTT we would need some kind of different definition for initial connections
… in this example, we have a default top-level HTTP connection
… the interesting part that we can see here now is that, since we don't need the broker in the form, the href field can be an empty string
… this might change if we revisit the URI scheme
… in the HTTP form, the HTTP method is left out since POST is defined as that globally
Ege: so this is a more complex example, which we can discuss in the feature
Daniel: We need to be careful here, Ege, since we are adding a lot of complexity here
… with the reference and the sanity checks
… we need to be careful not to complicate things for implementations and also keep things readable for humans, especially with regard to defaults
Ege: I had a similar feeling, wanted to limit-test here a bit
… we should have some kind of block for global definitions, which then don't need to be repeated all the time. Although this approach can make it a bit complicated for simple TDs
<Zakim> dape, you wanted to sanity checks
Ege: need to compare the result of TDs using the two different approaches
Luca: Concept-wise, it can be a lot simpler than this
… the connection objects at the top are basically forms
… so the parser only needs a way to compose a final href from the different hrefs defined in the TD
… so implementation-wise, this is not that difficult, as long as we make the connections not too different from a form
… but the problems that we have with this are the following
… 1. We also have the concept of links
… they can currently leverage having base, so the question is what happens in this scenario
… that is one part
… the other one is, how can we really leverage a form?
… The problem here is that we can have different verbs that cannot be mapped
… so if you have different verbs for reading and writing, you need to duplicate the form
… the problem is that with the defaults for the forms you are forcing the operation types to always be expanded, so they cannot be an array
Ege: But that is already a problem in the current TD specification
Luca: But this proposal only exacerbates the problem here
… so it would be nice if we could have a vocabulary term for the TD that can unify the different approaches here
… so we need to be referring when the form is referring to its own default, but that is not that big of a deal
… in the end, though, I like the approach
… the only part that might be worth thinking about that we might not get away with is the specification whether the connection is an initial one or not
… so a better term than "initial" might be "resuable"
… and instead of a boolean I would specify a number, indicating how many seconds the connection can be reused
Ege: Thank you for the opinions, I would open a PR with the changes in the TD repository
Daniel: Treating these as a form is fine for me in general, but if it comes to security, I am wondring if we should support expanding instead of replacing here
… that would increase the complexity by a lot
… in the example, you might want to add another security mechanism in the form at the bottom of the hierarachy
Luca: At the moment, we don't have this kind of mechanism anywhere
Ege: In the example, the security is replaced. But we can discuss this going forward
… will add that via a PR to the planning folder to have more discussions on that as well
AOB
Nothing concerning the whole group
<kaz> [adjourned]