14:06:45 RRSAgent has joined #wot-td 14:06:49 logging to https://www.w3.org/2023/07/05-wot-td-irc 14:08:37 https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf 14:08:53 meeting: WoT-WG - TD-TF 14:10:01 chair: Ege 14:10:08 Kazeem has joined #wot-td 14:12:11 JKRhb has joined #wot-td 14:12:12 dape and Mizushima are you in the right call? 14:12:32 luca_barbato_ has joined #wot-td 14:12:53 cris_ has joined #wot-td 14:13:16 present+ Kaz_Ashimura, Ege_Korkan, Kazeem_Oladipupo, Jan_Romann, Luca_Barbato, Daniel_Peintner 14:14:16 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#July_5.2C_2023 14:14:53 scribenick: JKRhb 14:15:04 topic: Minutes Review 14:15:38 ek: We will review the minutes today, but in the future we will review them asynchronously (as described in a policy proposal) 14:15:50 i|We will|-> https://www.w3.org/2023/06/14-wot-td-minutes.html June-14| 14:15:56 ... with the new process, people can suggest amendments via email 14:16:17 ... (goes over last time's minutes) 14:16:28 present+ Cristiano_Aguzzi, Tomoaki_Mizushima 14:17:09 ... we will talk about project management via GitHub again today 14:17:28 ... (notices an incorrect placement of a link) 14:17:36 ... Kaz, could you fix that? 14:17:46 done 14:17:50 kaz: Is fixed now 14:18:01 s/done// 14:18:08 rrsagent, make log public 14:18:15 rrsagent, draft minutes 14:18:16 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 14:18:33 ek: Does anybody see anything they want to be changed? 14:18:57 ... and also, Kaz, for the minutes before that one, we only need to change the names 14:19:14 q+ 14:19:15 https://www.w3.org/2023/06/07-wot-td-minutes.html 14:19:32 ... "minutes" and "minutes review" also need to be merged into one section 14:20:14 Kaz: I think the result from June 14 was not really productive 14:20:44 q? 14:20:46 ack k 14:20:51 ek: Anything more to change? 14:20:58 No change requests, minutes are approved 14:21:26 topic: TPAC 14:21:36 ek: You can add your topics to the list in the Wiki 14:21:37 s/productive/productive, given that meeting was expected to concentrate on the preparation for the planning meeting.../ 14:21:42 sebastian has joined #wot-td 14:21:58 ... as discussed in the main call, the JSON-LD-related topics are now in their own section 14:22:21 q| 14:22:26 s/q|// 14:22:28 q+ 14:22:44 ... also, we had some discussion with the JSON-LD people and we want to discuss the topic of a single source of truth at TPAC 14:23:10 kaz: As mentioned during the main call, I do not understand why we need to have a breakout session regarding that topic 14:23:15 mjk has joined #wot-td 14:23:48 ... this important discussion should not be held in a breakout session 14:24:26 q+ 14:24:27 ... we need to discuss with them common problems that impact all JSON-LD-based specifitions like namespace handling 14:24:47 ... we should discuss these topics with all affected working groups 14:25:17 ... as this very important for future specifications 14:25:43 ek: I do not agree with you, but we can discuss it next week at the main call 14:27:10 sk: I don't understand your point here, Kaz, I am very happy that Ege took the initiative to talk to the JSON-LD people. As Ege mentioned, there is a high interest in the JSON-LD working group to make progress on this topic 14:28:16 kaz: In that case, you should split the discussion into a JSON Schema and a JSON LD part, and provide more background. We should discuss what should be discussed during this Thing Description call first 14:28:55 ek: This was indeed just a general proposal, we can move on to the TD topics 14:29:33 kaz: As mentioned during the main call, I don't object to the idea, but we need to clarify what the core topic is and how the stakeholders can be involved 14:29:51 ... we need to clear in order not to confuse people and to use these two sessions productively 14:30:41 ek: JSON-LD-related topics in the Wiki were mentioned under "TD" before, they have now become their own section 14:30:41 https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf/2023_WoT_TPAC_Agenda 14:30:57 ... if you want to add something to the list, you can use the link above 14:31:05 topic: PRs 14:31:18 ek: We can now move on to the PRs 14:31:28 subtopic: PR 1844 14:31:32 https://github.com/w3c/wot-thing-description/pull/1844 14:31:41 ek: We can start with this one as it is the most recent one 14:31:53 ... this one only updates the JSON Schema 14:32:11 ... before we had a bug that allowed an empty array as a value for the "op" field in a form 14:32:24 q+ 14:32:29 ack k 14:32:30 ack s 14:32:39 ... this is addressed by the PR by adding "minItems" members to the respective places in the JSON Schema 14:33:07 q? 14:33:07 dp: This is more of a question: Is this change also correct for the Thing Model? 14:33:09 q+ 14:33:12 ack d 14:33:18 ... as it does not need to be fully valid there 14:33:35 ek: I guess this could make sense as you could fill the array when instantiating the TD 14:34:06 ca: I would be against allowing an empty array for TMs, since you can simply omit the array in that case 14:34:27 q+ 14:34:34 ... one thing I was wondering about when you opened the issue: What if people what to use the empty array to indicate the default value? 14:34:54 ... I don't know how people interpret that 14:35:20 ... to me it would be clear that the default should only be used if the value is undefined but maybe it should be explained better in the feature 14:35:29 s/feature/future/ 14:36:09 ek: I think we have it in the SHACL file via a minimum of one element 14:36:24 ca: Maybe this is another source of confusion 14:36:38 ack c 14:36:48 lb: We have other places where you can have a single value or an array of values 14:37:02 ... in some cases this might be wasteful 14:37:17 ... we should probably be more careful here in the future 14:37:45 ek: (Adds a comment with a summary of the discussion to the PR) 14:39:10 rrsagent, draft minutes 14:39:11 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 14:40:03 q? 14:40:09 lb: The part that is annoying is that implementors need to consider many different cases. We should have a consistent behavior across all fields that are expected to behave in a similar way 14:40:15 i|You can add your topics|-> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf/2023_WoT_TPAC_Agenda TPAC wiki| 14:40:22 rrsagent, draft minutes 14:40:23 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 14:41:02 ek: What you mentioned last time regarding "items" is something that definitely needs to be fixed in the next version 14:41:12 s|… we should discuss these topics with all affected working groups|… we should discuss these topics with all affected working groups during the official WoT session.| 14:41:14 rrsagent, draft minutes 14:41:15 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 14:41:39 ... the current version of JSON Schema splits the ArraySchema into two versions 14:41:47 s/versions/variants/ 14:42:37 s|https://github.com/w3c/wot-thing-description/pull/1844|-> https://github.com/w3c/wot-thing-description/pull/1844 PR 1844 - Update schema to not allow empty op array| 14:42:41 rrsagent, draft minutes 14:43:12 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 14:44:55 In the discussion, it becomes clear that the semantics and usage of empty arrays must be clarified 14:45:13 ek: I will propose to not merge this today and to clarify this 14:45:21 q+ 14:45:25 ack l 14:45:30 ... just regarding the op value: Does anybody think that we should allow empty arrays? 14:45:44 q+ 14:45:51 ca: For me it is better to only go with the default if you have undefined 14:46:58 lb: My interpretation would be that you would only use the default value if the value is missing and not if the value is empty 14:47:21 ek: I agree, I am not sure if that is clear enough in the spec yet, though 14:47:34 ... (amends his comment to the PR) 14:47:55 q+ 14:48:12 ack c 14:48:13 ack l 14:48:22 ... I will have look until next week, this change would not break any tests I have conducted yet 14:48:45 kaz: Does this imply that we need to update the spec as well? 14:49:12 ek: I think some aspects are a bit vague, but we are not in the wrong 14:49:26 q? 14:49:33 ack k 14:49:40 kaz: In that case we should also update the specification, probably not 1.1 but 2.0 14:50:13 ek: Changes like these would be editorial, is that okay? 14:51:15 s/but 2.0/but 2.0 in order to improve the document and avoid any kind of confusion/ 14:52:57 kaz: Elements like Schema are only resources to help with the understanding of the text 14:53:19 ... however, we should think about potential improvements for the next specification version 14:53:53 ek: The corresponding issue will not be closed 14:54:04 subtopic: PR 1842 14:54:16 -> https://github.com/w3c/wot-thing-description/pull/1842 PR 1842 - Data schema clarification 14:54:58 ek: In this PR, Luca simply adds a clarification that JSON Schema 7 is being used 14:55:11 q+ 14:55:23 ... and processors implementing it can be used 14:55:34 ... would that be fine, kaz? 14:55:46 kaz: This might be a bit problematic 14:55:52 q+ 14:56:12 mk: I am wondering if we should simply state that we use a subset of JSON Schema Version 7 14:56:32 ... and that would indicate to implementors that they can set their ajv accordingly 14:57:05 s/This might be a bit problematic/The question is simply if this change would impact normative features and implementations./ 14:58:03 lb: In the current wording it might be a bit confusing for implementors since the IETF draft does not tell you that you can use Draft 7 as a package 14:58:59 ... persons that are not familiar with JSON Schema can figure out how layered JSON Schema is and do not need to reinvent the wheel. In this proposal I am simply clarifying the intended purpose of this sentence and data schema, without making a normative change 14:59:23 rrsagent, draft minutes 14:59:24 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 14:59:40 ek: I agree that this has not been very clear for implementors, if we could add some like this it would be very benefitial 15:00:31 mk: So you are saying that people should use a particular processor and not that we are using a vocabulary based on Version 7 15:00:42 present+ Michael_Koster, Sebastian_Kaebisch 15:00:46 rrsagent, draft minutes 15:00:48 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 15:00:54 ack mjk 15:00:54 ack l 15:01:18 ek: Would it be okay to add this, kaz? 15:02:06 q+ 15:02:21 kaz: It is discouraged, we could add it to the Recommendation(?), but we should not make any unnecessary changes at this point 15:02:57 ek: I think it would be benefitial, as the old statement confused implementors like Luca 15:03:14 lb: Making this clearer can save a lot of headache 15:04:12 mk: First version of implementors regarding JSON Schema is always "Which version?", so this would make things easier 15:04:39 kaz: I am about to publish the Proposed Recommendation, so we cannot add it to the main document now 15:05:04 ... we could add it to the Recommendation in one month if it is really necessary 15:05:14 mk: I would consider it a bug fix 15:05:40 kaz: I would could still add minor changes and bug fixes to the Recommendation 15:05:55 mk: We could also add a Implementation Guidance section with statements like this 15:06:05 ek: Should be considered for TD version 2.0 15:06:58 kaz: There are multiple options, but we could add this minor fix for the Recommendation next month. But we need a resolution for that 15:07:14 ... we can keep the issue and PR open and add a label 15:07:32 s/It is discouraged./It is not really recommended to add changes at this stage./ 15:08:29 s/we could add it to the Recommendation(?)/We could add it to the Recommendation publication/ 15:09:12 s/I would could/We could/ 15:09:23 s/minor changes/minor editorial changes/ 15:09:42 s/a resolution/a WG-wide resolution/ 15:09:54 rrsagent, draft minutes 15:09:55 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 15:10:57 scribenick: kaz 15:11:03 topic: Panning for new Charter 15:11:32 q+ 15:11:36 ack lu 15:12:38 ek: (starts to describe what is listed on the agenda wiki) 15:12:56 kaz: you want to describe the policy for the next Charter work. right? 15:12:59 ek: yes 15:13:26 ack k 15:13:43 q+ 15:15:31 q+ 15:16:37 ack k 15:16:59 kaz: this proposal to be put on GitHub as the basis of the discussion 15:17:02 ... and 15:17:10 ... the first point sounds a bit strange @@@ 15:17:20 q+ to existing feature request 15:17:30 ca: @@@ 15:17:41 s/@@@/question about tooling/ 15:17:48 q+ 15:17:57 ek: we can work on bug fixes and so on 15:17:59 ack cr 15:18:31 ... mainly maintenance, but could work on development of new tooling 15:18:36 q? 15:18:40 ack c 15:18:48 dp: clarification question 15:19:13 ... we do have some features already planned to be added for the 2.0 spec 15:19:22 ack dape 15:19:22 dape, you wanted to existing feature request 15:19:24 ... do we need use case descriptions for them too? 15:19:25 q? 15:19:27 q+ 15:19:55 ek: my initial feeling is 15:20:09 ... good numbers of items are already there 15:20:52 ... but would say if the description is not enough, or the discussion so far is not clear yet, would be better to have use case descriptions 15:20:56 ... need more discussion, though 15:21:14 mjk: really don't want to have much work unless we have concrete use cases 15:21:34 ... some proposals don't really have actual use case descriptions 15:21:59 ... some of them might be obvious, though 15:22:23 q+ 15:22:26 ... maybe still could have some brief description about why needed 15:22:28 ack mj 15:23:17 ek: yes, we should dig into concrete use cases for the proposed features 15:23:26 mjk: yeah 15:23:55 ... e.g., for the binding templates features, use cases are useful to describe why need what 15:24:33 kaz: agree 15:24:46 ... for minor editorial changes/fixes, maybe no use case needed 15:25:03 ... but all the feature additions/improvements should require use case descriptions 15:25:09 mizu: agree 15:26:15 ... if someone thinks some feature, which has been already raised, is really important, that person should raise a new issue based on concrete use case description 15:26:19 ek: ok 15:27:35 ... would like to move forward for "Big Tasks List Proposal" section then 15:27:44 rrsagent, draft minutes 15:27:46 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 15:28:04 mjk: (describes the items) 15:28:14 ... first two are basic restructuring 15:28:22 [[ 15:28:23 Restructure TD document, e.g. grouping of normative requirements 15:28:23 Restructure TD for usability e.g. common definitions section 15:28:24 ]] 15:28:47 mjk: may end up with some markup language to clarify the points 15:28:58 ... high-level categorization of the work items 15:29:25 s/markup/markdown/ 15:29:46 ... starting with a set of summarized aggregations 15:29:59 ... both are for usability 15:30:17 ... then ThingModel integration into TD doc 15:30:44 ... then Protocol Binding integration into TD doc 15:31:15 ... to me, a lot of stuff like Luca's document to be included here 15:31:22 ... how to put metadata payload, etc. 15:31:34 ... would call it refining the binding mechanism 15:32:08 ... then registry issue 15:32:19 ... three separate pieces to work on 15:32:40 ... and then security refactor and spec generation 15:33:02 ... how to manage the work and the mechanics would be the question 15:33:26 q? 15:33:26 q? 15:33:28 ack k 15:33:29 ack m 15:33:47 ... is this sort of discussion to be done? 15:33:49 q+ 15:34:05 kaz: agree 15:34:21 ... we should go for this direction, and continue the discussion based on this list 15:34:30 mjk: what about other topics? 15:35:02 ek: restructuring have two items here 15:35:36 mjk: can be put into one category 15:35:52 q| 15:35:55 s/q|// 15:35:56 q+ 15:36:18 mjk: not adding any features or anything, but restructure the document 15:37:10 kaz: agree 15:37:58 q? 15:38:04 ack k 15:38:10 q+ 15:38:12 ... during the restructuring work, we should not add new features :) 15:38:19 mjk: agree with that 15:38:44 ... on the other hand, we should work on basic design as well 15:39:04 ... moving on Architecture, moving on implementations, ... 15:39:25 ... we'll be working on many on the Architecture 15:39:46 kaz: right 15:39:48 q+ 15:39:50 ack m 15:40:05 ... and here we don't necessarily mean "WoT Architecture" by architecture 15:40:24 ... but mean "basic design for binding in general". right? 15:40:27 mjk: right 15:40:45 ack mjk 15:40:56 ek: for the spec itself 15:41:18 ... we should not add new features while working on the big refactoring 15:41:46 ... but some concern that the discussion might be going to be a bit boring 15:42:09 ... maybe need some different place to manage new feature proposals 15:42:09 q? 15:42:09 ack e 15:42:11 q+ 15:42:48 mjk: how to deal with the high-level design document? 15:43:11 ... let us keep track on high-level design 15:43:27 q? 15:44:20 q+ 15:44:39 q+ 15:45:08 kaz: regarding the new feature generation concern, we should restart the Use Cases work asap 15:45:16 q+ 15:45:18 ... and use that as the basis for all the specs 15:45:27 ack k 15:45:30 + 15:45:33 s/+// 15:45:34 q+ 15:46:17 ek: for example, we have time-series data as a new proposal 15:46:33 mizu: I think testing should be also added as part of our own tasks 15:46:56 ... so far, the Testing TF has been working for Testing for all the specs 15:46:59 ... but that's too hard 15:47:05 q? 15:47:07 ack mi 15:47:15 ek: as one of the big tasks? 15:47:19 mizu: yes 15:47:57 ... TD TF should be responsible to testing for TD spec 15:48:01 ek: ok 15:48:08 dape: regarding the use case discussion 15:48:14 ... good to restart the work 15:48:55 ... in some cases, some of th enew features 15:49:18 ... are dependent on specific spec only 15:49:30 q+ 15:49:33 ack d 15:49:38 ack dape 15:49:50 mjk: agree with what Kaz said 15:50:28 ... would add categories and labels to use cases/requirements to clarify which ones are for which specs 15:50:28 mjk 15:52:02 ack m 15:52:04 ack k 15:52:14 kaz: @@extracting requirements 15:52:19 ek: agree 15:52:34 subtopic: Next discussion topics 15:53:07 ek: would like to see those two topics too 15:53:09 sorry, I have to go. Bye 15:53:16 [[ 15:53:17 Explain what this is: We want to log big discussion topics and invite specific people to the call where that discussion happens. 15:53:17 URI and href design for all protocols (latest issue: https://github.com/w3c/wot-thing-description/issues/1834) 15:53:17 ]] 15:53:39 q+ 15:55:53 kaz: you're suggesting we clarify the discussion topics beforehand for the next calls in general. right? 15:55:56 ek: right 15:59:57 q? 16:00:00 q+ 16:00:04 ack k 16:00:30 kaz: should concentrate on the refactoring discussion as the basis for the next charter work 16:00:44 ... rather than starting new technical items at this stage 16:00:57 mjk: that makes sense 16:01:27 ... need to think about the balance between the refactoring/bug fixes and new tech discussion 16:01:41 ... how to use the remaining 6 weeks? 16:02:29 ek: think it would be better to have some discussion on new features as well, e.g., 30 mins 16:03:00 mjk: would agree given we need to work on use cases and requirements first 16:03:20 ... in 8 weeks or so, we'll start new work anyway 16:03:28 q? 16:03:31 q+ 16:03:34 ack mjk 16:03:49 ek: should not work on new items then? 16:04:17 mjk: we could work on new items, but should clarify the use cases and requirements rather than jumping into the conclusion directly 16:05:06 ... we could prioritize the proposed features based on the use cases too 16:07:50 ack mjk 16:07:56 ack k 16:08:08 I'm here 16:11:48 kaz: my own preference and suggestion is strictly concentrating on the basic planning and refactoring for upcoming 6 weeks 16:12:21 ... then start discussion on technical details in collaboration with the Use Cases TF after that 16:12:29 ... anyway, we're out of time today 16:12:43 ... so let's continue the discussion next week 16:12:48 [adjourned] 16:13:27 rrsagent, draft minutes 16:13:29 I have made the request to generate https://www.w3.org/2023/07/05-wot-td-minutes.html kaz 19:29:54 Zakim has left #wot-td