15:08:20 <RRSAgent> RRSAgent has joined #wot-td
15:08:25 <RRSAgent> logging to https://www.w3.org/2023/11/08-wot-td-irc
15:08:34 <kaz> meeting: WoT-WG - TD-TF
15:08:58 <dape> dape has joined #wot-td
15:09:00 <kaz> present+ Kaz_Ashimura, Ege_Korkan, Luca_Barbato, Mahda_Noura, Michael_Koster, Jan_Romann
15:09:11 <kaz> chair: Ege, Koster
15:09:15 <kaz> rrsagent, make log public
15:09:20 <kaz> rrsagent, draft minutes
15:09:21 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:10:01 <dape> present+ Daniel_Peintner
15:11:17 <kaz> agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#November_8.2C_2023
15:11:59 <cris_> cris_ has joined #wot-td
15:12:50 <kaz> present+ Cristiano_Aguzzi
15:13:33 <kaz> rrsagent, draft minutes
15:13:34 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:17:16 <JKRhb> JKRhb has joined #wot-td
15:17:24 <mjk_> mjk_ has joined #wot-td
15:18:37 <cris_> topic: agenda
15:18:58 <cris_> ege: we will start for TD 1.1 publication process
15:19:26 <cris_> ... another major thing is to sync tha static html to the new process document
15:19:53 <cris_> ... we have bacnet
15:20:04 <cris_> ... one topic will be deferred for the next week
15:20:19 <cris_> ... after Michael will discuss next action items
15:20:42 <mjk_> q?
15:20:49 <cris_> ... we need to agree fro the process of new use cases
15:21:04 <kaz> i/we will/scribenick: cris_/
15:21:17 <Ege> q?
15:21:19 <cris_> ... if you have other items for the next week you can always provide the action items in the wiki
15:21:24 <cris_> ... any questions?
15:21:25 <kaz> i|we will|-> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#8_November_2023 agenda for today|
15:21:27 <cris_> ... ok
15:21:46 <cris_> topic: TD publication
15:21:59 <cris_> subtopic: PR 1916
15:22:14 <kaz> present+ Tomoaki_Mizushima
15:22:23 <cris_> ege: we synchronized a couple of resources
15:22:30 <cris_> ... with the root of the repository
15:22:46 <cris_> ... and then I will move it to the resources repository.
15:22:59 <kaz> s|https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#8_November_2023|https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#November_8.2C_2023|
15:23:02 <kaz> rrsagent, draft minutes
15:23:03 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:23:41 <cris_> q?
15:23:41 <cris_> ege: ok no objections, merging
15:24:17 <kaz> i|we synch|-> https://github.com/w3c/wot-thing-description/pull/1916 wot-thing-description PR 1916 - Sync Resources Folder|
15:24:20 <kaz> rrsagent, draft minutes
15:24:21 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:24:27 <cris_> ... ok merged I'll do the same in the resource repository
15:24:27 <cris_> +1
15:24:54 <kaz> s/resource/wot-resources/
15:25:50 <kaz> q+
15:26:03 <cris_> topic: updated process document
15:26:10 <cris_> ege: the process document has been updated
15:26:27 <cris_> ... we have to align
15:26:44 <cris_> ... it is commented
15:28:12 <cris_> ... ok if the processVersion is commented the document should report the current Process version.
15:28:16 <cris_> ... but this is not the case
15:28:29 <cris_> ... maybe we have to update it manually?
15:28:44 <mjk_> q?
15:29:17 <cris_> kaz: let's look in the latest html in the github.io as a starting point
15:29:34 <cris_> ege: still wrong
15:29:46 <cris_> kaz: this means that respec is old
15:29:52 <cris_> q+
15:30:01 <kaz> ack k
15:30:02 <cris_> kaz: we can manually update it
15:31:31 <cris_> ege: the processVersion is deprecated
15:31:37 <cris_> ack c
15:31:50 <cris_> ... during this call we can't do anything
15:32:00 <cris_> ... we should do this after respec is updated
15:32:02 <cris_> q+
15:32:36 <cris_> ack cris_
15:33:14 <kaz> q+
15:33:46 <cris_> kaz: web master said that respec is going to be updated tomorrow
15:34:00 <cris_> ... for today we can ignore the pub rule error
15:34:04 <cris_> ege: found the PR
15:34:09 <cris_> ... it is very fresh
15:34:20 <Ege> https://github.com/w3c/respec/pull/4573
15:35:27 <cris_> topic: binding templates
15:35:59 <cris_> ege: we will talk about URI variables problem next week
15:36:13 <cris_> subtopic: PR 312
15:36:31 <cris_> ege: I added bacNet json schema
15:36:41 <cris_> ... we decided to not put types in the schema
15:37:06 <cris_> ... but I understood wrong, fennybay explained the problem
15:37:39 <cris_> ... the types goes in the form
15:37:42 <cris_> q+
15:37:54 <kaz> q=
15:38:00 <kaz> s/q=//
15:38:01 <kaz> q-
15:38:08 <cris_> ege: basically there are a set of bacnet types
15:38:30 <cris_> ... these datatype are later defined
15:39:13 <mjk_> q?
15:39:17 <kaz> rrsagent, draft minutes
15:39:18 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:39:27 <cris_> ... there types of annotation of data
15:39:42 <cris_> ... everything is done at the form level
15:39:45 <cris_> ... showing an example
15:41:02 <kaz> i|I added|-> https://github.com/w3c/wot-binding-templates/pull/312 wot-binding-templates PR 312 - improve BACnet JSON schema|
15:41:05 <kaz> rrsagent, draft minutes
15:41:06 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:41:44 <mjk_> q?
15:41:44 <Ege> q?
15:41:44 <kaz> s/bacNet/BACnet/
15:44:55 <cris_> cris: good direction
15:45:06 <cris_> ... maybe the text should be more assertive
15:45:08 <cris_> ege: yes
15:45:35 <cris_> cris: also starting from this we should ask ourselves if also application types will need extension
15:45:35 <mjk_> q+
15:45:53 <cris_> ... example having just number and integer is good enough?
15:46:32 <Ege> q?
15:46:34 <Ege> ack c
15:46:35 <cris_> ack c
15:46:53 <cris_> cris: is it possible that the value pass data schema but is not valid for bacnet?
15:47:03 <cris_> ege: yes, we need a better validation process
15:47:28 <cris_> mk: doing this correctly depends by the right schema mapping in the TD next
15:47:53 <mjk_> ack mjk
15:47:57 <cris_> ... we don't have it yet and this is a temporaney fix
15:48:00 <cris_> ege: agree
15:48:06 <cris_> cris: +1
15:48:19 <cris_> ege: we are seeing this pattern in different bindings
15:48:27 <cris_> ... modbus has endianess
15:48:38 <cris_> ... URI variables could be another use case
15:48:43 <Ege> q?
15:49:01 <kaz> rrsagent, draft minutes
15:49:02 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
15:49:28 <cris_> cris: I would say this is a great starting point for using the new process of creating features in TD
15:49:35 <cris_> ege: merging PR
15:52:53 <cris_> topic: TD next
15:54:02 <kaz> (Ege leaves)
15:55:36 <JKRhb> scribenick: JKRhb
15:55:55 <JKRhb> q?
16:01:58 <JKRhb> mjk: Last time there was little attendance, so the last real meeting was two weeks ago
16:02:36 <JKRhb> ... today, we should have a look at how the organize the work and refactoring
16:02:38 <kaz> i|Last time|-> https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#TD_Next_.281h.29 TD next agenda|
16:02:45 <kaz> rrsagent, draft minutes
16:02:46 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
16:02:54 <JKRhb> subtopic: Project Management
16:03:20 <JKRhb> mjk: We need to get to the point at which we can generate PRs and issues
16:03:21 <mjk_> q?
16:03:43 <JKRhb> ... (looks at the Work Items document)
16:04:01 <kaz> -> https://github.com/w3c/wot/blob/main/planning/ThingDescription/work-items.md work-items.md
16:04:17 <JKRhb> ... the first thing we wanted to look at was restructuring
16:04:52 <JKRhb> ... I think we need to have a definition of some of these items under restructuring
16:05:08 <JKRhb> ... there should be a common definitions section
16:05:18 <JKRhb> ... is anyone aware of a better structure of these items?
16:05:40 <mjk_> https://github.com/w3c/wot/blob/main/proposals/deliverable-proposals/thing-description.md
16:05:40 <JKRhb> ... (switches to the TD-specific document)
16:05:50 <kaz> q+
16:05:56 <JKRhb> ... this is a breakdown of the items we have
16:06:20 <JKRhb> ... nevermind, it is not a very good breakdown of the items
16:06:32 <JKRhb> kaz: I have two questions:
16:06:49 <JKRhb> ... first: what is the relationship between the two documents?
16:07:08 <JKRhb> ... work-items.md should probably be the first starting point
16:07:30 <JKRhb> ... second: Maybe we should imrprove the usability of the documents
16:07:47 <JKRhb> mjk: I agree, we need to improve that and refine the definition of these work itmes
16:07:56 <JKRhb> s/itmes/items/
16:08:15 <kaz> s/imrprove the usability of the documents/clarify what we mean by "usability" and "design work"/
16:08:48 <JKRhb> ... so, I think it seems like Binding Mechanism and Binding Submission Mechanism are something different than restructuring
16:09:04 <JKRhb> ... seems to me like that bindings are more like a feature in general
16:09:18 <JKRhb> ... maybe we can start with some of the items lower down on this list
16:09:30 <JKRhb> ... like inline security and better TM integration
16:09:57 <JKRhb> ... not sure about normative parsing, although it seems like an interesting concept
16:10:24 <JKRhb> ... I suppose the idea behind restructuring was to create a new structure before integrating some of these other things.
16:10:32 <JKRhb> ... how should we get this going?
16:10:59 <JKRhb> ... we probably need to have someone go through the document and create a list of issues we need to address
16:11:29 <JKRhb> ... I think we probably need a better definition of the things we need to do here
16:11:35 <JKRhb> ... (starts editing the file)
16:11:47 <JKRhb> ... we might want to just add new items here
16:12:11 <JKRhb> ... specifically, what is a common definition section
16:12:19 <JKRhb> ... maybe we can add a subsection
16:12:43 <JKRhb> ... (adds a subsection "Document reorganization")
16:13:10 <JKRhb> ... and then we add an item "Common definition section"
16:13:49 <JKRhb> ... (adds it to the document, alongside of "Grouping of normative requirements")
16:14:14 <JKRhb> ... do we have anything else to add here? I guess we are not yet prepared to discuss this
16:15:00 <luca_barbato> q+
16:15:08 <kaz> ack k
16:15:11 <JKRhb> ... as a next step, we can collect "Reusable Elements"
16:15:57 <JKRhb> ... like the Reusable Connections, similar to how MQTT connections are organized in Node-RED
16:17:10 <JKRhb> lb: Another aspect are reusable data schemas, for example using JSON pointers
16:17:23 <kaz> ack lu
16:17:34 <JKRhb> ... we could also refactor the security schemes as they are our current blueprint for reusable elements
16:17:46 <JKRhb> mjk: Do you think they use a good pattern?
16:18:23 <JKRhb> lb: I am not sure if the pattern is really good, but the security scheme and connections use a similar pattern and are closely related, on the logical level they are the same thing
16:18:41 <JKRhb> mjk: Yeah, all of these reusable elements should use the same pattern
16:19:14 <JKRhb> ... normalization when processing a TD should more or less work the same across the whole document
16:19:43 <luca_barbato> q+
16:20:07 <JKRhb> mjk: Another item for Document reorganization is the start of a TD design document
16:21:23 <JKRhb> lb: Refactoring-wise, I think we should the affordances more uniform, they should apply the same patterns, e.g. when observing
16:21:40 <JKRhb> mjk: That is a great point, I think we had an ealier discussion about that
16:22:00 <JKRhb> ... what should we call it? That the state machine should work the same?
16:22:06 <JKRhb> lb: We have two parts:
16:22:25 <JKRhb> ... one is expressing the same kind of capability across the three affordances
16:22:43 <JKRhb> ... should not matter what kind of affordance it is, observing should work the same
16:23:20 <JKRhb> ... cancellation of events does work fairly different than obversing, that should not be the case
16:23:33 <JKRhb> s/obversing/observing
16:23:52 <cris_> q+
16:23:54 <JKRhb> ... also, we should express relationships across affordances, this is also something that got requested
16:24:08 <JKRhb> mjk: That is the say, that an action might affect the state of a property
16:24:10 <kaz> s/should the a/should make the a/
16:24:14 <JKRhb> lb: Exactly
16:24:14 <kaz> rrsagent, draft minutes
16:24:16 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
16:25:06 <JKRhb> ca: I think we have something like the list you are currently making somewhere else, should we maybe search first?
16:25:36 <JKRhb> lb: I think this is the list we have and we are just reorganizing it
16:25:52 <JKRhb> ca: There should be a list with issues
16:26:33 <kaz> q+
16:27:07 <JKRhb> mjk: I think we looked at that one. Let's finish this work for now, and then see if we can reuse something we had ealier
16:27:13 <cris_> ack c
16:27:26 <JKRhb> ... this is an attempt to put everything into one place, although it feels somewhat redundant
16:27:48 <JKRhb> ... this is trying to create an index, but let's try not to spend too much time on this
16:28:01 <JKRhb> kaz: Among those subsections currently listed
16:28:11 <JKRhb> ... I think reorganization is clear
16:28:46 <JKRhb> ... but reusable elements and state machines are a bit complicated. I think we should have a clarified environment and context for these two features
16:29:42 <JKRhb> ... the question is how to combine different affordances based on each environment and setting
16:30:05 <JKRhb> ... for example, ECHONET has certain restrictions in this regard
16:30:20 <JKRhb> ...  maybe we need to have a look at existing standards and documents
16:30:52 <JKRhb> mjk: We need to have a design document and have a look at current best practices
16:31:20 <JKRhb> kaz: @@@
16:31:49 <JKRhb> mjk: We should use the use case document as a basis, that makes sense
16:32:52 <JKRhb> ... when creating a design document, we could end up with a lot of documents, but documenting things avoids the same work twice
16:33:06 <JKRhb> ... the design document is more like a redesign document
16:33:11 <mjk_> q?
16:33:29 <JKRhb> ... explaining the rationale and reuse of patterns, e.g. from OpenAPI
16:33:50 <kaz> s|@@@|I personally think we could use the ordinary Use Case template and its procedure to clarify those points (i.e., Reusable Elements and uniform pattern/state machine between actions/events/properties|
16:33:51 <kaz> ack lu
16:33:54 <kaz> ack k
16:33:59 <JKRhb> ... there is one thing I wanted to bring up again, let's say "properties vs actions"
16:34:10 <kaz> rrsagent, draft minutes
16:34:11 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz
16:34:55 <JKRhb> ... the fundamental difference is that you need an operation to access the data with actions and events
16:35:11 <JKRhb> ... furthermore, a lot of people ask when to use an action and when to use a property
16:35:17 <cris_> q+
16:35:32 <JKRhb> ... we should talk a bit more about the semantics of the two concepts and explain them better
16:35:51 <JKRhb> ... for example, properties do not have input and output in contrast to actions
16:35:52 <kaz> ack c
16:36:07 <JKRhb> ca: I wonder if this topic also touches the problem of URI variables
16:36:43 <JKRhb> ... for example, if you have URI variables in properties, then they can act similarly to an action
16:37:03 <JKRhb> ... but I guess this is more refactoring or a new feature that deprecates the old one
16:37:15 <JKRhb> mjk: I agree with that
16:37:31 <JKRhb> ... and it has impact on how we solve others issues as well
16:38:29 <JKRhb> mjk: Can someone explain a bit better what the issue is with TD versioning?
16:38:43 <cris_> q+
16:38:44 <JKRhb> ... do we not have a version scheme that works with TDs or was this something else?
16:38:51 <JKRhb> ca: To be honest, I am not sure
16:39:10 <JKRhb> ... I think the question was how to uniquely identify different versions of a TD
16:39:24 <JKRhb> ... something like a hash to identify or sign a TD
16:39:31 <JKRhb> mjk: Like an md5 hash
16:39:34 <luca_barbato> q+
16:39:49 <JKRhb> ... but I think that also implies that there is some cryptography involved, not just a simple md5
16:39:55 <cris_> ack c
16:40:00 <JKRhb> ca: I suppose we need to ask the original author
16:40:23 <luca_barbato> https://www.w3.org/TR/rdf-canon/
16:41:00 <JKRhb> lb: The RDF canonicalization working group has published their recommendation
16:41:21 <JKRhb> ... this is one of the areas where it is good to not invent the wheel from scratch
16:41:29 <cris_> +1
16:41:51 <JKRhb> mjk: I would have preferred something for JSON, but whatever we do not have to reinvent is great
16:42:13 <JKRhb> mjk: I would add a category "Normative Consumption" to the list
16:42:29 <luca_barbato> q+
16:42:41 <JKRhb> ... do we want to prescribe how TDs are processed beyond the text part, if that makes sense?
16:43:04 <cris_> good point +1
16:43:04 <JKRhb> lb: I would care a lot about a normative degraded consumption rule
16:43:50 <JKRhb> ... see my presentation from TPAC, make all consumers make behave the same way when it comes to degradation
16:44:19 <JKRhb> mjk: Maybe this is also relevant for constrained devices, e.g., if the TD is too big to process as a whole
16:44:55 <JKRhb> ... now I am wondering what we should do with binding mechanism
16:45:03 <JKRhb> ... maybe it should become its own category
16:45:14 <JKRhb> ca: I agree, there is a lot of stuff to consider here
16:45:40 <JKRhb> mjk: (adds a new "Protocol Binding" subsection)
16:46:24 <JKRhb> ... now we have Usability and Design Work Items that make more sense as a separate category
16:46:33 <JKRhb> ... I think the rest of it is pretty clear
16:46:45 <JKRhb> ... so there are four work items here
16:47:15 <JKRhb> ... but maybe we want to start with the Document Reorganization and Reusable Elements first (?)
16:47:46 <JKRhb> ca: I agree, the first state should be to prioritize work items
16:47:58 <JKRhb> ... maybe start with the easier ones first
16:48:19 <JKRhb> mjk: (saves the file and goes over the list once more)
16:48:55 <JKRhb> ... Document Reorganization and Reusable Elements are mostly mechanical
16:49:05 <JKRhb> ... do we have any issues that relate to these two?
16:49:41 <cris_> q+
16:49:42 <JKRhb> ... do we want to create labels to categories the existing issues? We have a lot of issues by the way
16:49:52 <cris_> ack c
16:50:52 <JKRhb> ca: If we create new issues, then we should close older ones and add a comment that they have been superseded
16:51:15 <JKRhb> ... there is also the question, how the process relates to the one presented by Michael McCool
16:51:40 <JKRhb> ... is this related to the Use Cases and Requirements process presented by Michael?
16:52:00 <JKRhb> mjk: A lot of these items are related and motivated by use cases and requirements
16:53:07 <JKRhb> ... some of the issues in the TD repo are already labelled as TD 2.0, so we can probably filter them
16:53:38 <JKRhb> ca: Another kind of refactoring work item is understanding the toolchain for creating all the documents, is it there already?
16:54:12 <JKRhb> ... we had a discussion regarding a single source of truth, at the moment the process is pretty complicated and cumbersome
16:54:25 <JKRhb> ... as it also uses tools we cannot control
16:54:55 <JKRhb> mjk: I'll add it to the list
16:55:06 <JKRhb> ... will avoid the problems Ege had to fix recently
16:55:29 <JKRhb> ca: Not sure if it is easy to fix the process without using strange tooling
16:55:49 <JKRhb> mjk: Yeah, the key to solving this problem is to close the gaps in the tooling
16:56:18 <JKRhb> ... (updates the document)
16:57:19 <JKRhb> mjk: We have a lot of "Defer to TD 2.0" issues
16:57:45 <JKRhb> ... there will be some work involved to categorize all of them
16:58:16 <JKRhb> ... this where we need to have some kind of project management solution
16:58:22 <JKRhb> subtopic: Issue 1889
16:58:54 <JKRhb> mjk: This is one issue we should really have look at, creating a design document
16:59:09 <JKRhb> ... we need to figure out how to assign people and create action items
16:59:48 <JKRhb> ... I'll this issue as a link to the list
17:00:25 <JKRhb> q+
17:01:34 <kaz> q+
17:01:36 <JKRhb> jr: Maybe we can really use that Github Projects feature to organize the issues
17:02:18 <JKRhb> mjk: Ege, kaz, and I already looked into it, we will discuss it soon
17:02:34 <JKRhb> ... next meeting we should start assigning people and start the work
17:02:41 <JKRhb> topic: AOB
17:02:55 <JKRhb> mjk: Any other business?
17:03:43 <JKRhb> kaz: I already mentioned it some time ago, if we really want to use the projects feature, we should have a look into how it is organized across the W3C
17:03:56 <JKRhb> ... we should not overcomplicate things
17:04:04 <kaz> -> https://github.com/w3c/strategy w3c strategy repo as an example (but we need to define some specific procedure)
17:04:18 <JKRhb> mjk: Yeah, we need a policy and should keep the process as lightweight as possible
17:04:32 <kaz> [adjourned]
17:04:33 <JKRhb> [adjourned]
17:04:38 <kaz> s/[adjourned]//
17:04:55 <kaz> rrsagent, draft minutes
17:04:56 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-wot-td-minutes.html kaz