Meeting minutes
Logistics
Wiki
Ege: Wiki has been updated, you need to check "remember me" to stay logged in
Schedule
Ege: We could cancel the call after next week if a sufficient number of people would not be joining, but this seems not the case
Minutes Review
<kaz> Jan-24
Ege: (shows the minutes from last week)
… already had a look on them with Michael Koster
… looked good to me
… if there are no remarks, we can approve them
… hearing not remarks, minutes are approved
TD topics
Toolchain automation
<kaz> -> Slides tbd@@@
Ege: Mahda worked out a table with things that can be improved
Mahda: (shares her screen with a presentation)
Kaz: Are the slides available online?
Mahda: Not yet, but I can make them available later
Mahda: This is just a quick motivation why we need such a toolchain
… currently we are facing two problems
… one concerns the number of artifacts we have to update once a document changes
… this can cause a lot of inconsistencies
… once we have a model for generating the artifacts, we can start simplifying
… I prepared a table as an analysis of different semantic web tools
… we derived a number of requirements based on the features we currently have in the TD information model
… such as Array support, one of, inheritance of interaction affordances, unknown object keys with unknown behavior, or pattern matching
… the other table rows refer to specific features of the tools that I analyzed
… these are additional features such as OpenAPI Spec conversion or the generation of diagrams
… I prepared a meta model
… this is for example a meta model for TD
… has features like slots and enables the definition of ranges for example, arrays are supported via a "multi value" concept
… there is also an example for pattern matching
… once have such a meta model, it also generates the SHACL shapes
… the main difference of these shapes to our currently defined shapes is the naming
… we can do some post-processing to do these minor changes, though
… other than that, it does what we want
… it can also auto-generate a JSON Schema
… I haven't compared it to our current version, though
… it can also generate diagrams
… you can also pass additional arguments
Ege: Note: The diagrams are based on Mermaid
Cristiano: Definitely promising, already good result and good start
… I was wondering about the type, does it supports types?
… in the comparison table you mentioned that TinyML does not support types?
Mahda: This is referred to the cases where a TD field can be, for example, a string or an array of strings
… this could potentially be modeled via a oneOf
… however, we might need to look into different alternatives here
Cristiano: Can you show the JSON Schema again? I think you showed the context before
Mahda: Yes (shows the other file), it can also generate the context by the way
Cristiano: I have the feeling that it could potentially also handle the conversion to Typescript types as we are doing it in the Scripting API taskforce, although this might be even more complicated
Ege: @@@
Kaz: Thank you very much for trying to improve the toolchain itself
… however, I am still kind of confused, whether this is a proposal for a new mechanism or just the mechanism from the diagram
Mahda: We don't want to change anything about the documents themselves, but we want to improve the mechanism of generating them
Kaz: In that case, it might be nicer to clarify this point first and also the input files as well as the results such as the diagrams and tables within the HTML files as a starting point
… clarifying, which part of the document is generated using which tool
<Ege> @cris_ sorry it only mentions python dataclasses https://
Mahda: This is just a first proposal, but we can use it to improve the documentation about the process as a whole
It would be appreciated if you could start with high-level description about the toolchain as a whole handles this input to generate that output, then describe which part of the toolchain handles what input to generate what output.
Mahda: Sure, we can add this
Ege: There will be detailed markdown document later, this is just a sneakpeak
<Ege> @cris_ ah yes here https://
Luca: The main idea is we are using some kind of additional formalism to generate all of the other formalisms that we already use
Mahda: Yes, exactly
Luca: So the idea is to check out all of the tools to check which work for us and which one can produce the nicest output
… so then I think we should have a more detailed into the individual tools
… I already noticed that @@@ looks like a very promising tool
… hope that we can utilize for the generating our documents, thank you for your effort
Issues raised by Scripting API with a TD dependency
<kaz> wot-scripting-api Issues with "wait-for-td" label
Ege: This was raised by the Scripting API TF
… should go through them to check the implications for the TD spec
<kaz> wot-scripting-api Issues with "priority: high" label
Cristiano: We can start with the issues labeled "high priority"
… we labeled them according to their relevance to implementations
… most of them are related to meta operations such as readmultipleproperties
… there is the question how to model them in the Scripting API
… we wanted to raise awareness for this aspect in the TD spec
Ege: Thank you for raising these issues, the meta operations can almost considered a bug at the moment, should be improved in the TD specifications
… however, they are not only relevant for the Scripting API
… the data types for the meta operations are unclear, for example
… and this is relevant for all consumers
Cristiano: We share the same view on this issue then
… do we have an issue in the TD repo for that yet?
Ege: I think we should open issues if we don't have them already
… should be exempt from the use case process, as they can be considered "bugs"
… (adds this topic to the Wiki)
Cristiano: In the old TD, operations were more like "documentations" or backward justifications of what we've done. As you mentioned, if we haven't been able to use them then others will probably not be able to so as well
Ege: There are cases where it should be straightforward, such as MQTT with subscribing to wildcards, but this is not the case in general
Ege: Issue ??? is depending on the security definitions overall
Daniel: There are priorities other than low and high as well, by the way
Ege: Issue 214 could also be related to a use case
<kaz> wot-scripting-api Issue 214 - Requirements from oAuth 2.0 code flow
Ege: Issue 532 is related to the canonicalitation and signing work item
<kaz> wot-scripting-api Issue 532 - TD canonicalization and signing
Ege: issue 488 is depending on the versioning discussion
<kaz> wot-scripting-api Issue 488 - Use a different tag for unstable npm packages
Daniel: Correct, not only related to intermediate or snapshot versions, but more general how to align with different TD versions
Ege: Issue 351 got lost a bit
<kaz> wot-scripting-api Issue 351 - Finding correct unsubscribe form
Ege: we can prioritize this a bit, since it will be relevant no matter what we will do
Cristiano: About the versioning issue: It is that we use the same version as in the JSON Schema, so if we want to change the pattern here we are waiting for you
Ege: For now I will just to a documentation of this
… and then we can start sorting them into the correct workflow
Use Case Discussion
Ege: Last week, we agreed that we can do labelling of the issues, such as that the ones that need a use description can be labeled
… that means that we also split the work
… I think all of you should have gotten an email
… I already have seen some work
… so first, are there any questions regarding the process or does someone want to see an example?
Mahda: Yeah, an example would be great
Kaz: As you know, Mizushima-San has started reorganizing the workflow
… I think the current approach is nice
… the Thing Description TF should also think about how to join this discussion based on our discussions here
Ege: I invite everyone to join the use case discussion
… I think many of us are already joining the use case call, but I invite everyone to join the call
Mizushima: I think, regarding Kaz's comment, I would like to discuss the use cases of TD members at the use case calls
Ege: Do you mean to pick one of these issues as an example?
Mizushima: yeah
Ege: Since it is the same topic and also Mahda asked regarding an example, I will go to one
… (shows the issue list in the TD repo)
… each of you got a page assigned
… for example, I went to page 8
… and I looked at all of the issues to see if there is a use case relevant to the charter
<Ege> w3c/
Ege: so, for example, looking at issue 878
… this is related to "describing the initial connection"
… for example, regarding WebSocket endpoints
… this is already in our charter
Mizushima: I would like to add my opinion on the use cases
… I think it is important to clarify the expectations of stakeholders and users regarding the use cases
… and the members of our TD taskforce should be prioritized
Luca: I went through the issues that were assigned to me
… it would probably be nice to have a set of topics we could assign our issues to
… so far, I just added a note my issues, but it would be nice to have a label
Ege: There are already labels like "initial connection", do you mean something like this?
Luca: Yes
Ege: Okay, will create labels for them
Luca: Using the labels, we can also compile a list in GitHub projects eventually
Ege: Continuing the example, I took issue 878 and labeled it as "Has Use Case Potential", which is quite easy I think, I also added the "Selected Use Case" label as it is part of our charter
… having a look into our charter, there is for example "Support WoT Interoperability", which is applicable to a lot of issues
… something similar is true for "Improving TD descriptiveness"
… my basic advice is adding the "Has Use Case Potential", based on that we can also have a discussion in the call
<kaz> WoT WG Charter
Ege: Another example would be issue 885
… which is about more compact formats for TDs and has use case potential, but it is not directly related to our charter, in my opinion
… is that fine, Mahda?
Mahda: Yeah, thanks
Ege: If anything is unclear, feel free to ask and bring an example into the call
Kaz: We're out of time, so let's continue the discussion next time.
[adjourned]